In the wake of the latest Yahoo password breach, I scratched my head and thought to myself “are we REALLY still talking about this, especially at big companies like Yahoo”?
According to data published from Privacyrights.org (download the .csv file), SQL injection was the means used to extract 83 percent of the total records stolen in hacking-related data breaches from 2005 to 2011. Buffer overflow attacks are decreasing as organizations have done a better job at fixing those issues and frameworks like .NET, Java, Ruby and Python mitigate the risk – yet the same SQL threats that have existed for the past decade still exist. I believe this is for two reasons:
- Legacy– There are millions of lines of code out there that interact with SQL databases. In a green-field dev shop building on .NET or RoR it’s possible to take care of SQLi as it’s happening. Retroactively finding all the SQL commands in your eCommerce website is harder, especially with untrained developers.
- Missing the issue once – Its true, developers and security folks have to find and fix every, single, vulnerability and that’s hard. The bad guys have all the time in the world to find just one. However, I should say, the SQLi that people are finding now are not difficult to find. They should be considered very low hanging fruit.
SQL injection is a pervasive problem and one that we find in most applications that we test for our clients. In addition to data recovery attacks like the Yahoo disclosure, you can also get direct server command injection as well. It's very easy to fix and many modern frameworks do a very good job of it. The Entity Framework for .NET, Ruby on Rails, or Django for python all have their own ORM (Object Relational Mapping) components that make SQL injection much more difficult to write. Older languages like PHP are still fairly vulnerable as they usually rely on input filtering alone to secure their SQL.
The basis of almost all of the advanced Sony attacks were SQLi, as was the LinkedIn and LastFM breaches. Finding SQL injections in your applications is fairly easy to do. You can use tools like SQLmap to automate advanced attacks.
The optimistic in me says things are getting better, but not nearly fast enough. There are still so many legacy applications in production that have very little to no protection against SQL injection, and that’s a serious problem. Web Application Firewalls (WAFs) can help, but they're just a Band-Aid (and can block good traffic if misconfigured, which they often are.) The real fixes have to come from systemic use of Stored Procedures, Parameterized Queries, input validation, and judicious application of the principle of Least Privilege.
I also wrote a blog on Cross-Site Scripting (XSS) and how that still exists as well. Check it out.
