September 08, 2013
PhpIn our latest HII report, we dissect a problem that has been around for ages. The ADC research group has been studying the implications of third-party applications on the security posture of organizations. Attackers are always streamlining their activities and therefore aiming at commonly used third-party components that yield the best return on investment. With that in mind, we investigated one of the most commonly used web infrastructures: PHP.

The PHP platform is by far the most popular web application development platform, powering over 80% of all websites, including top sites such as Facebook, Baidu, and Wikipedia. As a result, PHP vulnerabilities deserve special attention. In fact, exploits against PHP applications can affect the general security and health status of the entire web, since compromised hosts can be used as botnet slaves for further attacks on other servers.

In the PHP architecture, several variables in the application are not explicitly defined in each script. These variables are called PHP SuperGlobals.

Ever since the PHP platform was introduced, the interaction between PHP SuperGlobals and user input has represented a security risk. Despite recommendations by application security experts, this interaction is still here today – probably due to the high flexibility it provides to programmers and due to the amount of legacy code written this way.

Two of the vulnerabilities mentioned in our report date back to 2010 and 2011. Unfortunately, they are still actively and successfully being used in combination with other legacy PHP security issues. That is exactly the problem! We should have gotten rid of the easy path from user input to SuperGlobals a long time ago.

Does this teach us something about patching known problems in the software development lifecycle as a security strategy? Does it imply that one should only trust a 3rd-party application layer security solution that tracks attacks in the wild? SQL injection is also old news. Does this have any effect on SQL injection still being the #1 threat to web applications? Some of these questions are mind blowing, and yet for many they remain unanswered.

Our research explores PHP vulnerabilities and the methods hackers use to exploit them in the wild. We also provide an analysis and specific recommendations on how organizations should prepare and deal with the long-standing security risks of PHP SuperGlobals.

To download the research paper, please click here.
Share:

Posted by Imperva Blogger at 11:24:30 PM


Tags:

Comments

  • PHP is in fact a third party component, a framework in this case. As a matter of fact any middleware component introduces the risk mentioned. when you look at frameworks such as Java for instance, there have been numerous vulnerabilities reported in the past couple of years within the framework that rendered Java based applications vulnarable. the only fixes were to either patch Java or put a compensating control of some sorts.

  • When did PHP became known as a third-party application? By your definition, it seems to me that .net, java, coldfusion, python, perl, ruby, and pretty much every other programming language out there would need to be called a third-party app.

  • This makes me laugh a little bit. As a long-time PHP developer, I see this "supersized issue" as a misnomer. The fact that PHP has superglobals isn't the issue here. There's plenty of web-centric languages that have a similar feature and allow for direct access to the GET/POST/etc data. The real focus here should be the fact that a lot of the PHP applications out there *use* the superglobal values without doing any kind of validation or filtering.

    There's plenty of libraries and built-in functions for the language that help with this, but the larger issue is education (just like with any other community). It's a known fact that PHP developers, as a whole, are not taught proper security concepts from the get go. As a result, they write vulnerable code, but - restating my original point - the fact that PHP has these superglobals that let you access this information is not the threat. It's poor coding practices, something that can happen in any language, not just PHP.

    I don't particularly agree with your last point on the Recommendations section, though. Using the superglobals should not be blocked as there's no other way in PHP to access that kind of information. You're essentially taking away PHP's ability to read anything from the URL, POSTed data and the sessions. What you *should* be recommending/advocating is the proper filtering and validation of these values instead.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.