Making Web Development "Secure By Default"

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





• Buffer Overflow

• Injection





2013: • Injection



• 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





• Buffer Overflow

• Injection





2013: • Injection










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?





• Buffer Overflow

• Injection





2013: • Injection










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&currency=USD

https://mybank.com

http://mybank.com

https://evilsite.com

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

https://mybank.com

http://mybank.com

http://mybank.com

https://mybank.com

3. https://mybank.com rejects any POST that without an XSRF token, or in which the token doesn’t match the Cookie

XSRF Tokens

https://mybank.com

XSRF Tokens

Elegant solution:

• Requires no new server-side state

• Can be added to most existing web applications with minor modifications

• “Secure by default”





• Buffer Overflow

• Injection





2013: • Injection










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

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? :)





• Buffer Overflow

• Injection





2013: • Injection










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('/')


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!


http://sqlmap.org/

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

Thanks!

[email protected]

@akgood

mailto:[email protected]

Date post:	06-May-2015
Category:	Technology
Upload:	duo-security
View:	407 times
Download:	1 times

Making Web Development "Secure By Default"

Technology