Is this code better than my earlier code, security wise

[Neil Gould]

Re: Is this code better than my earlier code, security wise

Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:

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

Re: Is this code better than my earlier code, security wise


"Neil Gould" <neil@terratu.c omwrote in message
news:%23PYWKXx0 IHA.5832@TK2MSF TNGP02.phx.gbl. ..

Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:
>

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

Re: Is this code better than my earlier code, security wise

Recently, Mike Brind [MVP] <paxtonend@hotm ail.composted:

"Neil Gould" <neil@terratu.c omwrote 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]]

Re: Is this code better than my earlier code, security wise


"Neil Gould" <neil@terratu.c omwrote in message
news:u6%23zDrz0 IHA.5944@TK2MSF TNGP04.phx.gbl. ..

Recently, Mike Brind [MVP] <paxtonend@hotm ail.composted:
>

>"Neil Gould" <neil@terratu.c omwrote 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]]

Re: Is this code better than my earlier code, security wise

Neil Gould wrote:

Recently, Mike Brind [MVP] <paxtonend@hotm ail.composted:
>

>"Neil Gould" <neil@terratu.c omwrote 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]

Re: Is this code better than my earlier code, security wise

Recently, Mike Brind [MVP] <paxtonend@hotm ail.composted:

"Neil Gould" <neil@terratu.c omwrote in message
news:u6%23zDrz0 IHA.5944@TK2MSF TNGP04.phx.gbl. ..

>Recently, Mike Brind [MVP] <paxtonend@hotm ail.composted:
>>

>>"Neil Gould" <neil@terratu.c omwrote 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]

Re: Is this code better than my earlier code, security wise

Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:

Neil Gould wrote:

>Recently, Mike Brind [MVP] <paxtonend@hotm ail.composted:
>>

>>"Neil Gould" <neil@terratu.c omwrote 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]]

Re: Is this code better than my earlier code, security wise

Neil Gould wrote:

Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:

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

Re: Is this code better than my earlier code, security wise

Hi Bob,

Thanks for your detailed reply.

Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:

Neil Gould wrote:

>Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:

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

Re: Is this code better than my earlier code, security wise

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.HTMLEnco de 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]

Re: Is this code better than my earlier code, security wise

Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:

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.HTMLEnco de 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]]

Re: Is this code better than my earlier code, security wise

Neil Gould wrote:

Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:
>

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

Re: Is this code better than my earlier code, security wise

Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:

Neil Gould wrote:

>Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:
>>

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

Re: Is this code better than my earlier code, security wise

Neil Gould wrote:

Recently, Bob Barrows [MVP] <reb01501@NOyah oo.SPAMcomposte d:
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.