PHP Security: Are you paying attention?

Security is a recurring topic when the talk is about Technology, or any other area for that matter. To take security for granted when you are developing an application, as simple as it may be, is a huge mistake which can take a turn for the worse. I have ran into lots of excuses for ignoring security in the past, one of them is the recurring "This is just a simple application, it has no sensitive data",  this may be a valid point for the person repeating it like a mantra, especially because this person is generally suffering of great pressures , short timeframes and a lack of proper management ready to deal with web development. Cal Evans in his Open Teams session gives a perfect example of this when he tells us about a project with an impossible due date. Upon questioning the due date to the marketing department their reply was straight forward: "Because that's when the brochures are done". This is an example of the lack of perception around web development and all the issues we need to take into consideration when developing applications.

Whatever the reason is for neglecting security the consequences can escalate much higher then the "non-sensitive data" of the application. I can cite a recent example that happened to one of the biggest Brazilian mobile companies. A simple issue was found in a file called popup.php, the objective of the file fits into the excuse mentioned above, it just had to append the company logo and load a given file's content into a popup window.

Doing a little play my part simulation we can easily imagine that the need for this page probably started in the <insert non-tech department> and got to the tech department with urgent priority, usually on a Friday EOD, when the manager is leaving and the developers are just waiting for the boss to leave in order to get to the closest bar for a happy hour. In the rush of things neglecting security and any other management process the order is "just do it". This generally leads to the easiest way out, so that whatever purpose the fix fits will be live before the weekend. No problem you say, "leave it like that during the weekend and redo it on Monday following the proper protocols", that's iffy behavior none the less, but in a real world example this feature will only be revisited on one occasion: the day it does an EPIC FAIL.

Doing a post-mortem analysis on the flaw i described, we can easily find out what happened. The final URL used by the popup.php file had a "url" GET var attached to it, the value usually pointed to another html or PHP file. This was the first indication that this was a sleeping time bomb, so the first thing someone tried was to point that to a file, any file that would be "unexpected", like so:

The result of this request exploded directly into our face 2 security issues overlooked by the developer. Can you guess which ones?

Ok, so the first mistake here was leaving display_errors on, lack of doing so now shows us the second mistake which can be one or two depending on how you think of it. The obvious on is neglecting the security karma everyone needs to know whick is: "Filter input, escape output". Obviously since he actually executed a include on the file given we can say that he did not check in any way the value provided in the "url" parameter, in the least he should have checked if it was still in the site's file tree.

To make this exploit something dangerous you just need to start passing it usual sensitive linux files, like /etc/passwd or try to load the apache httpd.conf file, which BTW actually worked

Analysing these files showed that the issue was really bad, the actual site really had few valuable information, but it did show that the server had much more on it then just this simple site, hence the EPIC FAIL and domino effect of compromising all systems on that machine. Another factor makes this become epic, Twitter. This flaw was only fixed 2 days after the first report and in the meantime it ra circles around twitter, giving everyone the chance to look at conf files and whatever else they could think of looking for. Only the victim can tell if any sensitive data was compromised, but giving flaw and the creativity of hackers nowadays, something was compromised for sure.

So security is not a simple "injection" or "pill" to give your application after its live, security needs to come from the ground up, leave the pills for the occasional bug which will always come up, after all its software. You development cycle needs to include security topics, be them, tests, validations or anything you can think of, OWASP is a great source for points to think about. No feature should roll out the door if it did not take this into consideration, one idea is to incorporate security into your Definition of Done, so a task can only be complete after security steps are taken to validate it, peer review and tests can also contribute to this, two heads are better then one. Managers should be as worried about this as the programmers. An example of 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 needs to include this, tough it may cost valuable project development time, it will save you even more valuable lawsuits if your site get hacked.This gives the developer time to plan each feature and reduces the risk of exploits going out the door. This is part of becoming a professional developer and leaving behind the code-hacker nature which just codes and does not consider the environment around the application. Needless to say this has to be embraced by management because its usually up to them to fight the battles for longer timeframes and proper development cycles, not just succumb to external pressures and risk distributing dangerous code.