Copyright Justin C. Klein Keane Web Application Security A Sisyphean Task

Copyright Justin C. Klein Keane <[email protected]>

Web Application Security

A Sisyphean Task


Who Am I?

Homepage: www.MadIrish.net Security research Work for University of Pennsylvania Over a decade of work in this space A couple dozen CVE's to my name A couple of degrees that prove I'm good at

school

http://www.MadIrish.net/


About Web Applications

A long time ago, in a galaxy far, far away...


Original Intentions

HTTP was designed to allow academics and researchers remote access to documents

Client server model Revolutionary because papers could include

references that could be used to directly access references

Documents were static Trust was implied



Oh the Place You'll Go

State (cookies) URL based distinct

services Dynamic scripting

languages Databases Mobile Encryption

AJAX Multimedia Proxies Browser Plugins Coming soon:

Web sockets Local storage And more...


Life of a web request

Starts with a client Typical desktop Or maybe a laptop Or maybe a tablet Or maybe a smartphone Or maybe a multimedia device Or your toaster...


What is a Client

Really we mean a web browser Like:

Chrome Internet Explorer Firefox Safari Opera Web Kit based something Who knows what else...


Browsers are Complex

Support multiple protocols Display various different content Remember your history, form fields, passwords Block evil badness Apply custom formatting rules Automatically update And so on...


Back to Square 1

Ok, so we have this massively complex browser Made more complex by plug-ins

Hosted on a massively complex OS Begins a request with:

URL


Stop and Ask for Directions

URL is really just the start Client immediately performs a DNS lookup Resolves the destination Next client packages up an HTTP request

Fairly simple, just a header and a body:

GET http://somedomain.tld HTTP/1.1


Wait a minute

Actually it's not that simple Unless RFC 2616 and 4229 are simple...

Remember that state thing? Client looks in the local cookie store Finds all cookies associated with the domain

and path Adds them to the header May also pass along other parameters (referer,

user-agent, and so on)


Hits Away

Ok, so after all of that: The client sends the initial request Traverses across the network Arrives at the server


Life on the server

Server actively listening for requests Actually the “server” is a web server Lives on top of an operating system just like the

client Comes in many shapes and sizes:

Apache, IIS, Jboss, Tomcat, Nginx, Zope, and on and on and on


Server, still...

Server gets this HTTP request Looks at the URI Breaks the URL into two parts, split by the '?'

delimiter Stuff in front is the resource Stuff in back are variables


Searching for the File

URL no longer refers to a “document” Server looks at the document part, parses it

and figures out a handler In most cases this refers to a piece of code that

needs to be compiled. Server finds the code, compiles it, and returns

the resulting HTML


Not So Fast

Actually, the server finds the file, then looks for any includes or hooks to other systems

Once these are all aggregated the server compiles the code and returns the HTML to the client


Whoa, whoa, whoa

Actually, what likely happens is: The script compiles In the process it examines user supplied data

like GET, POST and COOKIE variables. Queries a database Perhaps interacts with the file system Potentially invokes other programs Then builds an HTML response


HTTP Response

Like the request, includes headers and body Headers are again, complex

Can include new cookies, redirects, and all sorts of other directives

Body contains a mass

of HTML code


Client Gets the Response

Response passes to the browser Browser looks through the response

Identifies any remote resources, repeats the process with those

Once all resources are marshaled browser attempts to render display


Not So Fast (again)

Display is actually just one component Browser also sets up event handlers Dynamically evaluates any JavaScript Responds to inputs and fetches new resources silently

via AJAX Potentially loads up third party plug-ins and passes code to them Stores any local data necessary On and on...


Reasons it All Goes Sideways

All of this complexity happens using a single encoding

Boundaries between data and instructions are easily confused

Once any component (server or client) parses incorrectly bad things ensue

Easy to trick either side (client/server) into using data for display as instructions


Other Causes for Concern

Each piece in this puzzle is massively complex Security specialists can spend their careers

focusing on just one piece (the browser, the server, the database, the DNS'es, etc...)

Complexity is the enemy of security Complexity means automated analysis and

vulnerability discovery is extremely poor Check out Rice's Theorem


What's More

Everything keeps on changing all the time New browsers come out New features are added to HTML New applications make new use of the

protocols People want new features, not new security


Security Measures Suck

Tools for users like SSL are complex The certificate warning The green lock icon

Tools for developer fail too Safe libraries may exist, but using them

properly is difficult Server security measures often lead to

developer headaches Try disabling JavaScript in your phone


Also Consider:

Web apps are globally available 24/7 Barrier for entry to malicious attackers is

basically zero As browsers become more powerful they

become the application platform of choice Mobile means the app is the target, not the

machine Skidiot tools are getting better every day


Not to mention

Web application logic flaws and vulnerabilities


Life on an insecure product

Some has an idea for the next big thing They manage to wrangle up budget/staff to

create this thing On a limited budget/time they have to bring a

product to market Developers focus on meeting functional

specifications Product works (but is full of security holes)


Other Causes for Concern

Application development is extremely complex Application security is also extremely complex AppSec concerns are beyond most developers

Security flaws can be obscure, and developers might see them once in a lifetime...

Developers can't reasonably be expected to be security experts

Therefore if you don't have AppSec people, guess what...


What To Do

Invest in a mature application security program OK, this is expensive

Outsource! Choose a framework and leverage other

people's work Use established technologies Keep track of your apps (and owners!) Have security reviews on a schedule


Or..

Do what I do and break stuff!


Questions?