Earlier this week, Imperva Data Security Blog posted an article and whitepaper by Amichai Shulman lamenting the continued evils of PHP as a language because of the use of “SuperGlobals”. Here are a few reasons why the article is FUD.
The Blog
I’ll begin with the blog article since most people won’t read the full whitepaper.
The ADC research group has been studying the implications of third-party applications on the security posture of organizations.
Although Shulman points out that PHP powers over 80% of all websites, they implicitly equate PHP with 3rd party applications. If PHP is a 3rd party app, then so is .Net, Java, Python, Ruby and all the other programming languages out there. Only in the whitepaper does it become clear that they want to point out a particular 3rd party app.
Q: If the intent not to simply bash PHP, what justification can you provide to a fully functional programming language a 3rd party application? Or was this just a case of poor writing?
In the PHP architecture, several variables in the application are not explicitly defined in each script. These variables are called PHP SuperGlobals.
It is true that PHP, as a web language, does reserve a few variables, such as $_GET , $_POST, and $_COOKIE. It so happens that having these variables makes it much easier to design web applications which constantly refer to them. If you are using a PHP framework like ZF2 or Laravel, you access these through more abstracted means. If you are using a web framework (regardless of programming language) you will have access to a vast array of variables that you did not explicitly define.
Q: If your website has no need to interact with user input on the server level (GET/POST/…), why would you use PHP in the first place? Just use straight html and maybe toss in some javascript. Heck, get fancy and use Angular.js
Ever since the PHP platform was introduced, the interaction between PHP SuperGlobals and user input has represented a security risk.
The interaction between any language and user input has represented a security risk since the first programs were created. Heck, the Analytical Engine probably had a few hazards. I will whole heartedly agree that there is a problem between beginner & lazy programmers and how they use PHP’s SuperGlobals w.r.t. things like SQL Injection. I shudder to think of some of my original code, as much as I shudder rewriting someone else’s code at my current job. But the problem is not (at this point in time) between the SuperGlobals and user input. The problem is how we use those variables.
The Whitepaper
The researchers at Imperva set up some honeypots to see what nastiness was being sent across the interwebs.
Over the course of a month, our research team witnessed ~144 attacks per application (within a sample of 24 applications) that contained attack vectors related to SuperGlobal parameters.
Without specifying which SuperGlobal parameters, this is statement amounts to: “that contained attack vectors related to user input.” One needs to read several more pages of the whitepaper to get to the specific vulnerabilities with which they have concerns.
The author finally switches to what could rightly be called a 3rd party application: PhpMyAdmin. I cannot speak to the complexity of the mentioned vulnerability in PhpMyAdmin. I can speak, however, on the ease of which I was able to find out that the vulnerability was fixed 2011-07-03, when version 3.4.3.1 came out. The current version of PhpMyAdmin is 4.0.6.
Q: If you are going to pick a vulnerability, why pick one that was resolved over 2 years ago?
Our next dire vulnerability comes to us via CVE-2010-3065, a session modification hack that was fixed in 2010-07-22, ever further back than the previous exploit.
Q: If you are going to pick a vulnerability, why pick one that was resolved over 3 years ago?
What They Missed
I see three main recommendations that Imperva missed by a parsec:
- I find it very odd that Imperva failed to mention one of the most basic web security practices: filter all input. All serious web applications need access to parameters such as GET/POST/COOKIE. They will also most likely have some means of session storage. PHP just happens to make it easier. So what? Additionally, most languages require extra packages/libs to perform the input filtering. Nothing new here.
- Keep your servers and applications up-to-date. It is your responsibility as a developer to make sure they sysadmin keeps up with the releases. If they aren’t, or aren’t willing to, switch providers or get a new sysadmin who cares about security.
- Configure superuser apps like PhpMyAdmin to only listen on dedicated interfaces. Sure, they are powerful and in some cases, easy to misconfigure. That doesn’t mean we stop using them. We tell people how to use them correctly.
Feel free to send me comments on others I missed.
Conclusion
I am not sure whether or not to consider Imperva a professional group after reading their whitepaper. The whitepaper makes it seem that they were testing the latest/greatest versions of everything, which they patently weren’t. Bashing PHP for issues that were fixed 2-3 years ago is just setting up a straw-man (CVE-2010-3065 was created a month after the problem was fixed). One of the strengths of the PHP community is that vulnerabilities are fixed within hours of being reported.
- Imperva failed to mention at least three key components of webapp security, while tossing in buzzwords like SQL Injection.
- Even though Imperva points out that some of the largest sites on the net use PHP, they fail to comment why sites like the Open Web Application Security Project use the language. I think that Facebook, Baidu, and Wikipedia all have security staff on board who would have picked a different language if PHP was really so drastically insecure.
- Imperva fails to give the most basic solutions to the old problems identified.
As the Imperva author himself says:
Some of these questions are mind blowing, and yet for many they remain unanswered.
At least they are already answered for the rest of us. And the answers are free.
I would be tempted to say that the article should have recommended an IDS solution like PHP-IDS or Expose as an extra layer of security, but I guess they are trying to sell their services in addition to FUD.