Making Web Development “Secure By Default” !
Adam Goodman 2014-05-31
The OWASP Top 10
2004: • Unvalidated Input
• Broken Access Control
• Broken Authentication and Session Management
• Cross Site Scripting
• Buffer Overflow
• Injection
• Improper Error Handling
• Insecure Storage
• Application Denial of Service
• Insecure Configuration Management
The OWASP Top 10
2004: • Unvalidated Input
• Broken Access Control
• Broken Authentication and Session Management
• Cross Site Scripting
• Buffer Overflow
• Injection
• Improper Error Handling
• Insecure Storage
• Application Denial of Service
• Insecure Configuration Management
2013: • Injection
• Broken Authentication and Session Management
• Cross Site Scripting
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Function Level Access Control
• Cross-Site Request Forgery
• Using Components with Known Vulnerabilities
• Unvalidated Redirects and Forwards
2004: • Unvalidated Input
• Broken Access Control
• Broken Authentication and Session Management
• Cross Site Scripting
• Buffer Overflow
• Injection
• Improper Error Handling
• Insecure Storage
• Application Denial of Service
• Insecure Configuration Management
2013: • Injection
• Broken Authentication and Session Management
• Cross Site Scripting
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Function Level Access Control
• Cross-Site Request Forgery
• Using Components with Known Vulnerabilities
• Unvalidated Redirects and Forwards
Success Story: Buffer Overflow
Buffer Overflow - Review
void bad_idea(const char *input) {! char buf[10];! strcpy(buf, input);! /* ... */!}!!
int main(void) {! bad_idea("This is a longish string");! return 0;!}!
Buffer Overflow - Review
void less_bad_idea(const char *input) {! char buf[10];! strlcpy(buf, input, sizeof(buf));! /* ... */!}!!
int main(void) {! less_bad_idea(“This is a longish string");! return 0;!}!
Microsoft SDL
http://blogs.msdn.com/b/bryang/archive/2011/04/01/security-development-lifecycle.aspx
Best Practices
• “Deprecate Unsafe Functions” - no more strcpy, strcat, …
• Training
• Code reviews
• Automated enforcement (framework changes, analysis tools, …)
Compiler Smarts
void less_bad_idea(const char *input) {! char buf[10];! /* MSVC 2005 and newer; C++ only */! strcpy_s(buf, input);! /* ... */!}!
!
!
(Similar: FORTIFY_SOURCE in gcc)
Exploit Mitigation
Make it less feasible to exploit bugs (i.e. turn “security bugs” back into “ordinary bugs”):
• Stack Smashing Protection (SSP)
• Data Execution Prevention (DEP / NX)
• Address Space Layout Randomization (ASLR)
Encapsulate Hazardous Code
We don’t write web apps in C/C++ anymore.
!
Most of our high-level languages and web servers are still built on C, but these are carefully-curated components written by skilled developers with lots of review (we hope!).
(We’re Not There Quite Yet)
http://xkcd.com/1354/
To Review
Hypothesis: Buffer overflows fell off the OWASP Top 10 thanks to
• Concerted efforts to define and (automatically!) detect anti-patterns
• Better tooling to simplify code / limit human error
• Catch-all exploit mitigation technologies
• The simple fact that we don’t build web apps in C/C++ anymore!
To Review
Hypothesis: Buffer overflows fell off the OWASP Top 10 thanks to:
• Concerted efforts to define and (automatically!) detect anti-patterns
• Better tooling to simplify code / limit human error
• Catch-all exploit mitigation technologies
• The simple fact that we don’t build web apps in C/C++ anymore!
!
How can we apply these ideas to other classes of bugs?
2004: • Unvalidated Input
• Broken Access Control
• Broken Authentication and Session Management
• Cross Site Scripting
• Buffer Overflow
• Injection
• Improper Error Handling
• Insecure Storage
• Application Denial of Service
• Insecure Configuration Management
2013: • Injection
• Broken Authentication and Session Management
• Cross Site Scripting
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Function Level Access Control
• Cross-Site Request Forgery
• Using Components with Known Vulnerabilities
• Unvalidated Redirects and Forwards
XSRF
XSRF Review
1. Alice logs into https://mybank.com, and gets back a session cookie:200 OKSet-Cookie: session-id=123-456789; path=/; domain=.mybank.com; Secure; HttpOnly;
2. Alice is tricked into opening https://evilsite.com, whose JavaScript code sends a POST to mybank.com: POST /transfer_fundsCookie: session-id=123-456789...destination=evil_account_number&amount=100000¤cy=USD
1. https://mybank.com sends back another cookie with an “xsrf token”:200 OKSet-Cookie: session-id=123-456789; path=/; domain=.mybank.com; Secure; HttpOnly;Set-Cookie: _xsrf=SOMESECRETVALUE; path=/; domain=.mybank.com; Secure; HttpOnly;
2. On any page with a form, https://mybank.com includes the same token in an input field to be POST-ed: … <input type='hidden' name='_xsrf' value='SOMESECRETVALUE'> …
XSRF Tokens
3. https://mybank.com rejects any POST that without an XSRF token, or in which the token doesn’t match the Cookie
XSRF Tokens
XSRF Tokens
Elegant solution:
• Requires no new server-side state
• Can be added to most existing web applications with minor modifications
• “Secure by default”
2004: • Unvalidated Input
• Broken Access Control
• Broken Authentication and Session Management
• Cross Site Scripting
• Buffer Overflow
• Injection
• Improper Error Handling
• Insecure Storage
• Application Denial of Service
• Insecure Configuration Management
2013: • Injection
• Broken Authentication and Session Management
• Cross Site Scripting
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Function Level Access Control
• Cross-Site Request Forgery
• Using Components with Known Vulnerabilities
• Unvalidated Redirects and Forwards
XSS
XSS - Review
{% autoescape None %} !<html> <body> <h1>Your Notes</h1> {% for row in rows %} <hr> <p> {{ row.content }} </p> {% end %} </body> </html>
Threats
• Annoy users (i.e. <script>alert(‘hi’)</script>)
• Steal any data in the DOM
• (Including XSRF tokens!)
• Phish users’ credentials, even if it wasn’t a login page!
XSS - Review
XSS - Escape All The Things
{% autoescape None %} !<html> <body> <h1>Your Notes</h1> {% for row in rows %} <hr> <p> {{ escape(row.content) }} </p> {% end %} </body> </html>
XSS - Autoescape
• Actually, Tornado does auto-escape by default (I had to disable it!)
• But, naive auto-escaping is not good enough!
Different Contexts
{% autoescape None %} !<html> <head> <title>Hello, World</title> <script> var qux = {{ json_encode(qux) }}; </script> </head> <body> <input type="hidden" name="foo" value="{{ escape_attr(foo) }}" /> <a href="/{{ url_escape(bar) }}">{{ escape(baz) }}</a> </body> </head>
Context-Aware Auto-Escaping
Basic idea: as you’re generating template output, feed it back through an HTML parser. When you hit a template directive, figure out what context you’re in, and call the appropriate escaping function!
Mitigation: Content-Security-Policy (CSP)
HTTP Header that will tell the browser from what sources it’s allowed to load (and in the case of scripts, execute) content.
• Content-Security-Policy: default-src ‘self' - load scripts/images/etc. only from the same domain (and do not run inline scripts or process inline CSS!)
• Content-Security-Policy: default-src 'self'; img-src * - same, except allow loading images from any host
For more, see: http://cspisawesome.com
Mitigation: Content-Security-Policy (CSP)
• Turns security vulnerabilities back into “ordinary bugs”…
• (… if your users are using supported browsers!)
• Eliminating inline scripts usually requires some restructuring
• but separating code, data, and presentation is a good pattern anyway, right? :)
2004: • Unvalidated Input
• Broken Access Control
• Broken Authentication and Session Management
• Cross Site Scripting
• Buffer Overflow
• Injection
• Improper Error Handling
• Insecure Storage
• Application Denial of Service
• Insecure Configuration Management
2013: • Injection
• Broken Authentication and Session Management
• Cross Site Scripting
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Function Level Access Control
• Cross-Site Request Forgery
• Using Components with Known Vulnerabilities
• Unvalidated Redirects and Forwards
SQL Injection
SQL Injection - Review
class LoginHandler(tornado.web.RequestHandler): def post(self): user = self.get_argument('username') password = self.get_argument('password') ! pwhash = hashlib.sha1(password).hexdigest(); row = self.application.db.get( 'SELECT uid FROM users WHERE uname=\'%s\' AND password=\'%s\'' % (user, pwhash)) if row: self.set_secure_cookie('user', str(row.uid)) self.redirect('/')
SQL Injection - Review
class LoginHandler(tornado.web.RequestHandler): def post(self): user = self.get_argument('username') password = self.get_argument('password') ! pwhash = hashlib.sha1(password).hexdigest(); row = self.application.db.get( 'SELECT uid FROM users WHERE uname=\'%s\' AND password=\'%s\'' % (user, pwhash)) if row: self.set_secure_cookie('user', str(row.uid)) self.redirect('/') !!
(By the way, DO NOT store your passwords like this!)
Fun things to submit for ‘user’:
• akgood' OR '1' = '1
• akgood'; DROP TABLE users; SELECT …
• or just point a tool like sqlmap (http://sqlmap.org/) at it!
SQL Injection - Review
Parameterized Queries
class LoginHandler(tornado.web.RequestHandler): def post(self): user = self.get_argument('username') password = self.get_argument('password') ! pwhash = hashlib.sha1(password).hexdigest(); row = self.application.db.get( 'SELECT uid FROM users WHERE uname=%s AND password=%s', user, pwhash) if row: self.set_secure_cookie('user', str(row.uid)) self.redirect('/') !!
Can you see the difference?!
ORM
class LoginHandler(tornado.web.RequestHandler): def post(self): username = self.get_argument('username') password = self.get_argument('password') ! pwhash = hashlib.sha1(password).hexdigest(); rows = self.application.session.query( User).filter_by(uname=username, password=pwhash) if rows: row = rows[0] self.set_secure_cookie('user', str(row.uid)) self.redirect('/')
ORM Magic
from sqlalchemy.ext.declarative import declarative_base from sqlalchemy import Column, Integer, String !Base = declarative_base() class User(Base): __tablename__ = 'users' ! uid = Column(Integer, primary_key=True) uname = Column(String) password = Column(String)
Middle Ground: SQL Expression API
class LoginHandler(tornado.web.RequestHandler): def post(self): username = self.get_argument('username') password = self.get_argument('password') ! pwhash = hashlib.sha1(password).hexdigest(); s = select([users]).where( (users.c.uname == username) & (users.c.password == pwhash)) rows = self.application.conn.execute(s) if rows: row = rows[0] self.set_secure_cookie('user', str(row['uid'])) self.redirect(‘/') !… !users = Table('users', meta, autoload=True, autoload_with=engine)
Static Analysis
If you really must write raw SQL:
• basic: a check to ensure that developers never use the string interpolation operator (‘%’) in a database function call
• better: dataflow analysis to trace the construction of a query string and ensure no untrusted inputs were used (a.k.a. ‘taint analysis’)
Static Analysis: Commercial Solutions
Powerful, but extremely expensive - e.g.:
• Veracode
• Coverity
• Fortify
Static Analysis: Homegrown Hacks
Example: make sure that we only ever use Python’s “SystemRandom” class to generate random valuesv1: basically, grep for instances of:
• ‘random\.\w+’ (other than ‘random.SystemRandom)
• ‘from random import .*’(other than ‘from random import SystemRandom)
v2: use the python AST
Abstract Syntax Tree
>>> import ast >>> m = ast.parse("from random import SystemRandom") >>> ast.dump(m) "Module(body=[ImportFrom(module='random', names=[alias(name='SystemRandom', asname=None)], level=0)])" >>> m.body[0].module ‘random' !>>> m2 = ast.parse("self.db.execute('SELECT * FROM users WHERE uname=%s' % (uname))") >>> ast.dump(m2) "Module(body=[Expr(value=Call(func=Attribute(value=Attribute(value=Name(id='self', ctx=Load()), attr='db', ctx=Load()), attr='execute', ctx=Load()), args=[BinOp(left=Str(s='SELECT * FROM users WHERE uname=%s'), op=Mod(), right=Name(id='uname', ctx=Load()))], keywords=[], starargs=None, kwargs=None))])"
Checking SystemRandom with the AST
class RandomVisitor(ast.NodeVisitor): def visit_Attribute(self, node): if (isinstance(node.value, ast.Name) and node.value.id == 'random' and node.attr != 'SystemRandom'): raise BadRandomGenerator(node.lineno) ! def visit_ImportFrom(self, node): if (node.module == 'random' and any(alias.name != 'SystemRandom' for alias in node.names)): raise BadRandomGenerator(node.lineno) !with open(some_python_module, 'r') as fp: m = ast.parse(fp.read()) RandomVisitor().visit(m)
• Use frameworks and tools that prevent entire classes of bugs by default - either by intentionally mitigating vulnerabilities or simply by encapsulating dangerous code so you don’t have to deal with it.
• If you see an anti-pattern, write a script to enforce it!
• Can be quite basic, especially if you pair it with peer code reviews and consistent coding norms
• Don’t forget about the rest of the SDL
Conclusions
Top Related