Security is a recurring topic when discussing Technology. Taking security for granted when you are developing an application, even if it is a very simple application is a huge mistake which can have grave consequences.
I have ran into many excuses for ignoring security – especially this one: “This is just a simple application, it has no sensitive data”. The point may seem valid to the developer who is under immense time pressure, but the consequences of neglecting security can be serious. Cal Evans in his Open Teams session demonstrates the impact of deadlines when he tells us about a project with an impossible due date. Upon questioning the due date to the marketing department their reply was simple: “Because that’s when the brochures are done”. This demonstrates the all too frequent lack of understanding of the complexity of issues around web development shown by the business side of organisations.
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.
Related Posts
