Charles Rowe dot com

I have been meaning to write a web security post and Ilya Grigorik has inspired me with the post “Web Security With Ingress Filtering”. Ilya lists some solid points for protecting your web application. Here are some fundamental points that continue to crop up all the time. If you know them: Congratulations, you are ahead of the game.

Don’t code on production machines
I have been through this before , but it deserves repeating. Every little piece of junk that gets left on a production server is another piece of junk which increases server vulnerability. Neglected software packages will also end up as security holes given enough time to sit and rot.

Protect your database connections
This is another bit of info in the above link. If your script accidentally gets displayed, the last thing you want is for your DB credentials to be exposed to the world.

Salt & hash passwords
Don’t store unencrypted passwords. I don’t care if you are serving up public church newsletters, you still need to encrypt passwords. Think of it as a public service for the rest of the internet: When Alice uses the same password at all of her favorite online hangouts, she is headed for trouble. Your database getting hacked could start a chain reaction ending in Alice’s 20 other account’s getting hacked too. Alice will thank you for not handing her over to the crackers on a silver platter. You should salt every password to make it that much harder for crackers. They may have your passwords and randomized salts, but their hash tables will be useless.

Provide a brute force lockout feature
Don’t allow brute force attempts against your application accounts. Depending on your paranoia level, you can have delays, temporary lockouts, permanent lock outs, etc. Don’t assume someone is going to be monitoring the production logs and will notice accounts put under attack.

Skip the “remember your password” features
Why bother? If they want to remember their password so badly, let them use their browser functionality.
I know of two ways to remember passwords across sessions:

1. Some people will drop the raw password hash into a cookie and use that to authenticate on the next session.
2. Some people create a session that is set to never expire.

I don’t like either. I would rather put it on the user to maintain their environment, than to put it on me to keep that sort of data lying around. I know this attitude is leaning towards an a**ho** point of view, but in a business environment, I think it is necessary. When someone steals a child’s social security number out of your application by getting in through some sort of password feature, it is going to be game over for the business and everyone employed there.

Understand web pages are not tamper proof
Most Developers know an exposed email address being passed into a form leads to it becoming a spam relay. The thing that kills me is that a good number of these same developers will validate data using Javascript, and then fail to validate it before manipulation or storage. Everything must be validated. No exceptions.

Web pages are not secure

• Skip the cookie authentication tokens (go back to using sessions) - Remember the old school “passwords” stored in cookies to allow you into a certain area? I still see those on occasion.
• Don’t hide sensitive data in your cookies or forms, no matter how well you think you have hidden the data. There will always be someone more clever than you are , who given enough time will see your obfuscation patterns. If you have sensitive files don’t put them in a web accessible area. Put them outside of the web path, and use a script to properly authenticate access to the files.

Remove the debug code
Turn your PHP errors off on the production machine, and get rid of the debug code.
These items just act as a foothold to get at the machine. Leaving your debug data lying around risks getting it indexed.

Take care of your production machines
Your application is only as strong as the machine it sits on.

• Do you have a maintenance schedule?
• Do you monitor bug tracking services?
• Do you have regularly scheduled penetration tests?

You will save lots of time by implementing preventative measures instead of formatting your machine after it gets exposed to a root kit. Sometimes when machines run too smoothly we tend to ignore them and put all of our attention towards the problem machines or applications.

If all else fails…
If your company has a known track record of having their applications exploited, or if you currently have security holes but lack the time to address them quickly: I would recommend a Web Application Firewall (WAF). WAFs are a layer between the world and your web application. You can specify suspicious requests and prevent them from being executed in a variety of ways.
I know that web application firewalls get a bad rap, but i honestly think they have their place. Think of them as training wheels for proper security methods, and a baby sitter for those risky third party software. If you have the means, skip WAFs entirely because they are hardly a satisfactory solution. My point is don’t completely disregard them in a pinch.

This entry was posted on Tuesday, May 1st, 2007 at 10:43 am by Charles and is filed under security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.