OWASP Periodic Table of
Vulnerabilities
James Landis
james.landis@owasp.org
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