Saturday 23 April 2016

security - Interpolique: transparently preventing SQL Injection and XSS with base64 encoding, what happened?



For the keynote at The Next HOPE a couple of years ago, Dan Kaminsky unveiled Interpolique (the talk is really fun btw). The problem he raised was how to defend against injection attacks, including SQL injection, cross-site scripting (XSS), and other injection vulnerabilities. For example, Unicode makes escaping characters useless and that prepared statements are a PITA.



His fix was to convert strings to base64 during transit. In SQL, for example, one can simply pad the SQL call with a decode64 eval(). It's much easier than prepared statements, little (if any) impact on DB performance, transparent to users of the DB, and native implementation within programming languages could make usage transparent for the programmer both in terms of use and server performance. Similar techniques can be applied to defend against XSS and all cross-language communication. But, outside of a couple of blog articles written at the time, I can't find mention of it anywhere.



What happened?


Answer




What happened? What happened is the same thing that happens to many good ideas in the security space: it went nowhere, for reasons outside of the inventor's control. It is a cool idea, but it requires adoption by frameworks and application developers. And, for better or worse, there is not a lot of demand for security solutions like this. For most developers, security is a secondary consideration. Many application developers don't think they have a problem and don't perceive a need for a solution (most of them are probably fooling themselves, but so it goes). And many of the developers who are aware of XSS, think they can avoid it by just being careful (that's a dubious proposition, as it is too easy to make a single inadvertent mistake that hoses the security of your whole site, but hey, if they don't feel a need for it, they ain't gonna adopt it).



Please do understand that Interpolique is not primarily about SQL injection. You describe it as being about SQL injection, but that isn't its primary contribution. Its primary contribution is helping to defend against XSS and other injection attacks. Kaminsky's talk does discuss how to use Interpolique to prevent SQL injection, but I suspect that is primarily a pedagogical device. Interpolique is a general defense against injection attacks, of which SQL injection and XSS are two examples. SQL injection is easier to understand and simpler to understand than XSS, so it was probably simpler to explain the ideas behind Interpolique in the context of SQL injection than XSS. Any security researcher should immediately see how they apply to the context of XSS, which is the more important and challenging problem. As others have said, prepared statements are a "good-enough" solution to SQL injection for practical purposes (there are indeed some cases that are not handled by prepared statements, but they can probably handled by escaping/validation plus careful code audits), so that's not where Interpolique is most useful.



The security technology in this space that has seen the most take-up is context-aware auto-escaping, such as that implemented in Google's ctemplate. That requires framework support, but is arguably even better for developers than Interpolique, because in most situations it requires no additional effort from developers: escaping is done automatically for them. In addition, it is better for security, too: escaping is done by default, so the defaults are secure and developers have to take some explicit step to disable the security measures.



This question might have gotten more informed responses on the IT Security.
(I can't believe one person actually wrote "Dunno who is that Dan Kaminsky guy, but he has no clue." I hope that was a joke! Kaminsky is one of the most prominent and respected researchers/practitioners in computer security.) You can find Interpolique and similar technologies discussed on IT security at the following questions: Whitelisting DOM elements to defeat XSS, Escaping JavaScript constants.


No comments:

Post a Comment

c++ - Does curly brackets matter for empty constructor?

Those brackets declare an empty, inline constructor. In that case, with them, the constructor does exist, it merely does nothing more than t...