Rosemarie Wise guides the website owner through
a minefield of scripting and security issues that
help ensure a site is less likely to suffer the
unwelcome attention of a malicious intruder.
It is so easy to forget about security when you
first start out writing your own interactive content;
so long as it does what you want it to, does it
really matter that someone with a bit of knowledge
can see the script configuration files? Yes it does!
Once hackers know a bit more about the server environment,
they can use that to try known exploits that will
open the server so they can get access to it; and
once they get it, only they know what they will
do with the information!
Fortunately there are a few simple, but often overlooked,
techniques that you can use to minimize the risk
of exposing your server through poor scripting.
I'm going to discuss a few here.
The most common way of getting access to a server
is through a script that processes data from an
outside source (either another script or user input);
so your first priority should be to secure any scripts
that process any tainted data (the name given to
data that isn't generated by the script).
Other security issues can arise from people "discovering"
data files that are used for running a script. Basic
password protection through the use of .htaccess
or putting these kind of data directories and files
out of reach should be enough to thwart the curious
visitor looking for an easy way to get some control
over the site.
The more determined someone is to get access to
your server, the more they will probe your site
looking for scripts, software or server configurations
that have known security issues. In some cases all
it takes is for a certain combination of letters
and symbols passed in a query string to fool the
server into passing scripts as plain text. It would
be a good idea to keep your scripts and software
up to date; while the new versions of the software
may still be buggy, the more commonly known exploits
of older software should be fixed.
FormMail is a very well known script; however recently
there was a bug discovered that allowed anyone who
knew about the exploit to use the script to send
out spam mail. While the problem has since been
fixed, there will still be a lot of servers that
are running the old version and so run the risk
of having their IP addresses put on the mail blacklist.
Never Assume that
Data is Safe
Be careful not to fall into the trap of assuming
that your online forms will be used the way they
were designed; even the naive visitors that fill
in forms for the fun of it with various symbols
can break open a script. To reduce problems caused
by unexpected data, you should make sure that data
is preprocessed before using it as valid input.
There are two places where you can check the input
that comes from your visitors; on the client side,
and on the server side. While both have their benefits
and drawbacks, you should be careful not to rely
entirely on client side validation as it could easily
Client Side Validation
To validate data on the client side you have to
ensure that there is support for the scripting language
on the visitors' browser. Where you can be sure
that either is available; then it can save a round
trip to the script should any data be invalid. The
problem of dealing with browsers that cannot handle
the client side scripts still remains, although
careful planning of form field sizes and data options
can reduce the number of invalid field entries.
Server Side Validation
The best thing about validating the input on the
server is that your visitors don't need to meet
any specific browser requirements. Of course validating
on the server side can be much more demanding on
server resources, but it does help to catch any
invalid data that comes into the script directly
or happens to make it past any client side filters
Dangerous Data Types
Its all very well knowing that certain user input
can be dangerous, but exactly what kind of data
can be hostile if run directly by your scripts?
Well, there is no easy answer, as it will depend
on what your script is doing with the data, but
there are some data types or patterns you can look
HTML Code - may not seem like a threat in itself,
but if your script is set up to allow HTML code
of any form, be sure to strip out any comments;
otherwise it might be possible for visitors to start
scripts with a SSI call with some undesirable effects.
Symbols and Special Characters - could easily be
mistaken as part of an escape character or variable
with unexpected results. More likely to break a
script than expose a server.
File Paths - be very careful to restrict the directories
and paths you allow your script to access; filter
out all requests to back out of a directory (../)
as this is a popular way of getting access to otherwise
Keeping it under wraps
Another good idea is to hide as much of the data
transferred between your visitors and the server
as possible. Writing your script so that it will
only accept valid data from a form that uses the
POST method, not only keeps the information out
of the URL that your users see, but makes more work
for those people that try to break into a script
by passing data through the URL. For extra protection
you could even make it so that your script checks
that the form used is actually on your own site;
be aware however that the HTTP_REFERRER header that
is commonly used to achieve this sort of protection
can be forged.
While there are other more complex ways of gaining
access to a server, I hope that I have made you
aware of some of the more common ways that undesirables
will try to get access to your server. By taking
the extra time in preprocessing any tainted data,
you can go quite a long way in making scripts more
Happy safer programming!
author, Rosemarie Wise, is a self proclaimed
'web enthusiast' who set up her site, Web
Site Owner to share her experiences of being
a site owner.
has produced a great resource for anyone who'd
like to learn about, or develop their skills
in web design...
Although our contents are free to browse, copyright
resides with the originators of all works accessed
at AbleStable®, and unauthorised copying
or publication of our site contents is strictly
AbleStable © 2002-2007