4 ms·

There isn't, at least not really, since webapps are designed as full-service kiosks: all of the data management, user management and access control are supposed

by tremon 5y ago

There isn't, at least not really, since webapps are designed as full-service kiosks: all of the data management, user management and access control are supposed to be handled from the same console. If you want the database to enforce access controls, then every user must exist as a separate entity in the database, which is good, but then the webapp also needs the permissions to manage user accounts in the database, which is bad for security, and the webapp can no longer use connection pooling, which is bad for performance. There are tricks you can use, such as implementing row-level security and tying it to some concept of end user identity, but even ignoring that ORM's don't understand or support RLS and developers therefore won't use it: it's still the same problem of letting the fox guard the henhouse. The webapp is the single control point for both user access and user administration (including self-service account creation and password reset), so whatever solution you come up with, the webapp will need to have super-user access to do that, and therefore if the webapp is compromised, your data-level access controls can be compromised too. So, in order to even begin thinking about securing your data, the webapp should probably be split into multiple reduced-access microservices that handle different aspects of the webapp function. As long as we're talking about a single monolithic backend, any attempt at scope mitigation can (and likely will) be defeated.

konha 5y ago
There are some easy wins most applications could use but don‘t most of the time. Like having sensible permissions for your app-db-user. Running migrations in a separate process? No need to have permission to do schema changes. Events are only written to the db and not queried/viewed from the app itself? Grant only INSERT rights to the table etc.
formerly_proven 5y ago
It's not that we don't know how to build things securely, it's just that we routinely ignore even basic principles of security 'cause it's easier. Virtually every webapp violates complete mediation and so it's just unreasonable to expect security. Similarly, most developers don't care for security and even less about principles and system design. Again, it's unreasonable to expect secure outcomes from that.
- pdimitar 5y ago
  It's probably more charitable to say "most devs are not given time and effort bandwidth to care about security". Trust me I'd love to plug more holes before first production deployment but management (and my CTO) would never approve a time/energy budget for it.
  - guiriduro 5y ago
    In the current market, I hope it won't sound too disingenuous to suggest you look to work with management that does. You'll be happier, and the market signal of enough people doing it will improve conditions for everyone.
    - pdimitar 5y ago
      I don't disagree in principle but there are many other factors that increase my job happiness: - We have deadlines but they are not strict and very rarely somebody is going to even ping you outside work hours. People there want some discipline but they don't micromanage. - The atmosphere is 95% of the time super chill. - There are no egos flying around (not more than usual anyway; I scheduled a meeting to explain some coding style practices that should be painfully obvious but hey, trying not to judge here). - Technical excellence is appreciated by a very technical and careful CTO -- but is indeed often sidelined in favor of deadlines and business-enabling work. However, I have already successfully fought him and the CEO off on 2-3 technical excellence tasks by demonstrating they'll reduce future slowdowns. Doable but requires some brawling in meetings. - Pay is one of the biggest in EU (although it's like 1.5x - 2.0x less the than the US one). --- > and the market signal of enough people doing it will improve conditions for everyone. I keep hearing this and I want it to be true but for 20 years of career I've never seen it, not once. Nowadays I no longer believe it. Everywhere I worked (I am mostly a contractor so it has been a very colorful career) the business will stick to their idea of "we can always hire somebody else" with persistence that you'd be jealous of -- I don't know if it's an illusion or not but trust me, it's VERY persistent. That alone weakens the point you brought up because employers simply don't believe it and often times go out of their way to look for those other mythical people -- and I've been told in several occasions that the business closed doors before they managed to repair their clusterf_ck of an app. That's how persistent they are in their thinking process that everyone is expendable.
willcipriano 5y ago
I have experimented with a design that only allows the application to access a set of stored procedures via it's SQL user. It seems to work, if you write complicated enough stored procedures you can enforce things like each entry must be created by a logged in user or whatever. Then the application is limited to interactions it's supposed to have, so it can't drop a audit table or something. I even did login via a stored procedure, confirming the hashed password matched and generating a bearer token that future stored procedures require to function.
- tialaramex 5y ago
  My current project is maintenance for a large system built of shared procedures. In principle this feels like a reasonable strategy but chances are your stored procedures do not enjoy the same creature comforts as your "real" software. In my case they've got commented out code blocks, procedures with names ending V3.bak.tmpMar14.old, randomly different styles and formats from one to the next, and inconsistent naming (AllGroups allGroups or ag?). All of which would be quickly and easily prevented or retrospectively corrected in say C# or Java but there's no easy way to do it with the archaic T/SQL setup here.
  - willcipriano 5y ago
    I agree it would require a great deal more discipline to implement then the alternatives. I can do it by myself, just takes about twice as long to do over the normal way, but with a team it would be a nightmare.
  - akersten 5y ago
    I'm unfamiliar with T/SQL but of those issues seem like fundamental limitations of stored procedures, just implementation details that need updating. Why is there no way to do it?
    - tialaramex 5y ago
      Of course, everything is possible, but resources are limited and so it matters that it's harder and requires ongoing effort to keep this right. Edited to add: I retrospectively realised the above comment had an auto-correct mistake where "easy way" had been misscorrected to "way way" and so it wasn't clear I meant only that it's needlessly harder
jeroenhd 5y ago
Even in a monolith, scope can be managed. I've worked on an application where a specific subset of endpoints used a different data source that was configured with different credentials, attached to a read-only user. Without code execution, these systems were reasonably fool-proof. A plugin system where an plugin would be exposed to a different set of credentials shouldn't be too hard to set up with some middleware preparations. Such a system would require granting the main account complete database control (which is iffy) or would require a lot of manual configuration for user permissions (which sucks) but it's definitely something you can do in a monolith like WordPress. Permissions wouldn't be as well-contained as in a proper, fragmented, micro-service-oriented permissions model, but it would be a good step forward and one that wouldn't necessarily break too much when done as a software update.

by tremon 5y ago

konha 5y ago

There are some easy wins most applications could use but don‘t most of the time. Like having sensible permissions for your app-db-user. Running migrations in a separate process? No need to have permission to do schema changes. Events are only written to the db and not queried/viewed from the app itself? Grant only INSERT rights to the table etc.

formerly_proven 5y ago

It's not that we don't know how to build things securely, it's just that we routinely ignore even basic principles of security 'cause it's easier. Virtually every webapp violates complete mediation and so it's just unreasonable to expect security. Similarly, most developers don't care for security and even less about principles and system design. Again, it's unreasonable to expect secure outcomes from that.

pdimitar 5y ago
It's probably more charitable to say "most devs are not given time and effort bandwidth to care about security". Trust me I'd love to plug more holes before first production deployment but management (and my CTO) would never approve a time/energy budget for it.
- guiriduro 5y ago
  In the current market, I hope it won't sound too disingenuous to suggest you look to work with management that does. You'll be happier, and the market signal of enough people doing it will improve conditions for everyone.
  - pdimitar 5y ago
    I don't disagree in principle but there are many other factors that increase my job happiness: - We have deadlines but they are not strict and very rarely somebody is going to even ping you outside work hours. People there want some discipline but they don't micromanage. - The atmosphere is 95% of the time super chill. - There are no egos flying around (not more than usual anyway; I scheduled a meeting to explain some coding style practices that should be painfully obvious but hey, trying not to judge here). - Technical excellence is appreciated by a very technical and careful CTO -- but is indeed often sidelined in favor of deadlines and business-enabling work. However, I have already successfully fought him and the CEO off on 2-3 technical excellence tasks by demonstrating they'll reduce future slowdowns. Doable but requires some brawling in meetings. - Pay is one of the biggest in EU (although it's like 1.5x - 2.0x less the than the US one). --- > and the market signal of enough people doing it will improve conditions for everyone. I keep hearing this and I want it to be true but for 20 years of career I've never seen it, not once. Nowadays I no longer believe it. Everywhere I worked (I am mostly a contractor so it has been a very colorful career) the business will stick to their idea of "we can always hire somebody else" with persistence that you'd be jealous of -- I don't know if it's an illusion or not but trust me, it's VERY persistent. That alone weakens the point you brought up because employers simply don't believe it and often times go out of their way to look for those other mythical people -- and I've been told in several occasions that the business closed doors before they managed to repair their clusterf_ck of an app. That's how persistent they are in their thinking process that everyone is expendable.

willcipriano 5y ago

I have experimented with a design that only allows the application to access a set of stored procedures via it's SQL user. It seems to work, if you write complicated enough stored procedures you can enforce things like each entry must be created by a logged in user or whatever. Then the application is limited to interactions it's supposed to have, so it can't drop a audit table or something. I even did login via a stored procedure, confirming the hashed password matched and generating a bearer token that future stored procedures require to function.

tialaramex 5y ago
My current project is maintenance for a large system built of shared procedures. In principle this feels like a reasonable strategy but chances are your stored procedures do not enjoy the same creature comforts as your "real" software. In my case they've got commented out code blocks, procedures with names ending V3.bak.tmpMar14.old, randomly different styles and formats from one to the next, and inconsistent naming (AllGroups allGroups or ag?). All of which would be quickly and easily prevented or retrospectively corrected in say C# or Java but there's no easy way to do it with the archaic T/SQL setup here.
- willcipriano 5y ago
  I agree it would require a great deal more discipline to implement then the alternatives. I can do it by myself, just takes about twice as long to do over the normal way, but with a team it would be a nightmare.
- akersten 5y ago
  I'm unfamiliar with T/SQL but of those issues seem like fundamental limitations of stored procedures, just implementation details that need updating. Why is there no way to do it?
  - tialaramex 5y ago
    Of course, everything is possible, but resources are limited and so it matters that it's harder and requires ongoing effort to keep this right. Edited to add: I retrospectively realised the above comment had an auto-correct mistake where "easy way" had been misscorrected to "way way" and so it wasn't clear I meant only that it's needlessly harder

jeroenhd 5y ago

Even in a monolith, scope can be managed. I've worked on an application where a specific subset of endpoints used a different data source that was configured with different credentials, attached to a read-only user. Without code execution, these systems were reasonably fool-proof. A plugin system where an plugin would be exposed to a different set of credentials shouldn't be too hard to set up with some middleware preparations. Such a system would require granting the main account complete database control (which is iffy) or would require a lot of manual configuration for user permissions (which sucks) but it's definitely something you can do in a monolith like WordPress. Permissions wouldn't be as well-contained as in a proper, fragmented, micro-service-oriented permissions model, but it would be a good step forward and one that wouldn't necessarily break too much when done as a software update.