Recently I watched a conversation play out online. In this conversation, someone announced their “Monthly reminder that there are no such things as best practices in programming.” I am paraphrasing the quote, but that was the gist of it. While this makes for a great sound bite, if you scratch beneath the surface, the mere hubris of the statement makes it laughable to any developer with experience, and hubris is neither a best practice nor a good idea in software development. In programming, there are some time honored best practices like normalizing relational databases to third normal form, or not storing passwords in clear text in your datastore. Of course, there are best practices, especially when you tread into areas like web application security.
In security, things like password security methods, building layers instead of walls, and of course, filtering input/escaping output are best practices. Too many insiders, they just look like common sense, but that is the essence of a best practice, common sense codified so that all can understand.
Let’s take a look at five common sense “best practices” that every developer needs to follow when designing web applications.
1. Don’t roll your own encryption
Encryption is hard, even for the experts it’s hard. It is also one of the most peer-reviewed areas of software development. Unless you are an expert in cryptography – and if you are, you already know not to attempt this – don’t try to roll your own encryption. The problem is that it’s very easy for any developer to create encryption that they themselves cannot break. That doesn’t mean it’s unbreakable, it just means that they can’t break it. The old adage regarding mousetraps applies to cryptography, “Every time you build an idiot-proof mousetrap, the Universe builds a better idiot.” Stick with the well-known and established standards.
Most of the time when we are dealing with encryption in web applications, we are dealing with hashing passwords. Luckily, the PHP manual has some excellent advice on exactly how to handle this very issue on the page titled “Safe Password Hashing.”
2. Clear text passwords
Since we are discussing passwords, the next best practice that most developers consider common sense is “Don’t store passwords in clear text.” The corollary to this is, don’t transmit passwords in clear text…or for that matter, at all.
This seems like common sense. We’ve known for a long time that storing a user’s password in clear text or even in reversible encrypted form is a bad idea. It leads to things like password recovery system that emails or texts you your password. While these things seem common sense today, it was only last year, 2015, when the largest PHP application on the web – WordPress – stopped sending passwords to users in an email when they registered. Clear text passwords are a bad idea, why you are doing it is irrelevant, don’t. If your application was designed this way – and yes, we have all done this – then your number one priority should be to refactor your application to do away with clear text passwords and to properly hash and store them.
3. Security is like an onion, it has layers
Attackers who target your website are not werewolves, there is no single silver bullet that will kill them. Security is best designed in layers. If you have a firewall, that’s great, you still need more. What the layers are depend largely on your particular app and infrastructure, there is no single best practice when it comes to layering security except for layering security. It works in protecting our embassies, our airports, and your web application.
Session Fixation and Session Hijacking are serious problems for PHP developers. If you use Sessions in your application, you need to make sure that your applications – and your infrastructure – are both set up properly. Like security in general, there is no single solution to the problem of sessions. If you use Sessions to maintain state in your application, make sure that you are at the very least following the OWASP guidelines for Session Management.
5. Filter input/Escape output
Almost all developers know Little Bobby Tables. It’s been a great reminder over the years to sanitize our inputs and our outputs. Even with this wonderful reminder though, there are still developers that forget the lesson, and those are the applications most likely to have a SQL Injection amongst other things. PHP makes filtering input very easy with the filter_* series of commands and output is easily filterable using one of several commands depending on what you are trying to do.
Don’t forget that you should be using PDO and prepared statements for all of your database output as that will properly escape data going to your database. And remember, your database is not a trusted source. You may think it is, but since your database can be accessed outside of your application, you cannot 100% guarantee that the data you are getting from it is valid. Therefore, make sure you filter anything coming from your database before you use it anywhere else, just like you would with data coming in from an external API or user.
It’s your responsibility
Application security is the responsibility of every developer. That said, you can’t bolt security onto your app, you have to design it into your app. When designing your next web application, make sure you consider these and the many other best practices that have evolved over the years. Ignoring them doesn’t make them any less important, it just makes your application less secure.
To help you get secure as fast as possible, we are currently offering 25% off our PHP security training course. This offer is only valid for a few weeks, so register now!