4 ms·

You're right that #1 is indeed just a matter of using the right API. (I actually blame the poor state of many database client libraries and tutorial docs for th

by rcoder 18y ago

You're right that #1 is indeed just a matter of using the right API. (I actually blame the poor state of many database client libraries and tutorial docs for the proliferation of interpolated query params, but the point remains that it's basically a mechanical fix.) For #2, the problem is a bit trickier, but again, it just requires attention on the part of the developer. Given the limited use of stored procedures by most LAMP developers, I think that #3 may be the least critical, even if it is the most difficult to tackle with a simple code analysis tool. As you suggest, none of these issues are particularly hard to avoid via careful programming. The problem is that programmers often aren't careful, and when working in languages which offer "one-size-fits-all" string, array, and file types, they tend to just shove everything into and out of those containers without thinking about type or flow checking. Type checking isn't a panacea, but it can flag issues of either type 1 or 2 early, which gives developers a chance to catch themselves before they commit (or even worse, deploy) a potential security hole. Part of my motivation for this comes from reading a lot of unit tests and specs for webapp code. If you step back and think a bit, it becomes obvious that a lot of the test harness is simply devoted to type checking, and that the verbosity (and easy satisfaction of coverage metrics such tests provide) often mask otherwise glaring gaps in the actual test coverage.

tptacek 18y ago
I guess I'm asking, how does Haskell reduce the amount of effort required to write secure SQL? * It helps in the first case, but then, so do parameterized queries, which developers already have and are familiar with. * It doesn't help --- at least not elegantly --- in the second case. * It can't help in the third case, because that error is happening in the database itself. (By the way, not sure why injections in dynamic SQL in stored procedures would be least critical). I get you loud and clear that "even though it's easy to avoid these problems in PHP, developers don't". You're right. "Use good code" is not a solution for the problem of "bad code". But is Haskell? I like the idea of static analysis in Haskell.
- rcoder 18y ago
  Where a static analysis tool can help is in flagging those cases where a developer might have made a bad assumption, and forcing them to reconsider that code point. Basically, it's a way to enforce some basic code review practices without requiring one of your senior developers to be able + willing to read over your junior devs' code. The whole point of programming is to automate those tasks that can be automated, right? So, let's automate the first-pass stage of a basic security audit as much as we can. To your specific points: * Parameterized queries are available in some cases, as you said, but don't work when you have to build some portion of the query (sort order, grouping, etc.) at runtime. Static tools can help flag such dynamic values as being tainted or clean, as well as help insure that resulting queries will be well-formed. * All that's necessary to extend your type checking to the database is to enforce the same level of discipline you do for built-in API functions. Just as static analysis tools need a signature for primitive functions provided by the runtime platform (syscalls for C, primitive library functions for PHP, etc.), your static checker could ensure that queries which used stored procedures checked at least the asserted type signature of those procedures. (SQL is pretty type-savvy, and most stored proc authors should be able to trivially provide type sigs for their code.) The advantage to using Haskell for all of this is twofold: * There are excellent existing parsing and graph algorithm libraries maintained by the Haskell community * Working in a strict, pure functional language makes you think in terms of mathematical theories, rather than stateful effects, which in turn tends to result in better, more deterministic code That being said, I think you could use OCaml, Lisp, or any number of other high-level languages to similar effect. The uniquely math-oriented world view of Haskell (and its implementers and users) does tend to lend itself to just the kind of defensible reasoning that you would want from a security-focused static analysis tool, though.
  - tptacek 18y ago
    Well, just so we're clear: I buy the idea of using Haskell or OCaml for static code analysis (in fact, one of the better known static analyzer tools, which operates on binary control flow graphs, is written in OCaml). What I don't buy is the idea that the Haskell runtime actually improves SQL or HTML security. By all means, write a Haskell source analyzer. It will help. But a web app stack written in Haskell will presumably have the same problems (or lack thereof) that Rails does. Mathematical reasoning, for what it's worth, doesn't have a great track record in systems security. ;)

by rcoder 18y ago

tptacek 18y ago

I guess I'm asking, how does Haskell reduce the amount of effort required to write secure SQL? * It helps in the first case, but then, so do parameterized queries, which developers already have and are familiar with. * It doesn't help --- at least not elegantly --- in the second case. * It can't help in the third case, because that error is happening in the database itself. (By the way, not sure why injections in dynamic SQL in stored procedures would be least critical). I get you loud and clear that "even though it's easy to avoid these problems in PHP, developers don't". You're right. "Use good code" is not a solution for the problem of "bad code". But is Haskell? I like the idea of static analysis in Haskell.

rcoder 18y ago
Where a static analysis tool can help is in flagging those cases where a developer might have made a bad assumption, and forcing them to reconsider that code point. Basically, it's a way to enforce some basic code review practices without requiring one of your senior developers to be able + willing to read over your junior devs' code. The whole point of programming is to automate those tasks that can be automated, right? So, let's automate the first-pass stage of a basic security audit as much as we can. To your specific points: * Parameterized queries are available in some cases, as you said, but don't work when you have to build some portion of the query (sort order, grouping, etc.) at runtime. Static tools can help flag such dynamic values as being tainted or clean, as well as help insure that resulting queries will be well-formed. * All that's necessary to extend your type checking to the database is to enforce the same level of discipline you do for built-in API functions. Just as static analysis tools need a signature for primitive functions provided by the runtime platform (syscalls for C, primitive library functions for PHP, etc.), your static checker could ensure that queries which used stored procedures checked at least the asserted type signature of those procedures. (SQL is pretty type-savvy, and most stored proc authors should be able to trivially provide type sigs for their code.) The advantage to using Haskell for all of this is twofold: * There are excellent existing parsing and graph algorithm libraries maintained by the Haskell community * Working in a strict, pure functional language makes you think in terms of mathematical theories, rather than stateful effects, which in turn tends to result in better, more deterministic code That being said, I think you could use OCaml, Lisp, or any number of other high-level languages to similar effect. The uniquely math-oriented world view of Haskell (and its implementers and users) does tend to lend itself to just the kind of defensible reasoning that you would want from a security-focused static analysis tool, though.
- tptacek 18y ago
  Well, just so we're clear: I buy the idea of using Haskell or OCaml for static code analysis (in fact, one of the better known static analyzer tools, which operates on binary control flow graphs, is written in OCaml). What I don't buy is the idea that the Haskell runtime actually improves SQL or HTML security. By all means, write a Haskell source analyzer. It will help. But a web app stack written in Haskell will presumably have the same problems (or lack thereof) that Rails does. Mathematical reasoning, for what it's worth, doesn't have a great track record in systems security. ;)