Is this code better than my earlier code, security wise

[Neil Gould]

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

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

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.

 

[Bob Barrows [MVP]]

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.

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"

 

[Neil Gould]

Hi Bob,

Thanks for your detailed reply.

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.

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

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.

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?

 

[Neil Gould]

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?

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! ;-)

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

 

[Neil Gould]

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

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.

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

Recently, Bob Barrows [MVP] <[email protected]> posted:
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.