owasp periodic table of vulnerabilities

OWASP Periodic Table of Vulnerabilities

James Landisjames.landis@owasp.org

The AppSec Profession

~1980-????

GOALProject 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 Default Secure 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 Code Business logic unique to each application

Economies of Scale

Browsers and Standards

Perimeter and Platform

Generic FrameworksCustom FrameworksCustom 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

eGeneric

FrameworkCustom

Framework Custom Code

ClickjackingBrowser vendor standardization on safe framing

Automatically set X-Frame-Options

headerConfigurable

XFO policy

CSRFChange 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 typesNever 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

XSSSQLi

CSRFHTTPRS

ClickjackingApplication DDoSImproper Input Handling

Redirector AbuseLogical Flaws

Remote File IncludeOS Commanding

XML External Entities

BEFORE AFTER

Logical FlawsFunction AbuseInput 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