Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
About Web Applications
A long time ago, in a galaxy far, far away...
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
Copyright Justin C. Klein Keane <[email protected]>
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...
Copyright Justin C. Klein Keane <[email protected]>
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...
Copyright Justin C. Klein Keane <[email protected]>
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...
Copyright Justin C. Klein Keane <[email protected]>
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...
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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)
Copyright Justin C. Klein Keane <[email protected]>
Hits Away
Ok, so after all of that: The client sends the initial request Traverses across the network Arrives at the server
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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...
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
Not to mention
Web application logic flaws and vulnerabilities
Copyright Justin C. Klein Keane <[email protected]>
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)
Copyright Justin C. Klein Keane <[email protected]>
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...
Copyright Justin C. Klein Keane <[email protected]>
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
Copyright Justin C. Klein Keane <[email protected]>
Questions?