OWASP Periodic Table of Vulnerabilities James Landis

The AppSec Profession ~1980-????

GOAL Project 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 WASC Threat Classification (v2) Attempts to enumerate, but not classify, all web application attacks and weaknesses Includes a view (Development Phase View) which shows SDLC mapping Officially avoids recommending solutions SANS Common Weakness Enumeration (CWE-25) Focuses on riskiest issues (just more of them) Measures DREAD attributes Recommends solutions, categorized by SDL phase

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 Make it impossible to make mistakes Economies of Scale Vulnerable by DefaultSecure by Design

Divide and Conquer Browsers and Standards User agents, plugins, HTTP protocol, SSL/TLS, Content Security Policy (CSP), Same Origin Policy (SOP), IETF RFC, etc. Perimeter and Platform Application proxies, content distribution networks (CDNs), application firewalls, web servers, database servers, application servers, operating systems, etc. Generic Frameworks Web application runtime environments Custom Frameworks Development platforms unique to individual businesses/verticals Custom CodeBusiness logic unique to each application

Economies of Scale Browsers and Standards Perimeter and Platform Generic Frameworks Custom Frameworks Custom Code WebDev Mistakes Impact Code Changes

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!

Selected Examples Vulnerability Browser /Standards Perimeter /Infrastructur e Generic Framework Custom Framework Custom Code Clickjacking Browser vendor standardization on safe framing Automatically set X-Frame-Options header Configurable XFO policy CSRF Change default for cross-domain writes Automatic nonce checking, configurable Improper Input Handling Provide APIs for positive validation of common types Provide APIs for positive validation of custom types Never use primitives Abuse of Functionality 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 XSS SQLi CSRF HTTPRS Clickjacking Application DDoS Improper Input Handling Redirector Abuse Logical Flaws Remote File Include OS Commanding XML External Entities BEFORE 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