Whatever the reason for neglecting security may be, such neglect can compromise much more than just the “non-sensitive” application data. Consider for example a recent incident at one of the biggest Brazilian mobile companies. An issue was found in a file called popup.php. The code in the file had the apparently simple objective of appending the company logo and loading a given file’s content into a popup window. So the excuse of “non-sensitive” data seemed to apply in this case.

We can easily imagine that the need for this page probably originated in the <insert non-tech department> and got escalated to the tech department with high priority (late on a Friday afternoon). In the rush the priority was to “Just get it done”, and ignore the worries about security. “No problem” you say, “leave it like that during the weekend and redo it on Monday following the proper protocols”. What happens of course is that code is never looked at again….until the day THE EPIC FAIL happens.

In retrospect we can easily see how the popup.php file led to THE EPIC FAIL. The final URL used by the popup.php file had a “url” GET var attached to it, the value of which usually pointed to another html or PHP file. This is an open invitation to try and point the GET to any file that would be “unexpected”, like so:

The result of this request immediately made obvious that at least 2 security issues were overlooked by the developer. Can you see which ones?

The first mistake here was leaving display_errors on – and this shows us the second mistake(s). The obvious one was neglecting to stick to the rule: “Filter input, escape output”. The developer obviously actually executed an include on the file specified in the URL. We can see that he did not check in any way the value provided in the “url” parameter, but he should at least have checked whehther the file was still in the site’s file tree.

To turn this exploit into something dangerous you simply need to start passing it sensitive files, like /etc/passwd or try to load the apache httpd.conf file (which actually worked in this case).

Analyzing these files showed that the problem was severe. The actual site had little valuable information, but it did show that the server had much more on it than just this site – this qualifies as an EPIC FAIL because it compromised all systems on that server. Another factor that contributed to the severity of the problem was Twitter. This flaw was only fixed 2 days after it was first reported and in the interval the detail of the exploit was widely circulated on Twitter, giving everyone the chance to look at configuration and other files. Only the victim knows if any sensitive data was compromised, but given the creativity of hackers nowadays, something was compromised for sure.

This demonstrates that security is not a simple “injection” or “pill” you can give your application after it is live – security needs to come from the ground up, leave the quick fixes for the occasional software bug. Your development cycle must include security concerns in the form of tests, validations or anything else you can think of. OWASP is a great source of points to think about. No feature should roll out the door if it did not take security into consideration. One approach is to incorporate security into your “Definition of Done”, so that a task can only be complete after security steps are taken to validate it. Peer review can further contribute to enhanced security – two heads are better than one. Managers should be as worried about this as the programmers should be. An example of such a Definition of Done is:

• Developed
• Tested (Unit Tests written and executed)
• Documentation (proper doc file or PHPDoc blocks for code segments)
• Peer review
• Security check (for known flaws, like input filtering)
• Load Testing

Every task should include the above. Even though it may cost some project development time, it will save you even more time and effort if someone attempts to hack your site. Including security in the set of tasks gives the developer time to plan each feature and reduces the risk of exploits being released. Taking security into account is part of becoming a professional developer and leaving behind the code-hacker ethic which means just coding and not considering the environment in which the application exists.

Needless to say the security-conscious approach has to be embraced by management because it is usually up to them to fight the battle for more development time and proper development cycles, and not to simply give in to external pressures – which leads to the risk of distributing dangerous code.

Even though it was published in 2005, the issues that “Essential PHP Security” addresses is still very relevant today. Written by Chris Shiflett, the book goes through various security aspects associated with a PHP application, and for that reason its content can be considered up to date and applicable to various day-to- day situations faced by developers.

The book has a very easy going approach to exposing the various aspects of security it addresses. These aspects are very clearly exposed and separated into differenct chapters, covering everything from forms to includes and security in shared hosting environments. Each topic is analyzed in detail and internally divided into exploits and attack strategies for that security flaw. In this way the book becomes an easy to access reference book where its possible to go directly to the chapter that addresses the specific aspect you are coding for right now and allowing you to know which flaws to look out for. The introductory chapter presents Principles and Practice of Security which can be applied in any application and any language, for example “Defense in Depth”, which demonstrates the fact that security is much bigger than merely analyzing specific points of you application.

Even thought is has been published a few years ago, the book addresses topics like XSS that play a important role in the AJAX driven web we observe nowadays. Old friends like Session Hijacking and SQL Injection are analyzed from various points of view, aligned to the various segments of an application. This structure makes for a very light and enjoyable reading experience which can easily be fit into a few spare moments, or even in the waiting room of the occasional visit to the doctor’s office (it worked for me anyway).

This book deserves to be part of any developer’s bookshelf, at least to serve as a reminder and inspiration for reflection, even in a world where more and more Frameworks internalize all aspects of security – but as I always say, we developers should always know what is going on behind the curtains.

Essential PHP Security A Guide to Building Secure Web Applications

By Chris Shiflett
October 2005
Pages: 124
ISBN 10: 0-596-00656-X | ISBN 13: 9780596006563

You can buy the book from Amazon