Basic Security Guidelines for Programming In Any Language

If you have a website, it's being attacked, probably on a daily basis. Looking at your server logs will almost undoubtedly show you many, many attempts at gaining entry by password-guessing bots or by repeated attempts to exploit your web forms. Expect that every form you use will be attacked mindlessly over and over by bots. It's just the way it is these days. Plan for it and guard against it. In this article I'll give you some basic tools and techniques to help make sure that you stay in control of your server or web site.

A Little Background
The bots and people trying to get into your server don't necessarily want your content, they want your platform. They want to be able to serve malware, send spam, host phishing and 'pill' sites, store warez and child porn, launch attacks on other sites, and so on. Your content is usually of no interest to them. Your computing power is. Publicly accessible servers are seen as resources for organizations with malicious or illegal intents. They don't care who or what they're harming or attacking. They just want to use your server to continue whatever they're doing. Many times, the attack is done through a zombie or bot, run on someone else's home PC. (I'm looking at you, Microsoft Windows.)

Let's be clear here- these days attacks against your site probably aren't being done by some lone hacker in his room late at night, just doing this for the challenge. These days most exploits are done by well-run criminal enterprises using botnets to scan and exploit any server they can find. These groups use other people's servers to attack people and other servers while protecting their identity. The attackers are very smart and have good tools. The objective isn't as much to destroy your files or deface your pages- they want to put something on your machine, perhaps a phishing site, perhaps a pill store, perhaps a directory full of child pornography. They can and will use your machine to distribute anything they want.

XSS (Cross-Site Scripting) and SQL Injection
XSS and SQL injection exploits are real problems and they're often fully automated. As mentioned above, it's not a lone hacker trying to mess with your site, it's botnets fuzzing every form they can find trying out long lists of common exploits. If your site is vulnerable, the chance of it getting hammered by a bot is actually pretty good.

Writing secure code takes about the same amount of time as writing insecure code if it's done correctly. Baking security into the application should not require a lot more code or time. If you write exploitable apps, you leave yourself open to liability if (when) it's exploited. If a client's site is cracked and it's due to your code being insecure, guess who's at the top of the list to be sued (or at least blamed)? You are. If you knowingly deliver insecure code, you're liable should something happen as a result.

All web-facing code must be made secure.ALL of it. Let's say you have a site that's very, very secure- that is, it's nicely locked down with no real security holes. You then add a simple app, like a contact form. If the contact form is insecure, you've just opened the entire site to being exploited, having its data stolen, etc. It's the "weakest link" principle in action, like having a very well secured home but leaving the back door unlocked.

Some basic security guidelines for programming in any language.

Suggestions for contact forms (and other forms, as needed):

Filter all tabs and carriage returns (\t, \r, \n) from the email addresses (sender and recipient), plus the name fields.

Prohibit the string "http". Look for it and disallow sending if it's in any of the fields. This works amazingly well. If they need to send you a URL, email them back and get it. This one trick will stop the vast majority of robotically-generated spam.

Use a CAPTCHA mechanism or use a timing function that fals the form if it's submitted too quickly (or after too long a period of time). For example, no human can fill out and submit a form with five text fields in under 1 second- but a bot can (and will). Make a form that's filled out to fast trigger a failure and refuse the form submission.

Similarly, some bots will fill out a form, wait some period of time (10 minutes, an hour) and then come back and submit it in order to get around a the "filling the form out too fast" trigger. Make that fail the form submission too.

Use a hidden text field and disallow sending if it's filled in- most spambots will blindly put something in every single field. (Or use a field that says "DON'T fill this in"- humans won't but spambots will.)

I also recommend using a referrer test to make sure it's being called from your domain and not anywhere else. This can be spoofed, but every little bit helps.

Be especially wary and careful of any code that does any of the following things:

Code that saves user input into a file, where the file is then displayed as content or where the user can browse to this file and cause the web server/scripting language processor to execute it.

Code that saves user input into a user specified location or file name, or allows deleting or downloading of a user specified file.

Code that allows uploading of a file to a user specified file name (or location) or with any content (such as scripting language.)

Code that places user input into a database query, where it can be used to read/modify/delete anything in the database or where user input in the database is then displayed as content or is executed as code or as template code…

Code that places user input into the header field of email, where it can be used to send anything to anyone.

Limit Your Incoming Data
Limiting the incoming data can prevent all sorts of problems. For example, if you're accepting data that's supposed to be a year (i.e. '1995', '2003', etc), clip the data to a sensible length (in this case, 4 characters). Why allow someone to pass in 50K worth of exploit code when you're only supposed to be receiving 4 characters? Don't give hackers room to play, make it hard for them by limiting what they can potentially put into your system wherever you can. Limiting data to rational lengths can make it much, much harder (or impossible) for exploits to succeed.It's awfully hard to hack a server if 4 or 5 characters are all you have to play with. For longer incoming data strings, sanitize and convert potentially malicious characters (single quotes, brackets, backticks, and so on).

Don't rely on the "maxlength" parameter in form fields to limit data- it's easily spoofed or changed. In addition to the "maxlength" parameter, always clip or limit incoming data at the server when it's received. For this, the substr() function is your friend. Use it.

Audit Your Files RegularlyUse a file-auditing script or mechanism to monitor seldom-used directories. A lot of phishing sites are deliberately loaded into application image directories or similar locations where they aren't visible from a cursory examination in the hope that they won't be discovered. To help prevent this, have your server send an email every night listing new and updated files. A simple cron job like the one below will check for new files and put them in a text file named "file_list.txt".

5 0 * * * find /path/to/your/directory -mtime 0 > file_list.txt

This cron job runs at 5 minutes after midnight (server time) every night. Change the path to match your server, and have a script on your system email the list to you each night after it runs.(courtesy of wirehopper.com)

Screen Out Countries You Don't Want
If you (for example) run a forum that's primarily of interest to only citizens of your country (i.e. divorce information, local nightlife, etc), disallow places that have no legitimate relevance to your site. If you have a site that's all about Los Angeles restaurants, how many legitimate visitors are you likely to have from China or Nigeria? The answer is "practically zero", most visitors from those countries will be bots looking for forms to hack. Why not block them? Block foreign countries from those forms or forums. Yes, you might lose a genuine visitor, but you'll definitely prevent the 10,000 bots and spammers from taking a run at your site. Which would you rather have?

In Conclusion
This is a brief set of guidelines and is by no means a comprehensive list of security measures, but I hope you've gotten some ideas about protecting your sites and servers from this article. It's up to you to protect your hard work and to protect your users.