Web Application Security
Re: SQLi with backslash Jun 25 2011 07:33PM
Robin Wood (robin digininja org)
On 25 June 2011 17:51, Voulnet <voulnet (at) gmail (dot) com [email concealed]> wrote:
> Okay then, have you tried an alternate encoding? MySQL can act funny
> when asian characters are used. For reference you can see this:
>
> http://stackoverflow.com/questions/1220182/does-mysql-real-escape-string
-fully-protect-against-sql-injection
>
> Because, if I understand correctly, there would a discrepancy between
> what PHP sees (thinking it is a normal multibyte character and passing
> it on, and what MySQL sees if set incorrectly which would result in it
> parsing the asian character as something + single quote.

Just tried and it didn't work, was worth a try.

> By the way, have you tried the char(39) or hex encoding and verified
> it didn't work?

Yes, it won't work as the char(39) is inside the quotes so is just
taken as a string:

insert into log values ('a', 'xx char(39) ...');

To use it I would have to have broken out of the quotes first.

Robin

>
> On Sat, Jun 25, 2011 at 1:36 PM, Robin Wood <robin (at) digininja (dot) org [email concealed]> wrote:
>> On 24 June 2011 18:17, Voulnet <voulnet (at) gmail (dot) com [email concealed]> wrote:
>>> They are probably using that mysql_real_escape_string php function,
>>> which escapes these characters. There are many ways to bypass it, and
>>> you can find it all over the web.
>>>
>>> Some examples:
>>>
>>> use char(39) <-- ASCII decimal value of ' is 39
>>> or use the hex value. For example SELECT (0x27) <-- 27 is the hex value of '.
>>>
>>> For example if you want to load a file, you would call
>>> load_file('myfile'), using hex encoding you take 'myfile' with the
>>> single quotes included and convert it to hex, then write it as
>>> load_file(0x27..........27) with the rest of the hex values of the
>>> filename characters filled in between.
>>>
>>
>> No, all they are doing is stripping ' and ", they dump the statements
>> to screen in the error message.
>>
>> And using 0x27 will just end up with the string 0x27 being inserted as
>> it is inside the single quoted string. That might help if I could
>> escape the quotes but that is the bit I can't do.
>>
>> Robin
>>
>>>
>>> On Wed, Jun 22, 2011 at 5:03 PM, Robin Wood <robin (at) digininja (dot) org [email concealed]> wrote:
>>>> Hi
>>>> I've got a scenario where both single and double quotes are being
>>>> stripped but no other escaping appears to be being performed. The
>>>> database is MySQL with php on top.
>>>>
>>>> The query that I've found SQL injection on is in the form
>>>>
>>>> insert into log values ('a', 'b');
>>>>
>>>> where I can inject in to the second parameter.
>>>>
>>>> If I inject a backslash then I get
>>>>
>>>> insert into log values ('a', 'b\');
>>>>
>>>> which gives an invalid SQL statement and is how the injection was
>>>> found. Can anyone come up with a way to exploit this? If I put
>>>> anything before the slash isn't really worth anything and if I put
>>>> anything after then the statement becomes valid and the slash escapes
>>>> whatever character is after it.
>>>>
>>>> I thought about using the slash to encode something but couldn't get it to work.
>>>>
>>>> The table is write only for me, I can't see any of its entries echo'ed
>>>> back to the site anywhere so I can't go for stored XSS or anything
>>>> like that (maybe possible but not in the time available for the test).
>>>>
>>>> Apart from breaking the statement I can't see a way to exploit this,
>>>> can anyone else?
>>>>
>>>> Robin
>>>>
>>>>
>>>>
>>>> This list is sponsored by Cenzic
>>>> --------------------------------------
>>>> Let Us Hack You. Before Hackers Do!
>>>> It's Finally Here - The Cenzic Website HealthCheck. FREE.
>>>> Request Yours Now!
>>>> http://www.cenzic.com/2009HClaunch_Securityfocus
>>>> --------------------------------------
>>>>
>>>>
>>>
>>
>

This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus