Preventing form injection on Classic ASP pages

[bregent]

I've seen plenty of articles and utilities for preventing form injections for
ASP.NET, but not too much for classic ASP. Are there any good input validation
scripts that you use to avoid form injection attacks? I'm looking for good
routines I can reuse on all of my form processing pages. Thanks.

[Bob Barrows [MVP]]

bregent wrote:

I've seen plenty of articles and utilities for preventing form
injections for ASP.NET, but not too much for classic ASP. Are there
any good input validation scripts that you use to avoid form
injection attacks? I'm looking for good routines I can reuse on all
of my form processing pages. Thanks.

"form injection"?
Do you mean cross-site scripting (XSS)?
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[Evertjan.]

bregent wrote on 10 feb 2006 in microsoft.public.inetserver.asp.general:

I've seen plenty of articles and utilities for preventing form
injections for ASP.NET, but not too much for classic ASP. Are there
any good input validation scripts that you use to avoid form injection
attacks? I'm looking for good routines I can reuse on all of my form
processing pages. Thanks.

If you do not mind loosing non-alphanumeric characters,
and don't have a user named O'Brien:

<script runat=server language=jscript>
function DesInjectString(s){
return s.replace(/[^a-z\d\.,-]+/ig,'?')
}
</script>

Not tested.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Anthony Jones]

Here are some rules to follow which will prevent injection attack.

Never build SQL code by string concatenation with input from the client.
Apply the above rule to code found inside Stored procedures.
Always pass input data to SQL code via Command object parameters.

Always call Server.HTMLEncode on data retrieved from the data base before
sending to the client.

Avoid using hidden fields to carry meaningful state that only the server
needs.
Instead store the state somewhere on the server (like in the DB) and send to
the client a unique (preferable use once only) ID.

Anthony.

[bregent]

In article <#y**************@TK2MSFTNGP15.phx.gbl>, Bob Barrows [MVP]"
<re******@NOyahoo.SPAMcom> says...

bregent wrote:

I've seen plenty of articles and utilities for preventing form
injections for ASP.NET, but not too much for classic ASP. Are there
any good input validation scripts that you use to avoid form
injection attacks? I'm looking for good routines I can reuse on all
of my form processing pages. Thanks.

"form injection"?
Do you mean cross-site scripting (XSS)?

No, I'm not too worried about XSS, just mainly sql and email injection.

[Bob Barrows [MVP]]

bregent wrote:

In article <#y**************@TK2MSFTNGP15.phx.gbl>, Bob Barrows [MVP]"
<re******@NOyahoo.SPAMcom> says...

bregent wrote:

I've seen plenty of articles and utilities for preventing form
injections for ASP.NET, but not too much for classic ASP. Are there
any good input validation scripts that you use to avoid form
injection attacks? I'm looking for good routines I can reuse on all
of my form processing pages. Thanks.

"form injection"?
Do you mean cross-site scripting (XSS)?

No, I'm not too worried about XSS, just mainly sql and email
injection.

For sql injection, simply avoid using concatenation to insert input values
into sql statements. use parameters instead. I strongly advise encapsulating
your queries in stored procedures, using parameters to pass the values to
them. However, if you are phobic about using stored procedures, you can use
this technique:
http://groups-beta.google.com/group/...e36562fee7804e

I still validate server-side, but that's mainly to discover the attack.
Using parameters prevents the attack even if my validation misses it.

For email-injection, I know of no way to prevent that outside of validation.
I'm surprised you haven't come up with any scripts in your google searches,
but the same techniques that work in .Net can usually be revised to work in
vbscript.

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

[bregent]

In article <u1**************@TK2MSFTNGP12.phx.gbl>, Bob Barrows [MVP]"
<re******@NOyahoo.SPAMcom> says...

bregent wrote:

In article <#y**************@TK2MSFTNGP15.phx.gbl>, Bob Barrows [MVP]"
<re******@NOyahoo.SPAMcom> says...

bregent wrote:
I've seen plenty of articles and utilities for preventing form
injections for ASP.NET, but not too much for classic ASP. Are there
any good input validation scripts that you use to avoid form
injection attacks? I'm looking for good routines I can reuse on all
of my form processing pages. Thanks.

"form injection"?
Do you mean cross-site scripting (XSS)?

No, I'm not too worried about XSS, just mainly sql and email
injection.

For sql injection, simply avoid using concatenation to insert input values
into sql statements. use parameters instead. I strongly advise encapsulating
your queries in stored procedures, using parameters to pass the values to
them. However, if you are phobic about using stored procedures, you can use
this technique:
http://groups-beta.google.com/group/...e36562fee7804e

Thanks Bob, I read that and the linked articles and am beginning to understand
how to implement these techniques. However, having never used the command
object, what I still don't understand is exactly HOW these methods protect
against an attack. How exactly do they prevent an attacker from inserting single
quotes and comment marks and other malicious code into a parameter?

[Bob Barrows [MVP]]

bregent wrote:

Thanks Bob, I read that and the linked articles and am beginning to
understand how to implement these techniques. However, having never
used the command object, what I still don't understand is exactly HOW
these methods protect against an attack. How exactly do they prevent
an attacker from inserting single quotes and comment marks and other
malicious code into a parameter?

They don't.
However, the fact that they are values being passed via parameter means that
they will be treated as values instead of pieces of strings that need to be
interpreted, so the inserted malicious code will simply be inserted into the
database table - the query engine will make no attempt to interpret or
execute the data.

To see this in action, use SQL Profiler to trace what occurs when using both
techniques.

Do not use the fact that you are using parameters to eliminate doing
validation. For one thing, you probably don't want that crappy data to be
inserted into your database. For another, the attempt to insert it may raise
an error (datatype mismatch, constraint violation, etc.) which you probably
should avoid. For another, you might want to consider "punishing" blatant
attacks - maybe redirect them to a page that takes 10 min. to load, etc.

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[Bob Barrows [MVP]]

Bob Barrows [MVP] wrote:

bregent wrote:

Thanks Bob, I read that and the linked articles and am beginning to
understand how to implement these techniques. However, having never
used the command object, what I still don't understand is exactly HOW
these methods protect against an attack. How exactly do they prevent
an attacker from inserting single quotes and comment marks and other
malicious code into a parameter?

They don't.
However, the fact that they are values being passed via parameter
means that they will be treated as values instead of pieces of
strings that need to be interpreted, so the inserted malicious code
will simply be inserted into the database table - the query engine
will make no attempt to interpret or execute the data.

I just thought of an analogy that may help.
vbscript has a method called Execute() which attempts to execute a string
passed to it. Create a page with this code and run it to see what i'm
talking about:

<%
Sub WriteText(sometext, moretext)
response.write server.HTMLEncode(sometext) & "<BR>" & _
server.HTMLEncode(moretext)
End Sub
dim s1, s2
s1="try"
s2="this "":response.write ""<script type='text/javascript'>" & _
"alert('something bad')</script>"" '"
WriteText s1,s2

Response.Write "<BR><BR>Now see the difference " & _
"using Execute()<BR><BR>"
dim stmt
stmt="WriteText """ & s1 & """, """ & s2 & """"
'Response.Write server.HTMLEncode(stmt) & "<BR><BR>"
Execute(stmt)
%>

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[Bob Barrows [MVP]]

Bob Barrows [MVP] wrote:

bregent wrote:

Thanks Bob, I read that and the linked articles and am beginning to
understand how to implement these techniques. However, having never
used the command object, what I still don't understand is exactly HOW
these methods protect against an attack. How exactly do they prevent
an attacker from inserting single quotes and comment marks and other
malicious code into a parameter?

They don't.
However, the fact that they are values being passed via parameter
means that they will be treated as values instead of pieces of
strings that need to be interpreted, so the inserted malicious code
will simply be inserted into the database table - the query engine
will make no attempt to interpret or execute the data.

Not sure if this went through the first time. Even if it did, I've revised
it to help make the distinction clearer:

<%
Response.Buffer=true
Sub WriteText(sometext, moretext)
response.write server.HTMLEncode(sometext) & "<BR>" & _
server.HTMLEncode(moretext)
End Sub
dim s1, s2
s1="try"
s2="this "":response.write ""<script type='text/javascript'>" & _
"alert('something bad')</script>"" '"
Response.Write "First, see the result of just calling the " & _
"sub, passing the text as argument values:<BR>"
WriteText s1,s2
Response.Write "<BR>See? No alert - text is simply written to page."
Response.Flush
dim i,t
t=now
do until datediff("s",t,now)>=4
loop
Response.Flush

Response.Write "<BR><BR>Now see the difference " & _
"using Execute()<BR><BR>"
Response.Flush
t=now
do until datediff("s",t,now)>=2
loop
dim stmt
stmt="WriteText """ & s1 & """, """ & s2 & """"
'Response.Write server.HTMLEncode(stmt) & "<BR><BR>"
Execute(stmt)
%>
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[bregent]

Makes sense now. Thanks for the help Bob!
In article <eb**************@TK2MSFTNGP09.phx.gbl>, Bob Barrows [MVP]"
<re******@NOyahoo.SPAMcom> says...

Bob Barrows [MVP] wrote:

bregent wrote:

Thanks Bob, I read that and the linked articles and am beginning to
understand how to implement these techniques. However, having never
used the command object, what I still don't understand is exactly HOW
these methods protect against an attack. How exactly do they prevent
an attacker from inserting single quotes and comment marks and other
malicious code into a parameter?

They don't.
However, the fact that they are values being passed via parameter
means that they will be treated as values instead of pieces of
strings that need to be interpreted, so the inserted malicious code
will simply be inserted into the database table - the query engine
will make no attempt to interpret or execute the data.

Not sure if this went through the first time. Even if it did, I've revised
it to help make the distinction clearer:

<%
Response.Buffer=true
Sub WriteText(sometext, moretext)
response.write server.HTMLEncode(sometext) & "<BR>" & _
server.HTMLEncode(moretext)
End Sub
dim s1, s2
s1="try"
s2="this "":response.write ""<script type='text/javascript'>" & _
"alert('something bad')</script>"" '"
Response.Write "First, see the result of just calling the " & _
"sub, passing the text as argument values:<BR>"
WriteText s1,s2
Response.Write "<BR>See? No alert - text is simply written to page."
Response.Flush
dim i,t
t=now
do until datediff("s",t,now)>=4
loop
Response.Flush

Response.Write "<BR><BR>Now see the difference " & _
"using Execute()<BR><BR>"
Response.Flush
t=now
do until datediff("s",t,now)>=2
loop
dim stmt
stmt="WriteText """ & s1 & """, """ & s2 & """"
'Response.Write server.HTMLEncode(stmt) & "<BR><BR>"
Execute(stmt)
%>