Aristotle points out a post from Anne van Kesteren about draconian error handling. FWIW, I agree with Aristotle. But both of them are really missing the point.
The simple fact of the matter is that the defaults in all of our tools are wrong. Yup, you heard right.
When you’re working with some server-side framework, variables are almost invariably output as-is. If you need to include data from a source that might contain angle brackets or ampersands, you have to call a function first to escape the output before inserting it into the page. Some frameworks (eg: rails) attempt to make this easier by reducing it to a single character (the h function).
But the simple fact of the matter is that it’s the wrong defaults. The default should be to escape everything that’s output, unless the programmer asks otherwise. This is the only way that we will start seeing a reduction in Cross Site Scripting attacks.
The fact that I can flip this default is one of the reasons that I like working with HTML::Mason, even though it’s otherwise a bad mix of code and template.
The SQL guys learned years ago that if you rely on programmers to do the escaping, they won’t bother half the time. Result: lots of applications with SQL injection attacks. The solution: placeholders. Make it simpler and easier to do the correct thing and the problem goes away.
Sadly, I don’t hold out much hope for this being achieved.
5 replies on “The Wrong Defaults”
[…] like freemarker or velocity. But JSP is standard, and it’s everywhere. Despite it’s inability to be secure, it is convenient. And that’s gotta count for something […]
There’s hope yet. In fact Rails 3 has this default set (all output is escaped, you must manually unescape it if you want raw output). I imagine that many frameworks will follow suit in the coming year.
That’s awesomely good news. Hopefully something as high-profile as Rails will cause other people to follow suite…
The Python web framework Django also escapes template variables by default.
@ejunker — WooHoo! There’s hope yet!