Re: SQL injection (no single quotes used)

["Amit Klein (AKsecurity)" <aksecurity () hotpop com>]

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