All Injection Attack Vectors
For my next book, I’m trying to develop a reasonably comprehensive list of technologies which are potentially vulnerable to injection attacks. SQL injection is the most common, but there are of course many others. So far here are the ones I’ve got. What else am I missing?
- SQL
- XPath
- XQuery
- XSLT
- JavaScript
- LDAP
Partially, this is a question of which languages have an eval() function, either directly or indirectly. For instance, although theoretically one could imagine a service that accepted Java source code from a user, compiled it, and then executed the result, that’s so complex an approach few if any services have been implemented like that.
By contrast the eval() function in JavaScript will take any string and execute it. That’s why JSON worries me so much. SQL is not execute directly, but most languages including PHP, JSP, and so forth have ways to easily convert strings into SQL statements. If you’re not careful about what’s in those strings, you can find all records in your database deleted because of an errant semicolon.
So where else do injection attacks arise? I can’t imagine this list exhausts all the possibilities.
February 4th, 2007 at 12:57 PM
Shell (executed from Perl for example), XML & HTML (unescaped user input, XSS), and there are many other query languages out there, for example JDOQL, HQL, EJBQL, OQL.
Virtually any program (written in any language) constructed dynamically from strings is vulnerable.
See also: http://en.wikipedia.org/wiki/Code_injection
February 4th, 2007 at 1:06 PM
In fact, the parseJSON method in Javascript does use eval(), but it defangs the JSON by making sure it matches the following majestic regular expression first:
/^(“(\\.|[^”\\\n\r])*?”|[,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t])+?$/
Translated into English, that says that a JSON string is a non-empty sequence of tokens, where a token is either a string or a non-string character
Strings are a sequence of items surrounded by double-quote characters, where an item is either a backslash followed by any character, or a character that isn’t a backslash, newline, or return.
Non-string characters, on the other hand, can only be one of the following: comma, colon, braces, brackets, digits, decimal point, minus, plus, the letters E, t, r, u, e, f, a, l, s, n, u, and l, space, tab, newline, and return.
February 4th, 2007 at 1:11 PM
Oops, ‘u’ and ‘l’ appear twice in the last paragraph.
February 4th, 2007 at 9:01 PM
XML Entity Exploits : http://lists.xml.org/archives/xml-dev/200210/msg01735.html
February 7th, 2007 at 11:59 PM
[…] Over at Mokka mit Schlag Elliotte Rusty Harold (he teaches Java/XML at Poly) is asking whether SQL is the only language with injection attack vector? What about XML/ XPath, JSON, etc. Is there a comprehensive attack-tree for injection attacks? See if you can answer some of these questions. Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages. […]
February 9th, 2007 at 2:59 PM
[…] With a little luck, the book should be on store shelves sometime this summer. I’ve already posted a number of questions that arose while writing it. I’m going to be posting a lot more over the next couple of months. I also plan to post many small excerpts from the book for your perusal and comment. I hope you’ll help out by commenting on, caviling, and correcting the draft pieces I’ll be posting here. […]
February 11th, 2007 at 3:28 PM
If you really want to compile a list, you could add SSI ( Server side includes) injection, PHP injection, Shell injection, ASP injection, Include file injection, command injection and CRLF injection. Tommorow there my be a new web technology, followed the next day by a new type of injection targeted at that technology.
What Yan Ivnitskiy wrote over at http://isisblogs.poly.edu/2007/02/08/all-injection-attack-vectors/, especially the sentance “In reality, in all of these cases we are simply mixing the data with the control channel and assigning each variation a different name.”, is true.
I would suggest abandoning the idea of making a list of all injection attack vectors and simply saying that injection of malicious scripts, SQL statements, XML content and invalid data, usually through use of a form field that the attacker knows will be inserted into the application to cause a potential failure or denial of the service, requires input validation. Bye the way, implementing the security pattern named “Intercepting Validator Pattern” is an excellent way of validating input.
February 11th, 2007 at 9:00 PM
excuse me but what is this “injection attack”? Are you writing a book to define this meaning? Are you seeking dialogue to ascertain the popularity of this phrase? Is there anything novel about this phrase that is informative? Is there a point to this inventention? Are you teaching so that you may learn?
Let me see, now. What is your game, that you should write about a game? Taxonomy? Lepidoptary?