OWASP Top 10 – 2010
This presentation was by Dave WIchers, COO of Aspect Security and an OWASP Board Member. My notes are below:
What's Changed?
- It's about Risks, not just vulnerabilities
- New title is: "The Top 10 Most Critical Web Application Security Risks"
- OWASP Top 10 Risk Rating Methodology
- Based on the OWASP Risk Rating Methodology, used to prioritize Top 10
- 2 Risks Added, 2 Dropped
- Added: A6 - Security Misconfiguration
- Was A10 in 2004 Top 10: Insecure Configuration Management
- Added: A8 - Unvalidated Redirects and Forwards
- Relatively common and VERY dangerous flaw that is not well know
- Removed: A3 - Malicious File Execution
- Primarily a PHP flaw that is dropping in prevalence
- Removed: A6 - Information Leakage and Improper Error Handling
- A very prevalent flaw, that does not introduce much risk (normally)
- Added: A6 - Security Misconfiguration
- A1- Injection: Tricking an application into including unintended commands in the data sent to an interpreter. (http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
- A2 - Cross Site Scripting (XSS): Raw data from attacker is sent to an innocent user's browser. For large chunks of user supplied HTML, use OWASP's AntiSamy to sanitize this HTML to make it safe. (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
- A3 - Broken Authentication and Session Management: Means credentials have to go with every request. Should use SSL for everything requiring authentication.
- A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
- A5 - Cross Site Request Forgery (CSRF): An attack where the victim's browser is tricked into issuing a command to a vulnerable web application. Vulnerability is caused by browsers automatically including user authentication data with each request. (Check out OWASP CSRFGuard, OWASP CSRFTester, http://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)
- A6 - Security Misconfiguration: All through the network and platform. Don't forget the development environment. Think of all the places your source code goes. All credentials should change in production.
- A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
- A8 - Unvalidated Redirects and Forwards: Web application redirects are very common and frequently include user supplied parameters in the destination URL. If they aren't validated, attacker can send victim to a site of their choice.
- A9 - Insecure Cryptographic Storage: Storing sensitive data insecurely. Failure to identify all sensitive data. Failure to identify all the places that this sensitive data gets stored. Failure to properly protect this data in every location.
- A10 - Insufficient Transport Layer Protection
OWASP Top 10 Risk Rating Methodology
- Attack Vector (How hard for an attacker to use this flaw - 1 (Easy), 2 (Average), 3 (Difficult))
- Weakness Prevalence (How often is it found - 1 (Widespread), 2 (Common), 3 (Uncommon))
- Weakness Detectability (How hard is it for an attacker to find the flaw - 1 (Easy), 2 (Average), 3 (Difficult))
- Technical Impact (1 (Severe), 2 (Moderate), 3 (Minor))
This is generic across the internet, not specific to any organization.
Started a new "Prevention Cheatsheet Series" that the Top 10 references (XSS, SQL Injection, Transport Layer Security, CSRF, Direct Object Reference).
What is actually being released is RC1 of the Top 10 and they are encouraging people to provide comments through the end of the year and then use that feedback to post the final Top 10 in January 2010.
Keynote: Collaboratively Advancing Strategies to Mitigate Software Supply Chain Risks
It's my second year at the OWASP AppSec Conference and this year it is in Washington, DC. The New York City Conference last year proved to be probably the best conference I've ever been to. Based on the agenda and the facilities, this year is looking very promising. Today's keynote is by Joe Jarzombeck, the Director for Software Assurance at the National Cyber Security Division for the Office of the Assistant Secretary of Cybersecurity and Communication. Man, is that a mouthful. My notes on the presentation are below:
DHS NCSD Software Assurance Program
- A public/private collaboration that promotes security and software resilence throughout the SDLC
- Reduce exploitable software weaknesses
- Address means to improve capabilities that routinely develop, acquire, and deploy resilent software products
- IT/Software Security risk landscape is a convergence between "defense in depth" and "defense in breadth"
- Applications now cut through the security perimeter
- Rather than attempt to break or defeat network or system security, hackers opt to target application software to circumvent security controls
- 75% of hacks are at the application level
- Most exploitable software vulnerabilities are attributed to non-secure coding practices
- Enable software supply chain transparency
- Acquisition managers and users factored risks posed by software supply chain as part of the trade-space in risk mitigation efforts
- DHS Software Assurance program scoped to address:
- Trustworthiness
- Dependability
- Survivability
- Conformity
- Standalone Common Body of Knowledge (CBK) drawing upon contributing companies/industries
Build Security In: https://buildsecurityin.us-cert.gov
- Focus on making software security a normal part of software engineering
- Process agnostic lifestyle
- There was an interesting slide on touchpoints and artifacts that I took a picture of with my phone and I will try to post here.
Resources to Check Out
"Software Security Engineering: A Guide for Project Managers"
"Enhancing the Development Lifecycle to Produce Secure Software"
Fundamental Practices for Secure Software Development
http://www.safecode.org/publications/SAFECode_Dev_Practices1008.pdf
The Software Assurance Pocket Guide Series
Software Assurance in Acquisition: Mitigating Risks to the Enterprise
- Check out Appendix D - Software Due Diligence Questionnaires
"Making the Business Case for Software Assurance"
"Measuring ... Assurance"
Common Weakness Enumeration (CWE)
- If you have this weakness, then it's not a matter of if, but when you'll be breached.