4 ms·
The main problem is that both SQL and HTML are often simply represented by strings. The programmer has to keep track herself to make sure everything is escaped
by eelco 18y ago
The main problem is that both SQL and HTML are often simply represented by strings. The programmer has to keep track herself to make sure everything is escaped and unescaped at the right moment.
The point is that you can use Haskell's type system to get guarantees about and keep track of escaping. It's really light-weight to add new types. Also, dynamic typing would probably mess this up.
Still, all this mainly comes down at the shoulders of the library designer. But, looking at some of the available libraries (such as Text.XHtml) this works really well.
In the case of Text.XHtml the easy/default case when using a string in HTML is that it's escaped. When you want to 'parse' a string to HTML you'll have to be explicit. That makes it really hard to 'accidentily' forget to escape HTML.
The way I look at Haskell's type system is that it's a great tool for easily enabling 'safe' programming. It won't work automatically, but it gives you the opportunity to let the type checker take care of guaranteeing that everything will work as expected ;)
- tptacek 18y agoYeah, I think this is a bit naive. Of the three SQLi cases I mentioned, only the first is due to the app language's handling of string input and query strings, and that case is just as easily handled by parameterized queries. The second case is not due to the fact that the same type is used for input and query strings; when a web app passes DESC or ASC or LIMIT 100 in via POST arguments, that's a design problem type systems don't solve. Likewise, type systems might fix the simplest XSS problems, but the nasty ones occur in code that is explicitly trying to handle input that has been laundered through the database and must include HTML characters.
- rcoder 18y agoI still don't see why "type systems don't solve" the problem of keeping data domains separate. If user input is of a different type than SQL query components, you simply can't allow GET or POST arguments to hit the database un-sanitized. Yes, you can perform the check by hand (i.e., fix the "design problem"), but as we've all seen, programmers don't do that consistently, which leaves us patching the same class of vulnerability time and time again. Type systems also don't have to be the algebraic types of Haskell; SELinux DTE and FlowCaml/Jif information flow analysis both fit loosely under the umbrella of "type checking," and yet allow for very fine-grained and interesting security properties of complex, real-world systems to be asserted and enforced.