Advances in Web Application and Browser Security: A Few Cool Features

Ben Toews (Head of Application Security at GitHub) and I have been doing a round of talks discussing the state of the union in web application and browser security.  There is a whole slew of new technology and standards coming out that actually really do make the web more secure.  I wanted to take a second and dive into a few of the proposed and accepted standards that are helping make things better:

Forcing browsers to use SSL

Companies like Google, Facebook, and Twitter are using a technology called HTTP Strict Transport Security (HSTS) to force browsers over SSL. For example, when a user types www.google.com into a browser, the request automatically goes over SSL, making the browsing user experience more secure at the transport layer and helping to mitigate man-in-the-middle attacks.  This is an awesome technology that is very easy to implement.  Simply add the following header on the web server:

Strict-Transport-Security: max-age=600000000

This forces the browser to only access content via SSL.

Mitigating cross-site scripting

Companies like Facebook and Github are using Content-Security Policy (CSP), which severely cripples cross-site scripting (XSS). By blocking JavaScript features such as inline scripts and dynamic evals, attackers will have a much harder time performing XSS attacks. In addition, forcing developers to avoid inline scripts will encourage better coding practices. Facebook has started to send CSP headers on certain requests, but they seem to be very permissive, potentially suggesting they are still testing this technology.

I’m working with Patrick Thomas on collecting a bunch of information on Content-Security Policy and we will be presenting some metrics and tools on the technology at a Chicago Security Meetup in July.  More details to follow!

Rendering browser content only as explicitly stated

Facebook, Live.com, and Gmail utilize X-Content-Type-Options: nosniff, which finally fixes an age-old problem where content type is ‘sniffed’ by the browser and rendered even when it conflicts with the explicitly stated Content-Type. For example, when a document’s content type is specified as a plain text document but contains HTML, the browser may (depending on the specific browser) ‘sniff’ the content and decide to actually render it as HTML. Think about an attack where you have a file upload that only allows text documents. You upload a text document containing HTML and JavaScript, and when a user goes to retrieve that text document the browser ‘sniffs’ the document and renders that content, executing your script in the user’s browser. The nosniff header instructs the browser not to perform any content sniffing, forcing the browser to render content only as explicitly stated.

Preventing clickjacking attacks

Clickjacking attacks take advantage of embedded content in iframes by placing elements over those frames and tricking users into clicking actions that seem innocuous, but may be performing malicious actions on the attacker’s behalf. Companies like Google, Facebook, Twitter, Paypal, Ebay, and Live.com are using the X-Frame-Options HTTP response header, which either permits or denies the rendering of a page in a frame or iframe element. Since this can block content from being embedded into other sites, it can prevent clickjacking attacks.

This is just a subset of the technologies Ben and I will be covering at our talk at http://shakacon.org/.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s