Right, but you'd be insane to let anyone access your website with default
queries like that. You don't want to insert any sort of item like that.
Similarly you can do something like this:
id='blah; drop table foo;'
Note the semi-colon in the string. This will allow you to execute another
sring.
In many web forms, lazy (or underexperienced) programmers will leave out the
the need to escape single quotes in a website form, injecting the string
directly into a sql query.
A webiste form that throws a 500 with a single quote in it is oftentimes
vulnerable (as the sql syntax gets all messy at that point). There is
little to stop you from doing something like:
blah '; delete from foo; select * from x where y='
as a string into a web form.
There are many many non-widespead exploits in that sort of code. Wrap all
your functions and do a
$id =~ s/\'/\\\'/g; On your stuff.
This isn't new, and it isn't wide spread, but it does stand mentioning.
Also, ASP is particularly vulnerable to these sorts of troubles as there is
not necessarily a default function to escape out SQL strings built into the
language (from last time I used it).
Just one more thing to think about...
--Jay Bonci
Manifest Research, Inc.
----- Original Message -----
From: "Gabriel A. Maggiotti" <gmaggiotat_private>
To: <vuln-devat_private>
Sent: Saturday, December 29, 2001 6:59 PM
Subject: malformed sql queries
>
>
----------------------------------------------------------------------------
----
>
>
> ==========================================
> = Malformed SQL query =
> =----------------------------------------=
> = Author: Gabriel A. Maggiotti =
> =----------------------------------------=
> = Email: gmaggiotat_private =
> =----------------------------------------=
> = Webpage: http://qb0x.net =
> ==========================================
>
>
> The goal of this type of vulnerability is modifying the original SQL
query.
> Supposing that a dynamic webpage runs a query in a database server and
> trying to imagine the query structure, it's possible to modify the
> same query with the goal of injecting a malformed one.
>
> The following examples were proven with this architecture:
> - Intel 686
> - Apache/1.3.14(Unix)
> - PHP/4.0.2
> - perl v5.6.0
> - Mysql 3.23.25
> - Probably works in other architectures.
>
>
> A common query:
>
> (1) SELECT * from table WHERE id=$id
>
> where $id is a variable that the web progammer use to perform the query.
> This implies that the variable is potentially revalueable (if is not
checked
> before using it).
>
> We could inject some malicious query in this way:
>
> http://www.host.com/file?id="malicious_code"
>
> Mysql( I don't know if it is a SQL standard), allows to make this type
> of query:
>
> SELECT * FROM table INTO outfile '/tmp/file.txt';
>
> This query writes the output of "SELECT * FROM table" into
"/tmp/file.txt".
> Depending on the server permissions, the reach of this vulnerability.
> In mysql case, it doesn't rewrite files.
>
>
> Injecting the malicious query(1):
>
> - For webserver Apache with cgi's in perl( but works for others )
>
> http://www.host.com/file?id=121%20into%20outfile%20'/tmp/file.txt'
>
> Where "%20" is the hexa of the blank character.
>
> Good!!!, with this one you are able to write in "/tmp/file.txt", but the
> content is the result of the original query. It's at this point where
> is up to your imagination to create a useful query. :))
>
> Also is posible to read any file, making a query and dumping the result
> to a table.
>
> (2) LOAD DATA INFILE "/etc/passwd" INTO TABLE table;
>
> This query keeps in the table "table" the content from passwd, depending
> on the permissions of mysql daemon.
>
> If I choose the table correctly:
>
> CREATE TABLE table(
> txt text
> );
>
> I could inject the malicious query in this way:
>
> http://www.host.com/file?id=121%20load%20data%20in%20file%20'/root/passwd'
>
>
> .... Currently, I'm writing more about this kind of vulnerabilities
>
>
>
>
This archive was generated by hypermail 2b30 : Sat Dec 29 2001 - 18:39:31 PST