Is this code better than my earlier code, security wise

[Joey Martin]

One of my servers got hacked with the SQL injection due to poor coding.
So, I had someone write a stored procedure and new code.

But, to me, it looks just as flawed, even using the stored procedure.

email=request("email")
password=request("pw")

OLD CODE:
sql="select * from tablename where email='" & email & "' and password='"
& password & "'"
set rs=conn.execute(sql)

NEW CODE
sql="sp_CheckLogin '" & email & "','" & password & "'"
set rs=conn.execute(sql)

Stored Procedure:
CREATE PROCEDURE sp_CheckLogin
@Email VARCHAR(100), @Password VARCHAR(100)
AS
SELECT * FROM tablename WHERE email=@Email AND Password=@Password
GO
Thanks for your help!!
*** Sent via Developersdex http://www.developersdex.com ***

[Bob Barrows [MVP]]

Joey Martin wrote:

One of my servers got hacked with the SQL injection due to poor
coding. So, I had someone write a stored procedure and new code.

But, to me, it looks just as flawed, even using the stored procedure.

email=request("email")
password=request("pw")

OLD CODE:
sql="select * from tablename where email='" & email & "' and
password='" & password & "'"
set rs=conn.execute(sql)

NEW CODE
sql="sp_CheckLogin '" & email & "','" & password & "'"
set rs=conn.execute(sql)

Yes, it is just as flawed.You need to use parameters. Like this:

set rs=createobject("adodb.recordset")
conn.sp_CheckLogin email,password, rs

In addition:
Nothing to do with your problem, but you should avoid using the "sp_"
prefix for your stored procedures. "sp_" indicates to the query engine
that the procedure is a system stored procedure, which means that it
will waste time by first looking for the procedure in the Master
database, only looking in the current database when it is not found in
Master. Granted, the time wasted in very small, but the real problem
comes in when you give your procedure the same name as a current system
procedure. You will find that the system procedure will inexplicably be
executed when you attempt to call your procedure. Instead of trying to
remember to avoid names that conflict with system procedure names, you
can make your life a lot simpler by simply never using "sp_" to prefix
your procedure names unless you are creating a system procedure.


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

[Joey Martin]

Thanks for the information.
In my old code, I was able to successfully run sample sql injection
hacks. In the new SP code, those same sample hacks did not work. In that
case, is it still flawed?

Thanks again.

*** Sent via Developersdex http://www.developersdex.com ***

[Bob Barrows [MVP]]

Joey Martin wrote:

Thanks for the information.
In my old code, I was able to successfully run sample sql injection
hacks. In the new SP code, those same sample hacks did not work. In
that case, is it still flawed?

If you are using & to create dynamic sql statements, then yes, it is
flawed and you are simply not using the hack that exposes the flaw.
Use parameters!
And validate all inputs before using them.

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

[=?Utf-8?B?T2xkIFBlZGFudA==?=]

In my old code, I was able to successfully run sample sql injection

hacks. In the new SP code, those same sample hacks did not work. In that
case, is it still flawed?

Try something like this with your new code:

password = "foo'; exec sp_HelpText sp_CheckLogin;"

sql="sp_CheckLogin '" & email & "','" & password & "'"
set rs=conn.execute(sql)
set rs = rs.NextRecordSet
Do Until rs.EOF
Response.Write rs(0) & "<br/>"
rs.MoveNext
Loop

Hmmm?? What happens?

[Joey Martin]

I see your point, but as far as the latest SQL Injection attacks, would
something like that be common?

*** Sent via Developersdex http://www.developersdex.com ***

[Daniel Crichton]

Joey wrote on Thu, 19 Jun 2008 19:33:24 -0700:

I see your point, but as far as the latest SQL Injection attacks, would
something like that be common?

Why bother coding for a specific type of injection attack just because
that's what you're seeing in your logs? You want to code to avoid injection
full stop, otherwise what happens next week when someone comes to your site
and tries out a simple one like the example and ruins your database?

--
Dan

[Joey Martin]

Thanks again.

Ok, so by adding this:
set rs=createobject("adodb.recordset")
conn.sp_CheckLogin email,password, rs
instead of this:
sql="sp_CheckLogin '" & email & "','" & password & "'"
set rs=conn.execute(sql)
makes it secure?? If so, I have done it and it works. Just confirming so
I can go thru my other login pages.

*** Sent via Developersdex http://www.developersdex.com ***

[Bob Barrows [MVP]]

Joey Martin wrote:

Thanks again.

Ok, so by adding this:
set rs=createobject("adodb.recordset")
conn.sp_CheckLogin email,password, rs
instead of this:
sql="sp_CheckLogin '" & email & "','" & password & "'"
set rs=conn.execute(sql)
makes it secure?? If so, I have done it and it works. Just confirming
so I can go thru my other login pages.

Yes. Try the Pedant's simple example. Because this technique I suggested
(commonly called the "procedure-as-connection-method technique) passes
values by parameters, the query engine will not attempt to parse and execute
the injected sql. Here is the difference:

When you cobble together a sql statement by concatenating separate strings
together and pass it to a database, you are leaving it up to the database to
treat it the same way it would handle any statement or set of batched
statements handed to it: i.e., it parses the statement(s), and if valid,
compiles a plan and executes the statements, no matter what destructive
actions they perform - hey, you handed this statement to it - you must know
what you are doing, right?

When using parameters on the other hand, you are handing the database a
"tokenized" sql statement or a stored procedure to execute, along with
values for it to substitute for the tokens (or pass as parameters to the
procedure). So it only parses and compiles a plan (if one is not found in
cache) for the sql statement, and then substitutes the tokens with the
supplied values (or passes the values as arguments to the procedure), making
no attempt to parse or execute those supplied values.

So yes, using parameters will foil all primary sql injection attempts.

But you need to go beyond that. If you do not validate all user inputs, you
will wind up with data filled with sql injection attempts. And if you use
that data in dynamic sql in oter places, then you will wind up accomplishing
the hacker's purpose yourself. This is known as "secondary sql injection".

Also, the procedure that was written for you properly uses the parameters in
the sql statement it executes:
WHERE email=@Email AND Password=@Password

See? it's a tokenized sql statement, so passed parameter values will not be
executed.

If, on the other hand, the person who wrote the procedure did something like
this:

set @sql = 'select ... where email=''' + @email + ''''
execute(@sql)

Then you are back at square one: any sql injected into that @email parameter
value will be parsed and executed.
So, when I say that dynamic sql should be avoided, I mean to say it should
be avoided everywhere: in client code and in stored procedure code.

There are situations where dynamic sql cannot be avoided (when you need to
specify column or field names dynamically). In these situations, proper
validation is essential. You must reat the passed data and verify it
contains nothing untoward BEFORE using it in dynamic sql.
--
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"

[Joey Martin]

Again, a HUGE thank you to all of you.

*** Sent via Developersdex http://www.developersdex.com ***

[Joey Martin]

Again, a HUGE thank you to all of you.

*** Sent via Developersdex http://www.developersdex.com ***

[Neil Gould]

Recently, Old Pedant <Ol*******@discussions.microsoft.composted:

>In my old code, I was able to successfully run sample sql injection
hacks. In the new SP code, those same sample hacks did not work. In
that case, is it still flawed?

Try something like this with your new code:

password = "foo'; exec sp_HelpText sp_CheckLogin;"

sql="sp_CheckLogin '" & email & "','" & password & "'"
set rs=conn.execute(sql)
set rs = rs.NextRecordSet
Do Until rs.EOF
Response.Write rs(0) & "<br/>"
rs.MoveNext
Loop

Hmmm?? What happens?

How is this "tried"? Is it entered into a form field, or somehow executed
as ASP remotely?

Neil

[Bob Barrows [MVP]]

Neil Gould wrote:

Recently, Old Pedant <Ol*******@discussions.microsoft.composted:

>>In my old code, I was able to successfully run sample sql injection
hacks. In the new SP code, those same sample hacks did not work. In
that case, is it still flawed?

Try something like this with your new code:

password = "foo'; exec sp_HelpText sp_CheckLogin;"

sql="sp_CheckLogin '" & email & "','" & password & "'"
set rs=conn.execute(sql)
set rs = rs.NextRecordSet
Do Until rs.EOF
Response.Write rs(0) & "<br/>"
rs.MoveNext
Loop

Hmmm?? What happens?

How is this "tried"? Is it entered into a form field, or somehow
executed as ASP remotely?

It's just executed as is in server-side code as a test. It is supposed to
simulate a hacker entering "foo'; exec sp_HelpText sp_CheckLogin;" into a
form textbox and submitting 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"

[Neil Gould]

Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

Neil Gould wrote:

>Recently, Old Pedant <Ol*******@discussions.microsoft.composted:

>>>In my old code, I was able to successfully run sample sql injection
hacks. In the new SP code, those same sample hacks did not work. In
that case, is it still flawed?

Try something like this with your new code:

password = "foo'; exec sp_HelpText sp_CheckLogin;"

sql="sp_CheckLogin '" & email & "','" & password & "'"
set rs=conn.execute(sql)
set rs = rs.NextRecordSet
Do Until rs.EOF
Response.Write rs(0) & "<br/>"
rs.MoveNext
Loop

Hmmm?? What happens?

How is this "tried"? Is it entered into a form field, or somehow
executed as ASP remotely?

It's just executed as is in server-side code as a test. It is
supposed to simulate a hacker entering "foo'; exec sp_HelpText
sp_CheckLogin;" into a form textbox and submitting it.

I see. I was somewhat concerned that there may be some way "in" to the
server-side code from a browser.

Wouldn't it be good practice to parse & qualify form submissions before
executing any SQL statements? That way, even legitimate entry errors could
be trapped and dealt with appropriately.

Neil

[Bob Barrows [MVP]]

Neil Gould wrote:

Wouldn't it be good practice to parse & qualify form submissions
before executing any SQL statements? That way, even legitimate entry
errors could be trapped and dealt with appropriately.

Absolutely. I believe I have recommended this several times in this thread.

However, this should only be part of your defensive strategy. The most
airtight defense to sql injection is to never give it a chance to occur.
Since sql injection depends on the use of dynamic sql, then logically, sql
injection attempts can never work if you never use dynamic sql. Of course,
the alternative it to use parameters.

Read my other posts in this thread.

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

[Neil Gould]

Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

Neil Gould wrote:

>Wouldn't it be good practice to parse & qualify form submissions
before executing any SQL statements? That way, even legitimate entry
errors could be trapped and dealt with appropriately.

Absolutely. I believe I have recommended this several times in this
thread.

However, this should only be part of your defensive strategy. The most
airtight defense to sql injection is to never give it a chance to
occur. Since sql injection depends on the use of dynamic sql, then
logically, sql injection attempts can never work if you never use
dynamic sql. Of course, the alternative it to use parameters.

Read my other posts in this thread.

I've followed this thread with interest, and even looked into the
references that you cited.

Having been involved with database design for the last 3+ decades, I think
that much of what is said is just a important for "closed" systems that
have no opportunity to be hacked.

What I'm new to is integrating database functions with ASP, so my security
concerns are mostly in the area of unwanted access to server-side code by
client-side apps or actions.

Neil

[Mike Brind [MVP]]

"Neil Gould" <ne**@terratu.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

>Neil Gould wrote:

>>Wouldn't it be good practice to parse & qualify form submissions
before executing any SQL statements? That way, even legitimate entry
errors could be trapped and dealt with appropriately.

Absolutely. I believe I have recommended this several times in this
thread.

However, this should only be part of your defensive strategy. The most
airtight defense to sql injection is to never give it a chance to
occur. Since sql injection depends on the use of dynamic sql, then
logically, sql injection attempts can never work if you never use
dynamic sql. Of course, the alternative it to use parameters.

Read my other posts in this thread.

I've followed this thread with interest, and even looked into the
references that you cited.

Having been involved with database design for the last 3+ decades, I think
that much of what is said is just a important for "closed" systems that
have no opportunity to be hacked.

What I'm new to is integrating database functions with ASP, so my security
concerns are mostly in the area of unwanted access to server-side code by
client-side apps or actions.

Be aware that client-side actions can include tampering with querystring
values, saving a local copy of a form, amending the form fields and
submitting it from eg your Desktop etc.

--
Mike Brind
Microsoft MVP - ASP/ASP.NET

[Neil Gould]

Recently, Mike Brind [MVP] <pa*******@hotmail.composted:

"Neil Gould" <ne**@terratu.comwrote in message

>[...]
What I'm new to is integrating database functions with ASP, so my
security concerns are mostly in the area of unwanted access to
server-side code by client-side apps or actions.

Be aware that client-side actions can include tampering with
querystring values, saving a local copy of a form, amending the form
fields and submitting it from eg your Desktop etc.

Yes, I am aware of those possibilities, and that is why I'm curious about
other such opportunities.

Offhand, though, I don't know what advantage there would be to amending
form fields unless there is also some access to the code that the form
calls. If someone changes the field names in the form without such access,
the form submission should just fail. Added fields should have no impact,
as there isn't code to support the new fields. Any examples of the kind of
risk you had in mind?

Neil

[Mike Brind [MVP]]

"Neil Gould" <ne**@terratu.comwrote in message
news:u6****************@TK2MSFTNGP04.phx.gbl...

Recently, Mike Brind [MVP] <pa*******@hotmail.composted:

>"Neil Gould" <ne**@terratu.comwrote in message

>>[...]
What I'm new to is integrating database functions with ASP, so my
security concerns are mostly in the area of unwanted access to
server-side code by client-side apps or actions.

Be aware that client-side actions can include tampering with
querystring values, saving a local copy of a form, amending the form
fields and submitting it from eg your Desktop etc.

Yes, I am aware of those possibilities, and that is why I'm curious about
other such opportunities.

Offhand, though, I don't know what advantage there would be to amending
form fields unless there is also some access to the code that the form
calls. If someone changes the field names in the form without such access,
the form submission should just fail. Added fields should have no impact,
as there isn't code to support the new fields. Any examples of the kind of
risk you had in mind?

LOL. Straight off the top of my head, I once found a site that had the
actual SQL that was being executed stored in a hidden field. Get the
picture?

--
Mike Brind
Microsoft MVP - ASP/ASP.NET

[Bob Barrows [MVP]]

Neil Gould wrote:

Recently, Mike Brind [MVP] <pa*******@hotmail.composted:

>"Neil Gould" <ne**@terratu.comwrote in message

>>[...]
What I'm new to is integrating database functions with ASP, so my
security concerns are mostly in the area of unwanted access to
server-side code by client-side apps or actions.

Be aware that client-side actions can include tampering with
querystring values, saving a local copy of a form, amending the form
fields and submitting it from eg your Desktop etc.

Yes, I am aware of those possibilities, and that is why I'm curious
about other such opportunities.

Offhand, though, I don't know what advantage there would be to
amending form fields unless there is also some access to the code
that the form calls. If someone changes the field names in the form
without such access, the form submission should just fail. Added
fields should have no impact, as there isn't code to support the new
fields. Any examples of the kind of risk you had in mind?

I've seen people try to create generic form processing pages that looped
through submitted form fields, dynamically creating variables to contain the
submitted data ... ugh!

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

[Neil Gould]

Recently, Mike Brind [MVP] <pa*******@hotmail.composted:

"Neil Gould" <ne**@terratu.comwrote in message
news:u6****************@TK2MSFTNGP04.phx.gbl...

>Recently, Mike Brind [MVP] <pa*******@hotmail.composted:

>>"Neil Gould" <ne**@terratu.comwrote in message
[...]
What I'm new to is integrating database functions with ASP, so my
security concerns are mostly in the area of unwanted access to
server-side code by client-side apps or actions.
Be aware that client-side actions can include tampering with
querystring values, saving a local copy of a form, amending the form
fields and submitting it from eg your Desktop etc.

Yes, I am aware of those possibilities, and that is why I'm curious
about other such opportunities.

Offhand, though, I don't know what advantage there would be to
amending form fields unless there is also some access to the code
that the form calls. If someone changes the field names in the form
without such access, the form submission should just fail. Added
fields should have no impact, as there isn't code to support the new
fields. Any examples of the kind of risk you had in mind?

LOL. Straight off the top of my head, I once found a site that had
the actual SQL that was being executed stored in a hidden field. Get
the picture?

Ah. That sounds like something my clients might pay for. And, worth both
pennies they paid, too! ;-)

Neil

[Neil Gould]

Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

Neil Gould wrote:

>Recently, Mike Brind [MVP] <pa*******@hotmail.composted:

>>"Neil Gould" <ne**@terratu.comwrote in message
[...]
What I'm new to is integrating database functions with ASP, so my
security concerns are mostly in the area of unwanted access to
server-side code by client-side apps or actions.
Be aware that client-side actions can include tampering with
querystring values, saving a local copy of a form, amending the form
fields and submitting it from eg your Desktop etc.

Yes, I am aware of those possibilities, and that is why I'm curious
about other such opportunities.

Offhand, though, I don't know what advantage there would be to
amending form fields unless there is also some access to the code
that the form calls. If someone changes the field names in the form
without such access, the form submission should just fail. Added
fields should have no impact, as there isn't code to support the new
fields. Any examples of the kind of risk you had in mind?

I've seen people try to create generic form processing pages that
looped through submitted form fields, dynamically creating variables
to contain the submitted data ... ugh!

Are there are examples of access to code that is not stored in the form
itself (a rather curious practice for SO many reasons)? Is there any other
reason to be concerned about the structure of a query if the form entry
data is being parsed? Is server-side code actually protected from view by
all apps or hacker tools?

Inquiring minds want to know!

Neil

[Bob Barrows [MVP]]

Neil Gould wrote:

Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

>I've seen people try to create generic form processing pages that
looped through submitted form fields, dynamically creating variables
to contain the submitted data ... ugh!

Are there are examples of access to code that is not stored in the
form itself (a rather curious practice for SO many reasons)?

Huh? I'm not sure I understand the question (or why it's a "curious
practice"). Are you talking about server-side or client-side code?
Server-side code should never be revealed to a client by a properly
configured server. One case where it might be:

SSI (server-side includes) contained in files with extensions that the
server allows to be served rather than executed. (.inc, for example -
not everyone remembers to add .inc to the asp.dll mapping list with the
result that a user could navigate to the .inc file and see the code it
contains). This is why you often seee the advice to put you SSI code in
..asp files rather than .inc.

Basically, as long as all server-side code is contained in files whose
extensions are in the mapping list, then it is secure from inadvertant
browsing.

Is there
any other reason to be concerned about the structure of a query if
the form entry data is being parsed?

Yes, see my post about secondary sql injection. User inputs do not come
solely from form data submissions.
Also, your data may need to include sql keywords so you cannot always
parse them out.
And lastly, it's not just sql that they attempt to inject: the latest
exploit involved injecting javascript code that executed when sent to
the client.

It sounds like you are trying to justify the use of dynamic sql when you
should really be avoiding it. Parameter-use stops sql injection dead in
its tracks. Using parameters allows you to concentrate your data
validation efforts on avoiding datatype mismatch errors and business
rule violations. If you want to detect injection attempts, perhaps to
log them or to give the hacker a smack on the wrist, then concentrate on
the low-hanging fruit: don't try to create a validation routine that
catches all the various methods hackers have used to attempt to inject
sql: for one thing, it's a long list and you may not be aware of all the
techniques that have been tried, and two, they are always trying new
techniques that have not been documented.

Is server-side code actually
protected from view by all apps or hacker tools?

It should be, if the server is configured correctly. With the proviso
that if a hacker gains physical access to a server (or filesystem
access) then all bets are off.

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

[Neil Gould]

Hi Bob,

Thanks for your detailed reply.

Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

Neil Gould wrote:

>Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

>>I've seen people try to create generic form processing pages that
looped through submitted form fields, dynamically creating variables
to contain the submitted data ... ugh!

Are there are examples of access to code that is not stored in the
form itself (a rather curious practice for SO many reasons)?

Huh? I'm not sure I understand the question (or why it's a "curious
practice").

I find it a "curious practice" because such an approach would be nearly
impossible to parse for valid inputs. So, even in the case of legitimate
access to the database, there is the possibility of invalid data being
stored.

SSI (server-side includes) contained in files with extensions that the
server allows to be served rather than executed. (.inc, for example -
not everyone remembers to add .inc to the asp.dll mapping list with
the result that a user could navigate to the .inc file and see the
code it contains). This is why you often seee the advice to put you
SSI code in .asp files rather than .inc.

Basically, as long as all server-side code is contained in files whose
extensions are in the mapping list, then it is secure from inadvertant
browsing.

Thanks. This answers my basic question adequately.

>Is there
any other reason to be concerned about the structure of a query if
the form entry data is being parsed?

Yes, see my post about secondary sql injection. User inputs do not
come solely from form data submissions.

I can only think of a couple of methods: form sumbissions or site-related
buttons that move from one page to another. What other user input were you
referring to?

Also, your data may need to include sql keywords so you cannot always
parse them out.
And lastly, it's not just sql that they attempt to inject: the latest
exploit involved injecting javascript code that executed when sent to
the client.

Well, I would think that javascript code could only be passed if the data
input was not parsed.

It sounds like you are trying to justify the use of dynamic sql when
you should really be avoiding it.

I'm not trying to justify anything... I'm trying to fully understand the
issues at hand.

Parameter-use stops sql injection
dead in its tracks. Using parameters allows you to concentrate your
data validation efforts on avoiding datatype mismatch errors and
business rule violations. If you want to detect injection attempts,
perhaps to log them or to give the hacker a smack on the wrist, then
concentrate on the low-hanging fruit: don't try to create a
validation routine that catches all the various methods hackers have
used to attempt to inject sql: for one thing, it's a long list and
you may not be aware of all the techniques that have been tried, and
two, they are always trying new techniques that have not been
documented.

This is good advice, and I completely agree with it and in fact *do*
employ parameter-use, but for different reasons. What I'm trying to
understand is why the code examples given by you and pedant would be
passed by parsed input in the first place. For example, if a data field
for the submission is 10 alpha-numeric characters, then anything else
would get trapped unless there is some way to bypass that restriction.
That is what I want to know more about ASP.

Best,

Neil

[Bob Barrows [MVP]]

Neil Gould wrote:

>Yes, see my post about secondary sql injection. User inputs do not
come solely from form data submissions.

I can only think of a couple of methods: form sumbissions or
site-related buttons that move from one page to another. What other
user input were you referring to?

Data that was submitted by users and now resides in database fields or
some other supposedly safe storage area.

>Also, your data may need to include sql keywords so you cannot always
parse them out.
And lastly, it's not just sql that they attempt to inject: the latest
exploit involved injecting javascript code that executed when sent to
the client.

Well, I would think that javascript code could only be passed if the
data input was not parsed.

Again, you are talking about complicated parsing. Instead, when using
the data that was submitted by users, consider using the
server.HTMLEncode when writing it to Response.
There are so many ways to disguise script that you could easily miss one
of the ways.

This is good advice, and I completely agree with it and in fact *do*
employ parameter-use, but for different reasons. What I'm trying to
understand is why the code examples given by you and pedant would be
passed by parsed input in the first place. For example, if a data
field for the submission is 10 alpha-numeric characters, then
anything else would get trapped unless there is some way to bypass
that restriction. That is what I want to know more about ASP.

Ah, but that 10-character alphanumeric restriction covers a huge amount
of ground. If you are concatenating that to a sql statement that filters
results by it, what's to prevent a user from doing this to you?

sql = sql & "tst or 1=1"

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

[Neil Gould]

Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

Neil Gould wrote:

>>Yes, see my post about secondary sql injection. User inputs do not
come solely from form data submissions.

I can only think of a couple of methods: form sumbissions or
site-related buttons that move from one page to another. What other
user input were you referring to?

Data that was submitted by users and now resides in database fields or
some other supposedly safe storage area.

To get into the database fields, that data was submitted via forms, no?

I am curious about the "...other supposedly safe storage area". If one can
place user input into those areas, could they also extract, for example,
ASP code from those areas; in other words, doesn't that require read/write
permissions?

>>Also, your data may need to include sql keywords so you cannot
always parse them out.
And lastly, it's not just sql that they attempt to inject: the
latest exploit involved injecting javascript code that executed
when sent to the client.

Well, I would think that javascript code could only be passed if the
data input was not parsed.

Again, you are talking about complicated parsing. Instead, when using
the data that was submitted by users, consider using the
server.HTMLEncode when writing it to Response.
There are so many ways to disguise script that you could easily miss
one of the ways.

Well, you do know how to worry a guy! ;-)

>This is good advice, and I completely agree with it and in fact *do*
employ parameter-use, but for different reasons. What I'm trying to
understand is why the code examples given by you and pedant would be
passed by parsed input in the first place. For example, if a data
field for the submission is 10 alpha-numeric characters, then
anything else would get trapped unless there is some way to bypass
that restriction. That is what I want to know more about ASP.

Ah, but that 10-character alphanumeric restriction covers a huge
amount of ground. If you are concatenating that to a sql statement
that filters results by it, what's to prevent a user from doing this
to you?

sql = sql & "tst or 1=1"

The =, ", &, and blank spaces are neither alpha nor numbers, and the
length of that string is 10. Parsing the above does not require much
code, and is not at all compicated.

Neil

[Bob Barrows [MVP]]

Neil Gould wrote:

Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

>Neil Gould wrote:

>>>Yes, see my post about secondary sql injection. User inputs do not
come solely from form data submissions.

I can only think of a couple of methods: form sumbissions or
site-related buttons that move from one page to another. What other
user input were you referring to?

Data that was submitted by users and now resides in database fields
or some other supposedly safe storage area.

To get into the database fields, that data was submitted via forms,
no?

If that's the source, yes. You could also be reading text out of an
uploaded document, or getting values from a querystring, etc.

When a programmer opens a recordset on that table, will he consider it
to be safe data that needs no validation? Or will he correctly treat it
the same way he would treat data coming from a form field?

>
I am curious about the "...other supposedly safe storage area".

I am talking about text files, application variables, etc. Places where
asp server-side code can store data which subsequent programmers may
wrongly consider to be safe, i.e, risk-free.

If
one can place user input into those areas, could they also extract,
for example, ASP code from those areas;

Only if they can trick your server-side code into doing it. And no, I
have no examples of this. It would take a, shall we say, daredevil
programmer using Eval or Execute directly with user input to even
approach allowing a user to do something like this. Let's move on. Users
cannot modify/read/execute server-side code without the programmer
allowing them to do so.

>>
sql = sql & "tst or 1=1"

The =, ", &, and blank spaces are neither alpha nor numbers,

Really? Only if your parser eliminates those characters. What if your
application needs the data to be able to contain those characters?

and the
length of that string is 10.

sigh
The data gotten from the user consisted solely of these ten characters:
tst or 1=1

Parsing the above does not require much
code, and is not at all compicated.

Are you saying you intend to write different parsing routines based on
the size of the fields involved?

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

[Neil Gould]

Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

Neil Gould wrote:

>Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:

>>Neil Gould wrote:
Yes, see my post about secondary sql injection. User inputs do not
come solely from form data submissions.
>
I can only think of a couple of methods: form sumbissions or
site-related buttons that move from one page to another. What other
user input were you referring to?

Data that was submitted by users and now resides in database fields
or some other supposedly safe storage area.

To get into the database fields, that data was submitted via forms,
no?

If that's the source, yes. You could also be reading text out of an
uploaded document, or getting values from a querystring, etc.

Reading text I understand, and if doing so, it would require some rigorous
qualification.

Getting values from a querystring sounds outside the realm of what we're
talking about, since allowing external input from querystrings is risky
business at best.

When a programmer opens a recordset on that table, will he consider it
to be safe data that needs no validation? Or will he correctly treat
it the same way he would treat data coming from a form field?

Well, GIGO applies here, too. If the database _can't_ be corrupted by
invalid input (legitimate or malicious), one can be more trustful than if
the data input is unverified.

I'm primarily interested in preventing hijacking, and have seen some
occurances that concern me.

>I am curious about the "...other supposedly safe storage area".

I am talking about text files, application variables, etc. Places
where asp server-side code can store data which subsequent
programmers may wrongly consider to be safe, i.e, risk-free.

This is at the heart of my concern.

>If
one can place user input into those areas, could they also extract,
for example, ASP code from those areas;

Only if they can trick your server-side code into doing it. And no, I
have no examples of this. It would take a, shall we say, daredevil
programmer using Eval or Execute directly with user input to even
approach allowing a user to do something like this. Let's move on.
Users cannot modify/read/execute server-side code without the
programmer allowing them to do so.

I'll breathe a sigh of relief.

[...]

>sql = sql & "tst or 1=1"

[...]

The data gotten from the user consisted solely of these ten
characters: tst or 1=1

Ah. I saw your example as something one might enter into a field to append
a query.

>Parsing the above does not require much
code, and is not at all compicated.

Are you saying you intend to write different parsing routines based on
the size of the fields involved?

No, based on the valid content for a field. The parsing routine can be a
single function, and the field parameters can be stored in an array or
such and looped to qualify a form. I realize that this doesn't guarantee
valid input, but the data needs to at least be qualified.

Neil

[Bob Barrows [MVP]]

Neil Gould wrote:

Recently, Bob Barrows [MVP] <re******@NOyahoo.SPAMcomposted:
I realize that this
doesn't guarantee valid input, but the data needs to at least be
qualified.

..
I never said it didn't. I was trying to explain why this was not the
only layer of security you should be using.
Anyways, it looks as if we are in agreement.

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