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.
