You're welcome. No guarantees that's the answer, but it couldn't hurt to keep an eye on. It turns out I still have the full article I was referring to above. Here it is, reprinted from the Jayde.com newsletter:
Quote:
Does Your Site Have 3 Basic Security Measures? By Gim Yeap
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/tech_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.
=============================================
Gim Yeap is host and founder of PayingAds.com, an online trading
post for webmasters looking for paid advertising for their sites
or wanting to sell ad-space. Gim is also editor and writer for the
site's free e-zine, The PayingAds Gazette, a newsletter for
webmasters and online marketers.
=============================================
Expert in your field? We're looking for ARTICLES on web site design
and development, promotion, positioning, and e-commerce. Articles
should be in the 700 to 800 word range and include a 2 line promotion
of the author's site. Send submissions to: mailto:info@jayde.com
=============================================