|
Form
Security
|
 |
|
The
steps you need to take to prevent someone from infiltrating
your server from a form field depend on what you plan to do
with the data you're collecting.
If you're simply sending the information along in an email, you only need
to check for attempts to insert HTML or other code into the form field.
If you're storing the information in a database, you not only need to check
for HTML or other code insertion, you also need to check for possible injection
attacks aimed at gaining access to your database.
I recommend checking all user supplied input for both code insertion and
injection attacks no matter what you plan to do with the data. You never
know when your storage methods will change and it only takes a few lines
of code to protect against both. |
Code
Insertion Attacks
|
Suppose
you had a form field on your web site that allowed users
to send in an anonymous tip.
After the tip was entered, it's emailed to the chief's office where his
or her secretary decides where to route the tip (narcotics, juvenile,
internal affairs, etc.)
Now suppose that in addition to typing text into the form field, the
user also typed in the code below:
|
 |
<FORM>
<INPUT name="button" type="button"
onClick="alert('Congratulations! You have just infected your computer
with a virus.')" value="Click here to view tip.">
</FORM>
This would result in the following button appearing in the email that was
sent (click on the button):
The secretary
who got the email would assume you had changed the way anonymous tips are
viewed and would dutifully click the button.
No big deal right?
Imagine that instead of popping up a harmless window with a threatening
message, clicking the button would download and execute a virus that would
instantly infect the computer and possibly your entire network.
They wouldn't even have to use javascript.
A simple HTML link can easily be inserted through a form field and clicking
that link can take the secretary to billions of possible destinations on
the internet where more complex malicious code can be waiting to instantly
attack his or her computer.
Especially if the computer isn't protected with a firewall
program .
I'll have more about preventing insertion attacks in a minute - now to
injection attacks.
|
SQL
Injection Attacks
|
 |
Injection
attacks are similar to code insertion attacks in that they
attempt to send unintended commands through your form fields,
but the target for injection attacks is your database.
Most web sites use a version of an SQL (Structured Query Language) database
to store information.
|
By "injecting" unanticipated
SQL code into a form field, malicious users can gain unauthorized
access to the information in the database, or use the database
to gain access to secured parts of your web site.
For example, many sites use username and password fields to grant limited
access to users depending on values stored in a database. The username
and password are then looked up in the database using an SQL query:
query = "SELECT count(*)
from users where username='user' and userpassword =
'password'"
If the query returns a row from the database (indicating the username and
password match a valid database record), the user is then granted access.
What if a malicious user knew one of your valid users username ( jdoe for
example). He or she could enter jdoe for the username
and an expression like ' or 1=1 -- for the password.
Look what this does to the database query:
query = "SELECT count(*)
from users where username='jdoe' and userpassword =
'' or 1=1 --'"
Now, instead of checking for a username of jdoe and his valid password,
the query checks for the username jdoe with a blank password ('' is an
empty string) or the condition 1=1 (which is always true).
Notice how the
last quote is commented out (using --) so the server doesn't produce an
error due to the extra single quote.
Now, the query is checking for the condition that jdoe is a valid username
(which the malicious user knows it is) and that his record contains a blank
password (which it doesn't) OR the condition that 1=1
(which is always true). The end result is a login as jdoe without knowing
jdoe's password.
I won't go into too much boring detail here, there are many places on the
web that enumerate the many types of injections attacks - attacks which
can allow a malicious user to gain access to secure parts of your site,
gain access to data in your database, and even delete the database itself.
What's important is that there are straight forward methods to prevent
both code insertion and SQL injection attacks. |
| |
|
|
|
