Website Security Without Breaking the Bank? 195
An anonymous reader writes "I do my own Web design and have a few websites — MySQL, PHP, CSS, HTML, that kind of thing. It's simple, amateur stuff, but I would love to have some reasonable ways to assess their security myself and patch the big holes, or possibly enlist someone to do 'white hat' work to assist me. I have absolutely no idea how to proceed. I don't want to get mired in a never-ending paranoia-fueled race to patch holes before the hackers find them, but on the other hand, I don't want my websites to look like Swiss cheese. Right now, I wouldn't know what kind of cheese they look like: Swiss, Havarti, or hard as Parmesan. How can I take reasonable steps to protect these websites myself? What books has the community found useful? What groups (if any) can offer me inexpensive white-hat hacking that won't end up costing me a first-born child? Or am I better off just waiting until a problem arises and then fixing it?"
take a tour at OWASP site (Score:5, Informative)
Re:Well, for starters... (Score:4, Informative)
Look at OWASP for Top 10 security vulnerabilities (Score:5, Informative)
The Open Web Application Security Project (OWASP) has a Top 10 list, which lists the most serious web application vulnerabilities, discusses how to protect against them, and provides links to more information (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project [owasp.org]). This might be a good start.
A book couldn't hurt (Score:5, Informative)
I learned a decent amount from Essential PHP Security [is.gd]*. It doesn't cover everything, but should cover most of the crazy-stupid errors that crop up in a lot of novice php/mysql stuff. Not that the information isn't out there in plenty of places (just like every other topic humanity has ever thought up), but for twenty bucks it's nice to have a hard copy of the essentials in one place.
*Yes, that's a referral link to amazon. But I'd recommend it either way for people getting started with securing their basic LAMP sites.
Learn good coding practice (Score:5, Informative)
It doesn't matter what you do after the fact to secure your web sites, if your scripting is full of holes, trying to plug them up after the fact isn't going to work. For example, you mention MySQL so I gather your code accesses one or more databases? If so do you know what a SQL injection bug is and have you reviewed your code for them? Nothing you do at the point of deployment is going to help fix a SQL injection bug.
I'm afraid that if you're using MySQL and PHP you've moved from the realm of the very basic to something more advanced. You're no longer just talking about slapping static content on the web. People spend years learning how to do these things really well. You should find yourself a good book and get started. Start with a Google. It costs nothing. If you have friends who do web development with similar tools talk to them and see if they'll help point you in the right direction.
Here are some things to get you started. Note that these are language independent things you should do no matter what dev tools you use. You might want to look at something more targetted for PHP as well.
https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices [cert.org]
Here's the main site.
https://www.securecoding.cert.org/confluence/display/seccode/CERT+Secure+Coding+Standards [cert.org]
The other way to go would be to make your web files more static. However getting rid of everything dynamic may not be a reasonable option in 2009.
Good read (Score:2, Informative)
http://www.ipa.go.jp/security/vuln/documents/website_security_en.pdf [ipa.go.jp]
It's quite easy to understand and if you follow all the recommendations your website should be more secure than average.
mod_security (Score:5, Informative)
Re:take a tour at OWASP site (Score:4, Informative)
Some of these replies are pretty vague (Score:4, Informative)
In that case, the biggest exploits that you are probably easily vulnerable to are SQL injection and JavaScript injection. I highly recommend that you research those two things, they will go a long way toward securing your website.
The Kaspersky anti-virus website fell victim to SQL injection just yesterday... but it is an easy thing to prevent with a little knowledge and diligence.
Re:Best strategy (Score:5, Informative)
Point is, he writes his own PHP. It's very easy to include URL parameters into a query string, don't validate input for mail() et cetera. He needs someone to tell him where is PHP is wrong.
Some Ideas (Score:5, Informative)
First and foremost, check and sanitize EVERY input passed via a $_POST or $_GET (and to be safe, check cookie inputs too).
Make SURE that none of them are in a format or contain data that you don't expect.
It is easier said than done, and it sucks major ass to do, but it's really the only way to be sure of what you are doing.
I just spent most of the last week tracking down an XSS exploit for a client, and it was a mother to find where to filter the input AND what to look for. SOME inputs needed SOME HTML tags to pass through, others required binary data, and still others needed integers.
My advice on new code is to check your inputs like crazy before assigning any submitted data to a variable. Then check the variables themselves.
Watch for hex encodings of HTML characters, and then watch for it again.
Then, after all that work, hope it works, then drink heavily.
Suhosin, etc... (Score:5, Informative)
I just got back from a PHP security class, here's a quick overview of what was covered:
- register_globals = off
- Use the Suhosin PHP hardening patch.
- Always filter all of your input for injection attempts. Write a validation class to handle this.
- Use prepared SQL statements, or stored procedures to help avoid sql injections
There are some pretty good articles out there that cover most of these points and more, just google for "PHP security". Take the time to read the articles, they're worth it.
It's really sad that more people don't pay attention to PHP security. The class I took was, as far as I know, the only commercial PHP security class offered in the US this year, and there were only 4 students in attendance.
fix the braindead things first (Score:1, Informative)
SQL injection: Use prepared statements. Always. Period. Do not EVER interpolate or concatenate user input into a query. SQL injection was pretty much solved years ago and it's an embarrassment that sites still fall prey to it. With PHP, this requires mysqli.
Javascript injection/XSS: Find a template language that escapes BY DEFAULT and only prints raw HTML if you explicitly ask for it. You're on your own there; I'm not familiar enough with the PHP ecosystem to name one.
The usual PHP advice is "well, just wrap your input in these three functions every time you use it." That's just begging to forget it a few times, which leads to a few holes you are unlikely to notice. Security should be a default; it should not require constant extra work on your end.
If you cover those two and make sure you keep all your software patched, you will already be well ahead of the curve.
exactly (Score:5, Informative)
Honestly, if the OP is in the situation where he is trying to find and patch holes, it would probably be a better idea to do a little homework and start the project over again and use good security techniques when writing.
It is not that hard, really. You just have to remember never to trust user input. That means that you filter all of it, you don't rely on cookies for access control, and you don't trust the variables that the browser sent you (such as $_SESSION['http_referer']).
As far as filtering is concerned, remember that php has a lot of filters at your disposal [w3schools.com] (just remember to strip new lines out of email addresses yourself, the filter misses that one). Another word of warning: if you are echoing user input out onto a page, it is much easier to use bb syntax than allow html tags through strip tags: the danger is that an attacker can get javascript attributes the filter and it is better just to avoid it.
Re:Some of these replies are pretty vague (Score:5, Informative)
The easiest way to prevent SQL injection is to use a library like MBD2 ( http://pear.php.net/package/MDB2 [php.net] ) and use placeholders.
That way any data you use in SQL statements is automatically quoted.
Perl users have had this for ages with the DBI module, so SQL injection is much less likely in Perl than in PHP. Hackers like PHP ;)
Also AFAIK PHP has no convenient way of stripping Javascript from user input which also creates a risk.
X.
Enforce good passwords (Score:2, Informative)
Ensure your users pick good passwords [darkreading.com], by preventing them from entering passwords described here (e.g. their firstname, "password", "qwerty", etc).
Re:Better tools, good process, learning from other (Score:2, Informative)
80-20 rule (Score:4, Informative)
I'm not suggesting this is rock-solid security. It's a few easy steps that keeps most of the knuckleheads at bay.
Seth
Re:mod_security (Score:4, Informative)
Also, take a look at installing Suhosin [hardened-php.net], if you have root access to your server. It's a PHP patch that adds more security on the binary level to combat certain common attack vectors like SQL injection (though that said, you should never simply rely on its protection without knowing how these attacks work and how to program defensively).
Speaking of which, PHP itself has a page on SQL injection and how to avoid it [php.net], which I recommend that you read and commit to memory if you don't already know about it. Especially for new developers in the PHP world, SQL injection is the number one security pitfall, and if you're uneducated about it, it's very easy to create insecure applications.
If you would like, I am a very experienced developer with about eight years of PHP experience. I can go through your code with you and tell you where you might be able to improve security. My rate is $30 / hour, but it probably won't take too long to give recommendations. If you're interested, please contact me at my first name at jamiearseneault.com.
Learn about security to get good web security (Score:3, Informative)
You can start here:
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/358-BSI.html [us-cert.gov]
And for specifically for web apps:
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/assembly/639-BSI.html [us-cert.gov]
Then you frighten yourself by playing with the toys here:
http://insecure.org/ [insecure.org]
Re:Better tools, good process, learning from other (Score:3, Informative)
I have a simple guide when I write code, it's not flawless but it covers a lot of bases - every time I load a variable that has anything to do with generated content (i.e. from a user) I sanitise it - I don't report errors, I just strip out invalid characters (as a rule). It's not the best way to do it, but combined with a good site design it helps a lot.
Re:Suhosin, etc... (Score:3, Informative)
All good points. I would add that you don't really need to filter your input for injection attempts. Filter your data for valid input. And don't ever use user-submitted content to create code to run. That means don't do it in your php code, and don't do it in stored procedures. If you absolutely MUST, be extra sure that it's validated, and then if it's a string where it's potentially legal to have something resembling sql code, escape it.
Re:mod_security (Score:3, Informative)
> I recommend mod_security
One thing to watch for with mod_security is that it will block certain requests even when it's in 'logging only' mode [blogs.com]. Still a useful tool, but keep a close eye on it.
Re:take a tour at OWASP site (Score:5, Informative)
OWASP is invaluable for learning the WHY and HOW behind security.
But for an amateur, I think the first best thing he could do is apply the Suhosin patch for PHP: http://www.hardened-php.net/ [hardened-php.net]
This lets him worry about the why and how AFTER he's already closed many of the attack vectors a default PHP install leaves open. Especially if he's running below 5.2.x.
Furthermore, PHP has been more security focused since 5.01. You can learn a lot about security just by reading the release notes, even if you don't think you're learning about security!
For example, the filter_input() function. Instead of doing this:
$phone_number = $_POST['phone_number'];
do this:
$phone_number = filter_input(INPUT_POST, 'phone_number', FILTER_SANITIZE_STRING);
That simple change applied to all of your $_POST, $_GET (and/or $_REQUEST) look-ups will shut down most of your application-level attacks.
Any PHP developer should learn and ALWAYS use the new Filter features: http://us2.php.net/manual/en/ref.filter.php [php.net]
Comment removed (Score:4, Informative)
Re:Well, for starters... (Score:3, Informative)
I spent more than a year playing this wargame and learned a great deal about security.
The real world examples are the best. IRC can degrade into a flame war so you may not find much help there, alot of back patting.
eEye has some decent free tools, and useful Whitepapers.
http://www.eeye.com/html/index.html
Security Focus
http://www.securityfocus.com/
What toolkit would be complete without an excellent reference site. Includes some POC on some exploits.
SQL Injection White Paper from SPI Dynamics. Though I couldn't find their site, think HP bought them, you can find the white paper with a google search.
http://www.google.com/search?hl=en&q=%22sql%2Binjection%2Bspi%2Bdynamics%22&btnG=Google+Search&aq=f&oq=
Armed with this you should have access to as much knowledge as any attacker to your site.
DEFINATELY make sure you have your servers configured with only what they need to do what you need them to.
Simple (Score:4, Informative)
0) Use a version control system
1) Validate input, escape output
2) Turn off unused services
3) Regular, automatic backups to another location
Ok, the OWASP list is more comprehensive, but these four things are fundamental to preventing, and recovering from, security breaches.
Re:take a tour at OWASP site (Score:1, Informative)
Here's a good example:
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html [ilia.ws]