On 20 Dec 2004 at 22:34, Sverre H. Huseby wrote:
[Mike Andrews]
| Not all SQL attacks are on strings - integers used (maybe ids?
| are also susceptible. For example, at
| http://crash.se.fit.edu/hackerland/
| http://[...]/hackerland/showdetails.php?type=flowers&id=2
| uses a string and an integer to retrieve the description. Both
| are vulnerable, but if I just change the id number to...
| http://[...]/hackerland/showdetails.php?type=flowers&id=2 or 2>1
| ...there's no escaping of quotes needed, or the usual comment
| trick - it just works with the SQL that is generated.
Exactly. And there's no magic to it at all, if people are just
willing to think about what the "next layer" they pass the constructed
string to will do. In the SQL Injection case, the "next layer" is the
SQL parser of the database server.
I wrote about this on vuln-dev on my birthday 2.5 years ago [1], but I
feel like sort of repeating some of it, this time a little bit more in
(technical) detail than the last time. All injection problems, like
SQL Injection, Shell Command Injection, XPath Injection, LDAP
Injection and even Cross-site Scripting (HTML Injection) are the
result of programmers building a statement for some parser to read,
and mixing data with language constructs. If the programmer would
bother to play the role of the parser she passes the data to, the
injection problems would lose all their magic.
I fully agree. BTW, HTTP response splitting is yet another example of
an application (web/app server, usually), that constructs a message
(response) in a certain grammar (HTTP) and failing to do so securely.
So in my mind, HTTP response splitting is HTTP (response) injection.
-Amit
