Possible hacking of my ASP form - Need advice

[Jim]

Hi,

I keep getting form results emailed to me that would indicate a form
from my web site is getting submitted with all fields blank or empty,
but my code should preventing users from proceeding if they left any
field blank. My guess is that someone is trying to hack the site
using the form to gain entry or run commands -- I don't really know
since I'm not a hacker. I just know that forms are often susceptible
to these kinds of attacks.

I was hoping someone could shed some light on what may be happening
and how I may best try to prevent such things. I would think that
even if they entered various commands or whatnot into the form that I
might get some of those commands back in the results, but instead
every field comes back empty.

Any ideas?
Thanks!
Jim

 

[Curt_C [MVP]]

www.aspfaq.com has a bunch of good stuff on preventing SQL Injection attacks

 

[only me]

only accept forms submitted from your own servers IP add should reduce
possibility of external attack

 

[Jim]

From: jason ([email protected])
Thanks for the tip, but I'm not using session variables.
attacks

Sorry, I should have mentioned, I am not using a database. This is
just a very simple html form with a script to email me the results
with CDONTS.

Good question. It's just a simple validation script that checks to
see if any field was left empty and if so, rebuilds the form with an
error message requesting that the field(s) be filled out. I can't
seem to break it when testing, but then again I don't think like a

The only way I know to do this with a dynamic IP is to check the
Referer variable, but since my host disables this variable for some
unknown reason, I can't do that. Is there another way?

I appreciate all the tips and suggestions so far. What else should I
look for?

Thanks again.
Jim

 

[Jeff Cochran]

Good question. It's just a simple validation script that checks to
see if any field was left empty and if so, rebuilds the form with an
error message requesting that the field(s) be filled out. I can't
seem to break it when testing, but then again I don't think like a
hacker, and I guess that's part of the problem <g>.

Server side or client side? If this is client side, as in a
JavaScript validation, it's quite simple for a hacker to read the code
and bypass it. Make sure you *also* validate on the server side. In
your case, a simple check to see if the field contains A-Z and 0-9
might be enough. On a failure, simply reload the original page,
perhaps with a message to fill in all fields with A-Z or 0-9.

Jeff

 

[Jim]

The form is validated on the server side with an ASP/vbscript page
that recreates the original form with an error message if needed.

Numeric, email and date fields are all validated specifically, but
gereric text fields were not. I guess I'll add a check to my
validation script to check for characters like the following
!^*()_+='`~\|]}[{;:/?.<>&%.

Do I need to worry about dashes, underscores, commas, & periods?
Those I'd like to allow.

Also, some international addresses (something the form may collect)
contain forwardslashes or backslashes. I can imagine they could prove
troublesome, but how do I deal with this? I'd like to allow those if
it's safe to do so.

Something else that came to mind is the form conatins hidden fields
whose values are also getting returned empty. How could this be since
the user never sees or gets to change them?

Lastly, could I be barking up the wrong tree thinking this is a form
hack? Since the form uses CDONTS to email me the results, and CDONTS
doesn't validate users, could a spammer have found a way to send out
spam through this page/form and the blank results I get are just a
by-product? Just a guess.

Thanks,
Jim

 

[Jim]

Is there a list of characters that should ALWAYS be avoided in
forms/text boxes for security reasons? I can see right away how
quotation marks, semicolons, greater than & less than brackets and
backslashes could be problematic. What are some others to be wary of?

How do I handle the fact that in a few cases I will need to accept
backslashes, Apostrophes, Number/Pound symbol, and possibly a select
few other non-alphanumeric characters?

Will htmlencoding help prevent hacking, or will it be too late since
the validation is server side and code could get run before validation
is complete?

Thanks,
Jim

P.S. My form is validated on the server side with an ASP/vbscript page
that recreates the original form with an error message if needed. I
am not using any database. I am just gathering the form text and
having the results sent to my email.

The form is validated on the server side with an ASP/vbscript page
that recreates the original form with an error message if needed.

Numeric, email and date fields are all validated specifically, but
gereric text fields were not. I guess I'll add a check to my
validation script to check for characters like the following
!^*()_+='`~\|]}[{;:/?.<>&%.

Do I need to worry about dashes, underscores, commas, & periods?
Those I'd like to allow.

Also, some international addresses (something the form may collect)
contain forwardslashes or backslashes. I can imagine they could prove
troublesome, but how do I deal with this? I'd like to allow those if
it's safe to do so.

Something else that came to mind is the form conatins hidden fields
whose values are also getting returned empty. How could this be since
the user never sees or gets to change them?

Lastly, could I be barking up the wrong tree thinking this is a form
hack? Since the form uses CDONTS to email me the results, and CDONTS
doesn't validate users, could a spammer have found a way to send out
spam through this page/form and the blank results I get are just a
by-product? Just a guess.

Thanks,
Jim

Server side or client side? If this is client side, as in a
JavaScript validation, it's quite simple for a hacker to read the code
and bypass it. Make sure you *also* validate on the server side. In
your case, a simple check to see if the field contains A-Z and 0-9
might be enough. On a failure, simply reload the original page,
perhaps with a message to fill in all fields with A-Z or 0-9.

Jeff

 

[Dave Anderson]

Is there a list of characters that should ALWAYS be
avoided in forms/text boxes for security reasons?

It's a short list: {}

I can see right away how quotation marks, semicolons,
greater than & less than brackets and backslashes could
be problematic.

In what context?

If you are storing data in a DB, you can avoid all *security* issues by
explicitly calling stored procedures through an ADODB.Command object.

If you are spitting the values back onto a page, you can use
Server.HTMLEncode().

I can't think of a situation that demands avoidance of *any* character.

What are some others to be wary of?

How do I handle the fact that in a few cases I will need to
accept backslashes, Apostrophes, Number/Pound symbol, and
possibly a select few other non-alphanumeric characters?

You have to assume that *ANYTHING* can be submitted to the ASP script. Once
you accept that, it's easy to manage the data. Want to exclude specific
characters? Replace them (or test for them). Examples (I use JScript, but
the VBScript versions are similar):

Test for non-integer characters:
if (/\D/.test(myVal)) return "Integers only, please."

Ignore non-integer characters:
CMD.Parameters("Phone") = myVal.replace(/\D/g,"")

Strip away any HTML tags before displaying:
<%=myVal.replace(/<[\s\S]*?>/g,"")%>

Keep the HTML tags, but disable rendering them as such:
<%=Server.HTMLEncode(myVal)%>

The possibilities are endless.

Will htmlencoding help prevent hacking, or will it be too
late since the validation is server side and code could
get run before validation is complete?

Why would you run code before completing validation? That's a design issue.

P.S. My form is validated on the server side with an
ASP/vbscript page that recreates the original form with
an error message if needed. I am not using any database.
I am just gathering the form text and having the results
sent to my email.

In that case, it's safe to use this type of construction...

<INPUT TYPE="text" NAME="LastName" VALUE=
"<%=Server.HTMLEncode(Request.Form("LastName").Item)%>">

....adjusting for the different form element types, of course.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Jim]

You have to assume that *ANYTHING* can be submitted to the ASP script. Once
you accept that, it's easy to manage the data.

I accepted that a long time ago. The problem is I can't imagine all
the wild possibilities that some hacker with too much time can come up
with.

Why would you run code before completing validation? That's a design issue.

It's not that I am running code before validation, it's concern for
code a hacker may have input into a form field that will get executed
before my form gets validated. (if that's even possible - I don't
know)

Again, since no database is involved, I think the chances are greatly
reduced, but I have no idea what could still happen. It's my
ignorance that is fueling this fire.

What could a hacker enter into a form to compromise my security? I've
tried entering vbscript code lines into my form fields and at best all
I can do is break the form and get an ASP error. Usually a
syntax/string error.

I know I can htmlencode fields before sending back to the screen, but
what happens to malicious code inserted into a form when it's just
stored in the form collection before ever being output to the screen?
Anything?

Can a hacker use a form I've created to somehow view the asp source
for my pages, or gain access to the server itself (which is hosted and
not my responsibility, but nevertheless a concern)? Keeping in mind,
that there is no database backend.

Jim

 

[Dave Anderson]

I accepted that a long time ago...

I'm not sure you have, unless I misunderstand the following:

It's not that I am running code before validation, it's concern
for code a hacker may have input into a form field that will get
executed before my form gets validated. (if that's even possible
- I don't know)

I can't tell if you are talking about client-side or server-side validation.
If client, you can assume you have no validation. If server, then consider
the following:

Each named form element passes a name-value pair (select-multiples send as
many pairs as elements selected) as part of the request. These are parsed
and put into the .Form or .QueryString collection of the Request object.

Each element in the collection has .Key, .Item and .Count properties. .Count
is an integer, while the other two are strictly strings. .Item is the
default property, so if you are using VBScript, references to
Request.Form(key) will actually point to Request.Form(key).Item.

These values are ordinary strings. They cannot execute anything in your
script unless you use the Execute Statment (VBScript) or the eval Method
(JScript).

http://msdn.microsoft.com/library/en-us/script56/html/vsstmexecute.asp
http://msdn.microsoft.com/library/en-us/script56/html/js56jsmtheval.asp

Most of us don't use either, for good reason. Strangely enough, some of the
same people who would never do so seem to think it's OK to execute SQL
strings constructed with user input. But that's another topic.

What could a hacker enter into a form to compromise my security?

That's a bit like asking what he could type on paper that would cause a
security breach in your computer. Unless you use Execute/eval() (or re-type
his words into your computer), you're not at risk.

There's always a slim chance that he could craft a request that exploits
some existing vulnerability, but then it would be an IIS problem, and your
script would be no more vulnerable than any other.

I've tried entering vbscript code lines into my form fields and
at best all I can do is break the form and get an ASP error.

How are you even able to get an ASP error in that manner? Are you talking
about something other than a type mismatch? Perhaps you could show some
code.

I know I can htmlencode fields before sending back to the screen,
but what happens to malicious code inserted into a form when it's
just stored in the form collection before ever being output to the
screen? Anything?

What happens when a malicious letter just sits in an unopened envelope?
Anything? No - it's just text.

Can a hacker use a form I've created to somehow view the asp
source for my pages, or gain access to the server itself (which
is hosted and not my responsibility, but nevertheless a concern)?

Curiously enough, maybe.

Suppose, for example, you expect one of the values to be numeric, but you
don't bother verifying it. If that value contains a non-numeric string and
you try an operation that requires a number, you could get a run-time ASP
error.

Suppose further that the error occurs in an include file, which you have
conveniently named "myInclude.inc" without bothering to assign asp.dll as an
ISAPI extension for .inc files, and your server is configured to use the
default 500;100 error page.

Lucky you! Your error triggers an error that reads something like this:

Type mismatch error
myInclude.inc
Line 32, character 10

The hacker types the following into his browser...
http://yoursite.com/path/myInclude.inc
....and gets to read your entire include.


Scary? Only if you (a) don't validate your incoming data before using it,
(b) use includes with extensions that are not parsed by asp.dll**, (c) use
no exception handling, and (d) give away the farm on your 500;100 error
page.



**I just avoid the whole mess by using .asp for everything. This caused no
end of confusion for a vendor I was working with once, so I now use
something along the lines of myInclude.js.inc.asp or myInclude.vbs.inc.asp

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Jim]

I can't tell if you are talking about client-side or server-side validation.
If client, you can assume you have no validation. If server, then consider
the following:

Server-side. Sorry, I did mention that earlier, but this is a rather
long thread now.

These values are ordinary strings. They cannot execute anything in your

This was my assumption (dirty word assumption) but I'm glad you
confirmed it. Frankly I just wasn't sure.

unless you use the Execute Statment (VBScript) or the eval Method
(JScript).

I wasn't aware of that. Precisely the type of suggestion I was asking
for. Thanks! Fortunately, I don't use Execute and now I'll know to
avoid it or proceed with caution in future.

That's a bit like asking what he could type on paper that would cause a
security breach in your computer. Unless you use Execute/eval() (or re-type
his words into your computer), you're not at risk.

Ok, I admit this was a bit broad, but again, the Execute/Eval tip was
exactly the kind of thing I was asking to be informed about.

How are you even able to get an ASP error in that manner? Are you talking
about something other than a type mismatch?

No, type mismatch was what I was talking about. Didn't mean to
confuse.

Can a hacker use a form I've created to somehow view the asp
source for my pages

Curiously enough, maybe.

Suppose, for example, [snip] an error occurs in an include file, which you
have conveniently named "myInclude.inc" without bothering to assign asp.dll
as an ISAPI extension for .inc files, and your server is configured to use the
default 500;100 error page.

Lucky you! Your error triggers an error that reads something like this:

Type mismatch error
myInclude.inc
Line 32, character 10

The hacker types the following into his browser...
http://yoursite.com/path/myInclude.inc
...and gets to read your entire include.


Scary? Only if you (a) don't validate your incoming data before using it,
(b) use includes with extensions that are not parsed by asp.dll**, (c) use
no exception handling, and (d) give away the farm on your 500;100 error
page.


**I just avoid the whole mess by using .asp for everything. This caused no
end of confusion for a vendor I was working with once, so I now use
something along the lines of myInclude.js.inc.asp or myInclude.vbs.inc.asp

Well, if that's the most likely or common way, then I'm not too
worried. I am actually aware of this problem and DO use the .asp
extension for my includes.

I have to thank you for your patience and thorough assistance, Dave.
I do feel much better about my form security. Of, course this whole
thread got started because my form results are occasionally getting
emailed to me empty/blank and I was concerned someone was trying to
hack my site. And while the question of "how'd they submit a blank
form" still remains, at least I feel better about not having left any
gaping holes.

Thanks again!
Jim

 

[Dave Anderson]

Of, course this whole thread got started because my form
results are occasionally getting emailed to me empty/blank
and I was concerned someone was trying to hack my site.
And while the question of "how'd they submit a blank form"
still remains, at least I feel better about not having left
any gaping holes.

Spiders/webcrawlers can trigger your script. It isn't too difficult to craft
a solution, though. Changing from GET to POST is a good start. The fact that
you get blank messages at all suggests you still have some validation
issues, IMO.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.