3 posts from September 2013
September 24, 2013
 Lost and Found in the Dark
Pin It

IStock_000010945810XSmallA recent DarkReading article by Robert Lemos covers the lack of security expertise in companies developing in-house applications. This timely article explains the importance of sourcing security expertise from firms that are focused on application threats (and the application of fixes to these found problems).

My recent post about SQL Injection (SQLi) findings, which references Veracode’s infographic and the pervasive lack of application-security awareness, notes that 30% of breaches still come from SQLi. This data point clearly points out the lack of awareness at minimum, but also suggests that most organizations don’t really know how to deal with the problem.

The DarkReading article could have gone further by covering what a fix is, and what applying a control to a problem really means for an organization. Just as organizations require expertise in uncovering vulnerabilities, they also need expertise in fixing these — both are critical and ongoing processes. Hence, finding the problem and fixing it must go hand in hand

One reason we invest so heavily in our ADC research team is the acknowledgment that our customers depend on us to mitigate web security threats. At the end of day, a WAF is application security expertise packaged in a product to mitigate web threats.

What can you do to fix web application vulnerabilities?

  • Educate yourself about web application security risks
  • Choose a company expert at helping you identify web application security problems in your own data center.
  • Mitigate the discovered problems (and other undiscovered problems) using a WAF. One example is our collaboration with WhiteHat.
  • Fix the code and patch the systems. Although not all problems can be fixed by a code patch, this is an important step in lowering the overall risk.


September 18, 2013
 SQLi still Alive and Kicking
Pin It

Alive-and-kickingRecently, Veracode published a compelling Infographic on the true costs of a data breach.

According to the graphic 30% of data breaches are caused by SQL Injection. How is that still possible? SQL Injection was solved 10 years ago with the introduction of the positive security model with Web Application Firewalls and with proper code audits. Sadly, we still see major data breaches caused by a dated attack vector caused by the following:

  • Misinformation of security officers, who are made to believe that signature-based technologies such as IPS would stop SQL Injection. In a previous article we explored the differences between an IPS and a WAF and why SQL Injection still prevails.  
  • The classic “I’m a small shop, no one targets me” misconception, that leads unaware business owners to believe that SQL Injection attacks and other web attacks are only targeted or worse – only targeted at big companies. Credit card data stored in a small mom-and-pop shop database has the same value of one stored at a large bank database.

Where can I learn more?

  1. “What the IPS Didn’t See” article, here
  2. “The Future of Web Security” article, here


September 08, 2013
 PHP SuperGlobals: Supersized Trouble
Pin It
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.



Find Us Online
RSS Feed - Subscribe Twitter Facebook iTunes LinkedIn YouTube
Monthly Archives
Email Subscription
Sign up here to receive our blog: