Yesterday, we released Trustwave's Global Security Report 2011 (short registration required). This report encompasses data gathered by the SpiderLabs Team during 220 forensic investigations and over 2,300 manual penetration tests. Notice the word "manual" was highlighted right? That means that this data was not gathered through the use of automated scanning tools but rather by manually testing target networks and applications. This means that we are able to dig in deeper into the target web application and uncover vulnerabilities that automated tools alone would never identify. While there is a ton of great data within the GSR 2011 report, for this blog post, I wanted to focus a bit of attention to the web application sections of the report.
Top 10 Web Application Risks
This Top 10 list was gathered by the Trustwave SpiderLabs Application Pentest Team. The attacks and vulnerabilities listed below are ranked by collective threat, based on the frequency of findings, difficulty in launching the attack and the potential impact when exploited by criminals. The report explains:
For example, while SQL injection is not the most common vulnerability we encounter, the potential for the bulk extraction of sensitive data makes it the number one threat of 2010. Conversely, cross-site request forgery (CSRF) is one of the most common application vulnerabilities, but requires a more complicated attack scheme, relegating it to eighth on the list.
Here is the Top 10 List:
- SQL Injection
- Logic Flaw
- Authorization Bypass
- Cross-site Scripting (XSS)
- Authentication Bypass
- Vulnerable Third Party Software
- Session Handling Flaw
- Cross-site Request Forgery (CSRF)
- Verbose Errors
- Source Code Disclosure
If you cross-reference our Top 10 list with the well-known OWASP Top 10 for 2010, you will see some discrepancies. This is mainly attributed to the fact that we had a concrete data set to work from vs. abstractions of Top 10 lists from various participating organizations in the OWASP Top 10.
Actively Targeted Vulnerabilities
The Top 10 list above is certainly interesting data and should help organizations to prioritize their remediation efforts, however it does not tell the whole story. The issues that the SpiderLabs Application Pentest Team identifies are possible methods of which an attacker could compromise the application. Therefore, the next step to take is to cross reference these particular vulnerabilities with the attack vectors used in real-world web application compromises gathered by the SpiderLabs Incident Response/Forensic Teams. The Infiltration sub-section of the Incident Response Investigations section of the GSR 2011 lists the top web application attack method as SQL Injection:
Even after a decade, SQL injection continues to be the most popular method of entry for Web-based applications; it is a perfect example of attackers only working hard enough to identify a vulnerability affecting many or all payment applications, and then take advantage of it. In 2010, more SQL injection attacks resulting in system-level shell access were observed. Traditional SQL injection attacks typically result only in the extraction of data residing within the backend database. As entities continued to eradicate the storage of unencrypted data within these databases, attackers relied on advanced SQL injection techniques to obtain access to usable data. In most instances, advanced SQL injection allowed attackers to obtain system-level shell access and to then modify Web code to harvest sensitive data during the submission of the data within the Web form.
A public example of this type of SQL Injection methodology can be found in the WASC Web Hacking Incident Database (WHID) entry WHID 2009-29: FBI & Secret Service warn of a sophisticated HSM attack. The data presented by the FBI/SS shows how attackers are able to use SQL Injection to install OS level sniffing programs in order to capture credit card data in transit.
Lessons Learned
If you were to have one takeaway from today's blog post, it should be to validate how your web applications use back-end databases. Have your developers review the OWASP SQL Injection Cheatsheet document and then implement a plan to have your environment actively assessed for weaknesses
