Scripting and Security

Contributor: Rosemarie Wise

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.

Introduction

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.

Identifying Entry Points

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 be bypassed.

Client Side Validation

To validate data on the client side you have to ensure that there is support for the scripting language (either JavaScript or VBScript) and that it is enabled 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 you created.

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 out for.

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 inaccessible directories.

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.

Conclusion

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 secure.

Happy safer programming!