need bullet proof input validator

S

SLH

hi people. im trying to validate input received via a text area on an ASP
page before writing it to a database. i cant use client side javascript due
to policy, so it all has to happen on the server. here is what i was trying,
but pieces of it continue to break for one reason or another. the thinking
behind this function was like this:

if the input is less than 10 characters long, fail.
if its 10 characters or greater, but it doesnt appear to contain any words,
fail. (i try this by breaking up the input at space characters into an
array. valid input should have several spaces, indicating several words)
if there are 3 consecutive spaces, fail. (this cant be valid).
then if all that passes, i need to make sure no words are longer than 10
characters. (by looping through the words in the array)

different parts of this fail at different times. for instance if the data
has a newline, it fails (not sure why. is a newline looked at as 3 spaces?)
since there are too many moving parts here i was hoping someone else might
have a better approach to validating the input.
thanks for any help.


Function IsGoodInput(str)
IsGoodInput = True
Dim MyArray, i
MyArray = Split(str, " ")
If Len(str) < 10 Or InStr(str, " ") <> 0 Or UBound(MyArray) = 0 Then
IsGoodInput = False
Else
For i = 0 To UBound(MyArray)
If Len(MyArray(i)) > 10 Then
IsGoodInput = False
Exit For
End If
Next
End If
End Function
 
L

Larry Bud

SLH said:
hi people. im trying to validate input received via a text area on an ASP
page before writing it to a database. i cant use client side javascript due
to policy, so it all has to happen on the server. here is what i was trying,
but pieces of it continue to break for one reason or another. the thinking
behind this function was like this:

if the input is less than 10 characters long, fail.
if its 10 characters or greater, but it doesnt appear to contain any words,
fail. (i try this by breaking up the input at space characters into an
array. valid input should have several spaces, indicating several words)
if there are 3 consecutive spaces, fail. (this cant be valid).
then if all that passes, i need to make sure no words are longer than 10
characters. (by looping through the words in the array)

different parts of this fail at different times. for instance if the data
has a newline, it fails (not sure why. is a newline looked at as 3 spaces?)
since there are too many moving parts here i was hoping someone else might
have a better approach to validating the input.
thanks for any help.

Use regular expressions.
 
S

SLH

Larry Bud said:
Use regular expressions.

thanks, sounds great. i was kinda hoping for help though. maybe in the form
of a good example? regular expressions arent exactly my strong point.
 
E

Evertjan.

SLH wrote on 02 Oct 2006 in microsoft.public.inetserver.asp.general:
thanks, sounds great. i was kinda hoping for help though. maybe in the
form of a good example? regular expressions arent exactly my strong
point.

We all had to learn.
Ther best help is if you start of, and we go along.
 
S

SLH

thank you! here is what i have now:

Function IsGoodInput(str)
IsGoodInput = True
Dim MyArray, i
Do While InStr(str," ") > 0
str = Replace(Trim(str)," "," ")
Loop
If Len(str) < 10 Or Len(str) > 1000 Then
IsGoodInput = False
Exit Function
End if
MyArray = Split(str, " ")
If UBound(MyArray) = 0 Then
IsGoodInput = False
Exit Function
Else
For i = 0 To UBound(MyArray)
If Len(MyArray(i)) > 10 Then
IsGoodInput = False
Exit Function
End If
Next
End If
End Function

im tryng to see if/where this will fail and so far all i can see is that if
i enter:

line1
line2

it fails. i guess because there are no spaces. only a newline after the
first word.
can you see anything clever to fix it so that this input would be valid?
 
S

SLH

thank you.
that wouldnt work because when i later write the data from the DB to the
html page i need to preserver formatting, including newlines.
its ok though. i realize that NO inpute will be valid without a space. so i
should be ok.

thanks for your help
 
S

SLH

hey i have to duplicate this function in javascript. the only part im
struggling with is the following:

Do While InStr(str," ") > 0
str = Replace(Trim(str)," "," ")
Loop

the javascript replace function sucks. it only replaces the first occurence
of what youre looking for.... any ideas?
 
V

Victor

In addition to suggestions here, I'd also check to see if the strings "<%" or "%>" are
in the input, and if it is, invalidate the input and ban the IP address.

Of course, you'll want to set up the test strings like this:
strBad1 = "<" & "%"
strBad2 = "%" & ">"

After that, see if the characters "<" or ">" are in the string, and if it is, invalidate
the input.
 
S

SLH

almost... but that only makes one pass at the string.
so if there are 4 spaces, it replaces that with 2 spaces, but then leaves it
alone.
i somehow have to continue to loop through the string while there are 2
spaces in a row... just like the VBS one.

im going to go play, but do you have any ideas?
 
S

SLH

if i HHTPEncode the string before i write it to the database, that should
take care of that... no?
 
S

SLH

this seems to work nicely:

function replaceall(str, lookfor, changeto) {
str = str.replace(/^\s*|\s*$/g,""); //trim leading and trailing spaces
first
var temp = str;
var i = temp.indexOf(lookfor);
while(i > -1) {
temp = temp.replace(lookfor, changeto);
i = temp.indexOf(lookfor);
}
return temp;
}
 
D

Dave Anderson

Victor said:
In addition to suggestions here, I'd also check to see if
the strings "<%" or "%>" are in the input, and if it is,
invalidate the input and ban the IP address.

That's just plain stupid.

For one thing, you imply that the server will somehow respond to the text as
though it should switch context and execute the contents. This is UTTERLY
without merit. It cannot happen because the script is parsed *before* it is
interpreted. Context blocks are already determined before those strings are
ever encountered.

Secondly, you imply that there is no legitimate reason to use those
character sequences while simultaneously using those character sequences to
make your "suggestion". This is pure hypocrisy.

Lastly, you cannot effectively ban a user by "banning the IP address".
Besides introducing a hurdle for anyone behind the same proxy as your
"offender", you assume the user has a static address.
 
D

Dave Anderson

SLH said:
if i HHTPEncode the string before i write it to the
database, that should take care of that... no?

You mean HTMLEncode?

In my opinion (and in my shop), it is preferable to store the input AS
ENTERED. This leads to the decision of what is allowable. If we decide to
allow free-form text, we always *diaplay* that text with
Server.HTMLEncode().

If not, we audit the input for format compatibility and reject it when it
does not fit. That way, our database always reflects *EXACTLY* what the user
submitted.

Among other things, this makes searching more accurate and abbreviates the
need to perform stupid "compatibility" validation. It also makes our
processes more rubust, since this approach does not permit us to take
shortcuts on security.
 
S

SLH

thanks Dave.

so youre saying validate the input when submitted, write it to the database
AS IS, then Server.HTMLEncode as i pull it FROM the database to display on
the page?
 
D

Dave Anderson

SLH said:
thanks Dave.

so youre saying validate the input when submitted, write it to
the database AS IS, then Server.HTMLEncode as i pull it FROM
the database to display on the page?

Mostly, yes.

If your validation PRECLUDES the possibility of unwanted characters, then
HTMLEncode might be considered superfluous. I would certainly not criticize
you for using it anyway.

I am also saying that by using the right approach, you can limit your
validation to something as little as string length (since your DB field
almost certainly requires you to chaeck for that).

The decision to forego validation DOES mean you must protect yourself from
SQL injection, however. This is best done with parametrized stored
procedures, IMO. It is also fairly convenient to use the
SP-as-method-of-connection technique when inserting the data, though it is
not always possible.
 
S

SLH

Dave Anderson said:
Mostly, yes.

If your validation PRECLUDES the possibility of unwanted characters, then
HTMLEncode might be considered superfluous. I would certainly not
criticize you for using it anyway.

i have a field where it could be perfectly valid to submit "<%" or "%>" for
example.
since i would want to allow this input, how would you recommend i go about
the whole thing to make it as sound as possible?
 
S

SLH

Dave Anderson said:
Well, the display is a solved problem: Server.HTMLEncode().

As for storing it in a database, that dpends on the database. What are you
using?

its Access for now. couldnt i just store it in the database as is then
HTMLEncode as its coming out to be displayed?
hope so because thats how it is as of now
 
S

SLH

Dave Anderson said:
Yes. That is precisely what I would do.

However, I haven't got a clue about preventing SQL injection in Access,
since it does not have stored procedures. I suppose you can just escape
your single quotes, but that's just a swing in the dark.

Access does in fact have stored procedures. im using them for some pages but
not others.
where i dont use them i replace single quotes with 2 single quotes

thanks for your help
 
M

Mike Brind

Dave Anderson said:
SLH wrote:
However, I haven't got a clue about preventing SQL injection in Access,
since it does not have stored procedures.


It's very similar to how you would do it in SQL Server. Instead of a stored
procedure, you create a saved query. However, saved queries are just that -
saved individual sql statements, with parameters if you want. You would
call them in exactly the same way as with stored procs:

conn.qMySavedQuery parm1, parm2, parm3...

Access 2003 will even let you use similar syntax to SQL Server:

CREATE PROCEDURE qMySavedQuery
AS
INSERT INTO tbl
(
fld1,
fld2,
fld3
)
VALUES
(
@textvalue1,
@textvalue2,
@textvalue3
)

You don't declare the parameters or give there datatypes. Older versions of
Access will automatically surround parameter markers with [ ] brackets, and
some silly things go on if you open the query in design view. But, for
Access users, they are as effective against SQL Injection as stored procs in
SQL Server.
 
B

Bob Barrows [MVP]

Dave said:
Yes. That is precisely what I would do.

However, I haven't got a clue about preventing SQL injection in
Access, since it does not have stored procedures.

That's not relevant. SQL Injection can occur in SQL Server even (especially)
when stored procedures are not being used. Any application that uses dynamic
sql instead of parameters is vulnerable to injection. Preventing injection
for Jet involves the same techniques as preveinting it for SQL Server: it
all boils down to: don't use concatenation to insert user inputs into sql
statements; use parameters.
I suppose you can
just escape your single quotes, but that's just a swing in the dark.

While this will certainly be more effective with Jet than for SQL Server,
using parameters will prvent any loopholes.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top