Tuesday, February 16, 2010

CWE/SANS Top 25 Most Dangerous Programming Errors 2010 - WebApp Focus Profile

Submitted by Ryan Barnett 2/16/2010

Mitre and the SANS Institute have once again teamed up to create the new 2010 CWE/SANS Top 25 Most Dangerous Programming Errors list. As opposed to the OWASP Top 10 Web App Security Risks list, the CWE/SANS list includes all software so many of the issues raised are not applicable to web apps. One of the cool features of the new list, however, is the inclusion of "focus profiles" which provides a more focused, contextual view of the issues. I was able to work on a web application-specific focus profile of the list and I will present it below. Keep in mind that this is not an official list yet however I will continue to work with Steve Christey in order to complete the development.

Web Application Emphasis
This profile ranks weaknesses that are important from a web application perspective. The list maps its base CWE components from the Insecure Interaction Between Components Category-base view as these items are all directly related to web application isues. This data was then correlated with the OWASP
Top Ten Project, the Web Application Security Consortium (WASC) Threat Classification and takes a priority ranking focus based on real-world web application compromise data as gathered by the WASC Web Hacking Incident Database (WHID). The inclusion of WHID data allows for this focus profile to factor not only Prevalence and Importance but also Attack Frequency data. This accounts for the adjustments to the ranking order and the discrepancies between the individual lists. Each entry includes relevant mappings/references to the OWASP Top 10, WASC Threat Classification and WASC WHID Entries.

Combined Top 10 List (CWE/SANS, OWASP Top 10, WASC Threat Classification, WASC WHID)

  1. CWE-89: Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection')
    OWASP A1: Injection
    WASC-19: SQL Injection
    WHID: SQL Injection


  2. CWE-79: Failure to Preserve Web Page Structure ('Cross-site Scripting')
    OWASP A2: Cross-site Scripting (XSS)
    WASC-8: Cross-site Scripting (XSS)
    WHID: XSS


  3. CWE-307: Missing Authentication for Critical Function
    OWASP A3: Broken Authentication and Session Management
    WASC-01: Insufficient Authentication
    WHID: Insufficient Authentication


  4. CWE-307: Improper Restriction of Excessive Authentication Attempts
    OWASP A7: Failure to Restrict URL Access
    WASC-11: Brute Force
    WHID: Brute Force


  5. CWE-352: Cross-Site Request Forgery (CSRF)
    OWASP A5: Cross-site Request Forgery (CSRF)
    WASC-9: Cross-site Request Forgery (CSRF)
    WHID: CSRF


  6. CWE-209: Information Exposure Through an Error Message
    OWASP A6: Security Misconfiguration
    WASC-13: Information Leakage
    WHID: SQL Injection -> Information Leakage


  7. CWE-327: Use of a Broken or Risky Cryptographic Algorithm
    OWASP A3: Broken Authentication or Session Management
    WASC-18: Credential/Session Prediction
    WHID: Credential/Session Prediction


  8. CWE-285: Improper Access Control (Authorization)
    OWASP A7 – Failure to Restrict URL Access
    WASC-02: Insufficient Authorization
    WHID: Insufficient Authorization


  9. CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
    OWASP A4: Insecure Direct Object Reference
    WASC-33: Path Traversal
    WHID: Path Traversal


  10. CWE-78: Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection')
    OWASP A1: Injection
    WASC-31: OS Commanding
    WHID: OS Commanding

2 comments:

Unknown said...

Ryan, I've been reading some of your posts on web hacking incidents, and am interested in your perspective on the most common targets and victims of such attacks. In my experience, packaged applications, whether commercial or open source, are the victims of most web hacking incidents. (Leaving aside commercial web services such as Twitter, GMail, etc., which I would categorize as packaged applications).

Therefore, I believe that enterprise custom-built applications are rarely the victims of such attacks, as the attack must be custom built to work against the app. For packaged applications, we are seeing an increasing number of automated tools developed which can efficiently exploit packaged applications and find victims using search engines.

Given your experience with web application incidents and statistics, what is your perspective?

-Martin Nystrom

Ryan Barnett said...

Hey Martin, it has been a long time :)

With regards to your comment on top targets, you can check out the WHID Top Attacked Vertical Market view here - https://wasc-whid.dabbledb.com/publish/wasc-whid/293f30b1-acbf-4426-bf36-11241d4db62b/verticalmarketview-2010.html As far as top attacked software packages, we do list what the software was that was exploited.

I would agree with your statement that public software (commercial/open source) is attacked and compromised more from a statistical perspective however I would not say that custom built apps are *rarely* attacked. They are attacked all the time however they are manual in nature. You mentioned the rationale for your statement - which is that the bad guys are able to leverage economies of scale to mass-exploit known public software. Just reference the Mass-SQL Injection Bot attacks of the past two years.

Your point is true in that in order to successfully compromise a custom built app, the attacker is going to need to poke and prod around and find a vuln. This, in my opinion, does offer a window of time where defenders may be able to identify the recon and take some evasive actions. This of course is predicated on the concept that organizations have properly instrumented their web apps with proper detection points and logging details.

When you have these attack payloads that target packaged apps, however, then you dealing more with a sniper-type of attack where they are launching only 1 request. This means that your window of time for monitoring and response is eliminated and you had better have protected against the vuln.