Introduction
Security is definately not an add-on. Security is something that must be concieved and nurtured from the early points of your design. Using SSL and other technologies is noble and useful, but security needs to be a notion that is applied to the very design of your applications. If the roots of your application are not secure, all the technologies you add to it will usually be in vain.
As we make this journey, let us remember that total security is illusion. Those advertisments that Oracle makes about their products being unbreakable are foolish. Any seasoned expert in the field of security will laugh at that. Everything is insecure, its simply a matter of how insecure it is. To reduce our risks we should aim at making our products LESS insecure. Any product that says it is unbreakable or unexploitable is not telling the truth about its security.
There are many things to worry about. Buggy and blatently insecure software can allow outsiders to potentially do many different things:
– execute arbitrary commands on you system
– view confidential information
– delete important data
– dupe your system into thinking they are someone else
– gain information about your system and other systems on your network
– launch attacks on other servers
– intercept data being sent to and from your network
As a result of the great risk, it is important that we take a systematic approach to application development that is relatively secure.
Four-Layered Web Security
When trying to secure a web application, there are four primary layers that we should be concerned with. They are as follows:
– OS/Web Server Layer
– General Application Layer
– Specific Application Layer
– Data Layer
In case that list isn’t self explanitory, I will go over it quickly.
The OS/Web Server layer involves the setup of the operating system and web server. In most cases this involves Linux and Apache. Ideally, this would not be the concern of a developer–but rather a system administrator. This is the first and most crucial step to writing secure web application. The most secure application can be comprimized easily if the server it is running on is insecure.
As we move past the first layer, we must move on to the General Application Layer. This layer involves general issues that are in common for just about any web application. The General Application layer involves stuff like GET and POST queries, writing to files, session, etc. This layer includes things that you would deal with in nearly every web application you do.
The next thing you should worry about is the Specific Application layer. This layer involves issues that can’t be globally applied to every application you make (ie. WDDX or credit-card transactions).
The last layer is the data layer. This is something that a database administrator will probably worry about if you are dealing with large scale implementations.
Dividing web security four layers is helpful. Think about these layers and how you can improve the security of each layer. I recommend you stick with the first layer until your are confident with it, then move on to the rest of the layers. It may be a good idea to develop your libraries and classes with second layer security in mind because they will probably be reused alot.
The third layer will probably be significantly different in each application, so there is no real way to re-use it in most cases, but there are exception.
Disposing of False Untrue Disinformation
There are many misconceptions that tend to be generally accepted. Lets expose them!
Obscurity does not equal security. hiding your source code is a nice try, but it doesn’t make things more secure. For a vivid example of this, check out the security exploits that have hampered IIS. If the security of your applications relies on its source being hid from prying eyes, your application is not secure. Write your code so that if the whole world would see your source and it would still take them much effort to hack it.
Security is not something that can be an add-on. If security was an add-on, everyone who had certain add-ons would have secure applications. That is not the case. You can throw SSL,digital signatures, PGP, and just about any other technology to your system and still have a relatively insecure system. Use technologies to help you to get to your goal of having better security, but don’t think of them as your one-way ticket to perfect security.
You may limit access by IP address, but that is not necessarily very secure. What if someone exploits the site which you limit access from? There is also many ways to spoof IP addresses.
Following a set of rules will not guarantee your application will be secure. There is no set of standards or rules to follow to ensure that your application are secure. The best you can do is follow a set of PROVEN principles and be ready to adapt to any changes that might be necessary to improve security. Nevertheless,that is not a silver bullet.
General Security Principles to Apply
There are a set of principles that you can apply to your development activities that will empower you greatly in your ability to write secure applications. Check them out!
Control who accesses your web services. Minimalize who knows about about them. If your web application is for internal use only, there is no reason it should be accessible from the outside world.
Do less and check/test more. Write minimal applications. Don’t get fancy until you can handle the added complexity. Integrate your changes incrementally and be cautious of what changes you are making to your source. One “fix” can often open upon many other holes. Perform rigorous testing and validation. Use phpUnit (unit testing package) if you are developing a fairly large and complex application or library. Be careful what you borrow. Everybody (even managers) stress the importance of not “rebuilding the wheel”. Nevertheless, be cautious of what you borrow. While writing your own code may take time a valuable resources, using untrusted code is even worse. I am not saying that you shouldn’t borrow, just be cautious. Just because there are large amounts of libraries and applications already out there, doesn’t mean they are designed well or secure.
Anything that comes from the user is to be treated as highly suspicous. Don’t blindly trust data that comes from URL’s or files. Assume all data is dangerous until it is proven otherwise. Use comphrenesive validations schemes to make sure that data is not tampered with. Using a MD5 hash to ensure that URL’s are not tampered with is a good idea.
Don’t assume anything. Don’t assume that anything is secure. Don’t assume that anything is trusted. Everything must be PROVEN to be relatively secure and trustworthy. Determine the minimum permissions and access required for a specific task. Try to lower that minimum. Write software that never exceeds that minimum. It is better to write something in a restrictive way first and then later expand it to allow more things to be done. Start off with restrictive permissions and then gradually relax them until they are at a point that is relatively secure and usable.
Monitor your logs often. This is a tedious process, but it will pay off big. Search for irregular activity. You use programs that will automate this. Also pay close attention to file permissions. It also may be wise to install tripwire to verify the integrity of all files on the system.
Authentication works best when accounts are distributed discriminately.Don’t give accounts to everyone. This applies to virtually all four layers that we have discussed. Enforce good password naming conventions, but don’t think that doing that will solve all your problems. Plain-text is to be avoided where possible. Don’t store your passwords as plain text in a database. One line of defense is great, but two lines of defense are even better. The more precautions you take the better. Just because you have one form of protection doesn’t mean the others don’t apply.
Lastly, read up! No programmer/administrator is qualified if he/she doesn’t take the time to keep up with the industry. Read indespensible resources such as this site to be aware of security issues and other important things.
Auding and Measuring Security
After a product is created, there needs to be a semi-formal way to determine the security of it. This is difficult.
Having comphrensive tests are absolutely important. This should be obvious to you. Hackers are typically more persistant than you will ever be. Analyising your security will not be done properly if it is done quickly or flippantly.
The objectivity of the tests is also vital. This can be accomplished by letting someone else test it. The one who makes an applicaiton always knows the most about the application, but they also are notobjective. I will always favor the code I wrote even if it does have flaws. I am suspecting this might be a genetic trait that isparticularily emphasized in programmers. They will often take things for granted and overlook things that an outsider would not. A fresh outlook usually is very benefitial.
Using intelligent tests is also important. Tests should be automated and as creative as possible. This could be the subject of another article! Whether or not security can be measured quantitatively is another matter for discussion.
Conclusion
As you have probably noticed, this article has no sample code. That is not a mistake or shortcomming. If you are looking for a quick-fix, plug-and-play way to plop some few lines of code to make your applications secure–you are setting your self up for failure.
More to read: On the Security of PHP