4 ms·

Ensuring input is properly validated is always the developer's concern. A framework can make that easier for you, but especially in cases like this, which are b

by bascule 15y ago

Ensuring input is properly validated is always the developer's concern. A framework can make that easier for you, but especially in cases like this, which are basic user authentication concerns, it is ABSOLUTELY the developer's responsibility to be 100% sure how all of those abstractions work and ensure there are no leaks anywhere. You can't punt on security. Abstractions may make it easier, but you better be damn certain how they work.

sirclueless 15y ago
That said, when your tools generate an insecure scaffold by default with no easy path to discovery on how to fix it, your tools do have a security flaw as well. You can't expect all of the developers in the world to be literate in security, especially the ones who choose batteries-included web frameworks as their go-to.
- bascule 15y ago
  The scaffold Rails generates isn't insecure by default, it just doesn't automatically generate example cases that require input validation. Perhaps it should be laden with comments about how to validate input when your code does eventually require it. You can't blame the framework for people failing to validate input. The framework can provide you abstractions for helping you validate input, but at the end of the day, if you're being lazy or sloppy about what you do with data from the outside, that's your fault, not the framework's.
- einhverfr 15y ago
  Agreed. Once we got the SQL-Ledger codebase somewhat stabilized security-wise in LedgerSMB, we started removing it in favor of a secure-by-default framework. Our approach might not work well for other projects and it has its own security pitfalls (which we clearly document, and prevent by default), namely the fact that credential reuse is important and therefore you have to do something like HTTP-BASIC or HTTP-KRB5 auth (and hence for the former SSL really is required). The way we do it is by not trusting the application. All authorization happens by levels further back, such as permissions granted to run stored procedures or on relations (permissions are granted to relations where there really is a clear, coterminous mapping between relational operations and procedural ones). We then provide a framework for handling all of this. It means that as-yet-undiscovered flaws in our application are not as exploitable as they might be because the app is not trusted by the database.

by bascule 15y ago

sirclueless 15y ago

That said, when your tools generate an insecure scaffold by default with no easy path to discovery on how to fix it, your tools do have a security flaw as well. You can't expect all of the developers in the world to be literate in security, especially the ones who choose batteries-included web frameworks as their go-to.

bascule 15y ago
The scaffold Rails generates isn't insecure by default, it just doesn't automatically generate example cases that require input validation. Perhaps it should be laden with comments about how to validate input when your code does eventually require it. You can't blame the framework for people failing to validate input. The framework can provide you abstractions for helping you validate input, but at the end of the day, if you're being lazy or sloppy about what you do with data from the outside, that's your fault, not the framework's.
einhverfr 15y ago
Agreed. Once we got the SQL-Ledger codebase somewhat stabilized security-wise in LedgerSMB, we started removing it in favor of a secure-by-default framework. Our approach might not work well for other projects and it has its own security pitfalls (which we clearly document, and prevent by default), namely the fact that credential reuse is important and therefore you have to do something like HTTP-BASIC or HTTP-KRB5 auth (and hence for the former SSL really is required). The way we do it is by not trusting the application. All authorization happens by levels further back, such as permissions granted to run stored procedures or on relations (permissions are granted to relations where there really is a clear, coterminous mapping between relational operations and procedural ones). We then provide a framework for handling all of this. It means that as-yet-undiscovered flaws in our application are not as exploitable as they might be because the app is not trusted by the database.