OWASP Periodic Table of Vulnerabilities James Landis
[email protected]
The AppSec Profession
~1980-????
Project Goal GOAL
Existing ‘Taxonomies’
OWASP Top Ten (2013)
• Focuses on just the riskiest issue categories • Measures DREAD attributes • Recommends high-level solutions, and secure libraries like ESAPI
• Attempts to enumerate, but not classify, all web WASC Threat application attacks and weaknesses Classification • Includes a view (Development Phase View) which (v2) shows SDLC mapping • Officially avoids recommending solutions SANS Common • Focuses on riskiest issues (just more of them) Weakness • Measures DREAD attributes Enumeration • Recommends solutions, categorized by SDL phase (CWE-25)
Failed Approaches
• Developer Training • “Enumerating Badness”, “Penetrate and Patch” (h/t Marcus Ranum) – Some vulnerability classes, automated tests – Yes! – Other classes (e.g. Logic flaws), manual tests – No!
• Firewalls • Root cause analysis (XSS == SQLi, XSS != SQLi) • Everything else we’ve been doing
Solutions?
• Accepting Reality – HTTP not stateless – People might try to hurt us
• Platform Security Continuum Vulnerable by Default
Secure by Design
• Make it impossible to make mistakes • Economies of Scale
Divide and Conquer
Browsers and Standards Perimeter and Platform
Generic Frameworks Custom Frameworks Custom Code
User agents, plugins, HTTP protocol, SSL/TLS, Content Security Policy (CSP), Same Origin Policy (SOP), IETF RFC, etc. Application proxies, content distribution networks (CDNs), application firewalls, web servers, database servers, application servers, operating systems, etc. Web application runtime environments Development platforms unique to individual businesses/verticals Business logic unique to each application
Economies of Scale
Browsers and Standards
WebDev Mistakes
Code Changes
Perimeter and Platform
Generic Frameworks Custom Frameworks Custom Code
Impact
Scope
• Avoid reproducing existing documentation – Describe just enough of the solution to show how it’s distributed between targets – References, references, references!
• Minimize original research – Most solutions enforce old ideas in frameworks – Browser/standards require some new thought
• Mobile, thick client vulnerabilities excluded
Metaphor
Results!
OWASP'Periodic'Table'of'Vulnerabilities Perimeter'and'Platform
Generic'Framework
Custom'Framework
Legend
Browsers'and' Standards'@ ' Session' Management
Browsers'and' Standards'@ ' Content' Management
Custom'Code
Selected Examples
Perimeter Browser Generic Custom Vulnerability /Infrastructur Custom Code /Standards Framework Framework e Clickjacking
Browser vendor standardization on safe framing
CSRF
Change default for cross-domain writes
Improper Input Handling
Abuse of Functionality
Automatically set X-Frame-Options header
Configurable XFO policy
Automatic nonce checking, configurable Provide APIs for Provide APIs for positive positive validation validation of of custom types common types
Never use primitives
Define abuse cases for all features
Case Study - XSS
• Decouple presentation and data – easy with AJAX, not with Web 1.0 • What if content IS markup? • Secure framework might have steep learning curve / difficult adoption path • Browser sandboxing • CSP, Caja, IFRAME seamless/sandbox
Developer Training
BEFORE
XSS SQLi
CSRF HTTPRS Clickjacking Application DDoS Improper Input Handling Redirector Abuse Logical Flaws Remote File Include OS Commanding XML External Entities
AFTER Logical Flaws Function Abuse Input Validation Secure Framework
Drawbacks and Benefits
• DOESN’T help us with legacy/current applications • DOES help drive remediation planning / gap analysis in existing applications • DOES focus remediation toward areas with greatest force multiplier (e.g. Top Ten Defenses) • DOES allow objective evaluation of firewalls and frameworks
Q&A
