The Marketers’ Senate

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 ech_tips/malicious_code_mitigation.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; charset=IS0-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.