In recent weeks, attacks on prominent sites such as Yahoo and
Ebay have brought home a very pressing point - site security.
Anywhere you have a dynamically-generated page, you could be open
to attacks where malicious HTML is embedded into your pages. Your
pages could be rewritten to substitute your customers' names with
"Dummy." Or, credit card information could be intercepted and
sent to a secret depository for later use.
What can we do about this?
There are many methods by which a hacker may attack
or take control of a site. I am focusing this discussion
on attacks that come via form input. That is, anywhere you
have input coming in from your web user, e.g. a registration
form, user login or even a search on your site. Scripts could
be sent to your server by entering < script> some malicious
code < /script> in your input fields. The following are steps
you can take to minimise the risk of this happening.
These measures will not make your site hacker-proof
(no site can be if a hacker really has it in for you), but it
can make it less of an easy target.
Step 1: Place character limits on your inputs
You do this by adding the "maxlength" attribute into your text input tags
e.g. < input type"text" name"firstname" maxlength"15">
The example above restricts the user to a 15 character input for that field.
The "< script>" and "< /script>" tags alone will take 17 characters so
the smaller you limit your "maxlength" attribute to, the harder it will be
to include rogue codes in your inputs. Of course, you must ensure that
you impose a suitable limit so that actual input from your valid users
will not be excluded.
Step 2: Filtering your data
All data received from your site should be filtered, you can either filter
your data when it comes into your server as user input, or when it goes out
as results for your user's browser. Whether you should filter input
or output, depends on your site and its requirements, there is a good discussion
on this at http://www.cert.org echtips/maliciouscodemitigation.html/.
Filters can be written in any language, here is an example in Perl :
# This function checks the input, $firstname, for the following symbols ;<>?/'&$!#()[]{}:"'
# and tells the user to re-enter his/her firstname if any of the symbols is found
if($firstname ~ /([;<>?/'&$!#()[]{}:'"])/) {
print p('Invalid input found, please use only alphanumerical input. Please re-enter your
FIRSTNAME');
}
You can see this script at work on our site : http://www.payingads.com/freesignup.html.
Step 3: Setting the character encoding
Some HTML editors already set this while it creates a page,
but those of you who have older HTML editors or like me,
like to code the page from scratch will need to include the
following line in our HTML pages:
< META http-equiv"Content-Type" content"text/html; charsetIS0-8859-1">
It should go as high as possible on your webpage, I
normally place it just after the < /head> tag, before the
< title> tag. This META tag tells the browser to use the
"ISO-8859-1" character set, which is suitable for most
Western European languages, rather than let the
browser choose it's own character encoding, which
may or may not be ISO-8859-1.
Why is it important to explicitly set it?
The character encoding basically tells browsers how to display
a particular character. For example, in the ISO-8859-1character set,
"A" represents the letter "A" while "©" represents
the copyright symbol "©" (You can try this out by typing
< p>A< /p> or < p>©< /p> in a html file then call it up
on a browser). Some character sets, have more than one
representation for special characters such as "<" or ">",
so your filter program may not toss out all the representations
of the character you have asked it to exclude. So when it serves
a new page back to the browser, the browser, because it has
not been told what encoding to use, can still read the
malicious script intact.
So there you have it, 3 steps that should be incorporated
into every website. Use them as a base to further build on.
Because every site is different, you (or the security consultant
you hire) will need to assess your site's own vulnerabilities
and implement appropriate security measures. To do this
you need to take into account your site's risk
factor, your budget and your available resources.
On a final note, I'd like to stress the importance of keeping
up with the latest threats and developments in site security.
A good site for checking out security alerts is the
CERT Coordination Center http://www.cert.org/nav/index.html or
better yet sign up for their Security Advisory that is sent via email.
About the Author
Gim Yeap
Email : gim@payingads.com
Site : www.payingads.com