SQL Injection Attack

All,
I am trying to test an attack against a web page. The VBScript runs 2
queries against the database; the first must succeed before the second
runs. Here is the code:

1st-
select * from users where (userid=' + @string + ') and password=' +
@pwdstring + '

2nd-
select * from permissions where userid=' + @string + '

When attempting the attack the problem lies in the "(" & ")"
surrounding the first userid string in the 1st query. if I attempt to
put a ")" in the original @string function to cancel out the first "("
it then causes problems for the second string. Also, the @pwdstring
gets encrypted before it is sent to the SQL Server, so attempting the
attack from that field is useless.

For instance:
@string = ' or 1=1)--
@pwdstring = blank (becomes @pwdstring = 55-12-567-3244-123 due to
encryption)

select * from users where (userid='' or 1=1)--') and
password='55-12-567-3244-123' WORKS OK
select * from permissions where userid='' or 1=1)--' DOES NOT WORK

Is this an instance where the original developers made a happy coding
error (I asked and preventing injection attacks wasn't intended) or is
there something I can do to circumvent this?

Thanks,
josh

joshsackett (joshsackett@gmail.com)  writes:
> For instance:
> @string = ' or 1=1)--
> @pwdstring = blank (becomes @pwdstring = 55-12-567-3244-123 due to
> encryption)
>
> select * from users where (userid='' or 1=1)--') and
> password='55-12-567-3244-123' WORKS OK
> select * from permissions where userid='' or 1=1)--' DOES NOT WORK
>
> Is this an instance where the original developers made a happy coding
> error (I asked and preventing injection attacks wasn't intended) or is
> there something I can do to circumvent this?

I am afraid that I don't understand. There may or may not be a string
that can be used for both queries, but both of them are open to SQL
injection, and that's bad enough. You make it like SQL injection is a
desired feature, but find it difficult to understand such requirements.


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

I don't understand either - why don't you just use a stored procedure
i.e. the recommended approach?

This is cleaner, simpler and does not offer any possibility for a SQL
injection attack.

Malc
www.dbghost.com

Malcolm  wrote:
> I don't understand either - why don't you just use a stored procedure
> i.e. the recommended approach?
>
> This is cleaner, simpler and does not offer any possibility for a SQL
> injection attack.
>
> Malc
> www.dbghost.com

Using prepared statments seems to be another approach that does not suffer
this risk.

robert

I suppose I didn't make myself entirely clear.. I have been contracted
to find vulnerabilities in a customer's web page. I examined their code
and found this login page to be an excellent candidate to display to
them what a SQL injection attack is. Once I prove to them that it is
simple to hack directly into their database using an attack I am going
to suggest changing the code to a stored procedure (as well as checking
the text fields for invalid characters).

I just cannot thing of a @string that satisfies both queries.

On 24 May 2005 10:29:50 -0700, joshsackett wrote:

>I suppose I didn't make myself entirely clear.. I have been contracted
>to find vulnerabilities in a customer's web page. I examined their code
>and found this login page to be an excellent candidate to display to
>them what a SQL injection attack is. Once I prove to them that it is
>simple to hack directly into their database using an attack I am going
>to suggest changing the code to a stored procedure (as well as checking
>the text fields for invalid characters).
>
>I just cannot thing of a @string that satisfies both queries.

Hi Josh,

If you need to demonstrate the harm that can be done, try

set @string = ''') drop table permissions --'

Or

set @string = ''') shutdown with nowait --'



Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)

Hugo Kornelis (hugo@pe_NO_rFact.in_SPAM_fo)  writes:
> set @string = ''') shutdown with nowait --'

That one is good! Then Josh does not need to worry about the syntax
error in the second statement, because there will be no server that
can detect it!

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Hugo - Thank you!
I can't believe I totally overlooked the obvious. I appreciate the help!