RE: Simple to exploit SQL Injection ?

["LAROUCHE Francois" <Francois.Larouche () accorservices com>]

Rich,

If your theory of escaping was not bad at first I looked further at the syntax and realized that the last quote is the 
one to finish the whole statement of ' SELECT [...] password = 'test' '. So no it's not double quoting. Besides, it 
would not raise an error, quotes by pair will always be right, only odd number of quotes raises an error.

Jason:

The others people on the list probably gave you the right answer, so I don't think I can add anything on the syntax 
part.

But perhaps you need some hints to help you out with SQL injection for future needs, or anyone else who is starting 
with SQL injection.

Try to use characters before the quote first, then after. Try to put ; and look at the generated error. Sometimes it's 
harder than just a ' or 1=1-- statement.

The goal is to make some trials and compare the errors.

Remember that sometimes you don't even need a quote since the parameter expects a numerical value. I would highly doubt 
it for a password parameter but we never know...

Another thing you can try is to find other pages that you could SQL inject:

1. By brute forcing a valid user. That way it will expose even more pages to check
or
2. By finding a portion of the app that you can browse without being logged or
3. By finding another web app sharing the same DB server that you could SQL inject and rebound in the actual DB of your 
app you are pen testing. (my boss tease me in saying that I hack the Net to break the web app :) but sometimes it 
works!)

Also, you can always try to inject '; waitfor delay '0:0:10'-- and see what happens. Often, even if it generates an 
error, the second portion of your statement will be executed. If you are lucky, you can then blind inject with a time 
delay.

Another trick, is to do some trials with an environment you know well, like the query analyzer for instance with 
statements looking like the one you have in the web page. There you can compare the error generated with the one you 
get from the web page and try to figure out how to make it works there first and then you can inject in the actual web 
page.

The bottom line is, if you are blocked with one possible place to inject, don't waste too much time and try to find 
another that is much easier.

Hope it would help for future tests, and I'm sorry if you already knew all that, in that case it might help others.

François Larouche


-----Original Message-----
From: Rich Bergmann [mailto:rbergmann () cfl rr com]
Sent: Monday, November 28, 2005 2:12 PM
To: 'Jason binger'; webappsec () securityfocus com
Subject: RE: Simple to exploit SQL Injection ?

The application is apparently "escaping" (doubling-up) quotes in the
password field.  This is good practice, although a better (best?) practice
would be to parameterize the query.

AFAIK, SQL injection on this form will be difficult, if not impossible.

-----Original Message-----
From: Jason binger [mailto:cisspstudy () yahoo com]
Sent: Sunday, November 27, 2005 7:50 PM
To: webappsec () securityfocus com
Subject: Simple to exploit SQL Injection ?

I am reviewing a .Net web application. When entering
xyz for a username and ' for a password into a form I
receive the following stack trace (extract):

System.Exception: Can't Load DataReader using SQL
string: 'SELECT * FROM users WHERE username = 'xyz'
AND password = '''' -- Unclosed quotation mark before
the character string '''. Line 1: Incorrect syntax
near '''.

Now I would have thought this would be easy to
exploit, but I can't bypass the logon page. xyz is a
valid username. Any ideas?

Cheers



        
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com


______________________________________________________________________________________________________________________________
This email, the information contained within and any files transmitted with it (herein after referred as "the message")
are confidential. It is intended solely for the addressees and access to this message by any other person is not 
permitted.
If you are not the named addressee, please send it back immediately to the sender and delete it. Unauthorized 
disclosure,
publication, use, dissemination, forwarding, printing or copying of this message, either in whole or in part, is 
strictly
prohibited.
Emails are susceptible to alteration and their integrity cannot be guaranteed. Our company shall not be liable for this
message if modified or falsified.