Three Simple Ways to Improve the Security of Your Web App
Update: here's the next post in this series.
It seems like web app security has entered the public conscious recently, probably as a result of the press covering the activities of groups like Anonymous and incidents like security breaches at several CAs. Here are a couple of quick security tips to improve the security of your web apps. Think of these as low-hanging fruit, not as a substitute for thorough analysis of your app's security. If there's interest in this topic we can do more posts, too - let us know in the comments!
Prologue: SSL
Your app already forces all traffic over SSL, right? If it doesn't, it should. There are CAs that are accepted by all major browsers and will give you a cert for free. It's almost a sure bet that any overhead of SSL is drowned out by time spent in your app code. Forcing traffic to use SSL isn't a panacea (more on that later), but it's a great place to start.
Strict-Transport-Security
Assuming your app forces traffic to use SSL, there's still a chance that a plain-text connection happens: the user might forget to type *https* instead of *http* in their location-bar. For example, let's say Fiesta forces all traffic to use SSL (it does). When a user types "http://fiesta.cc" (or just "fiesta.cc") into their browser bar the Fiesta server responds with a redirect to "https://fiesta.cc". When that initial plain-text request is made, however, the browser includes any existing cookies. That enables attacks like the one that Firesheep made so easy earlier this year. It also opens up the possibility of a man-in-the-middle attack.
Strict-Transport-Security is a header that a site can set to tell browsers that it always wants connections to use SSL. If a server includes the Strict-Transport-Security header, browsers that support it will remember that information. The next time the user visits the site the browser will automatically switch to the SSL version of the site, without making any requests. That means there is no opportunity for cookies and other information to be sent plain-text, or for MITM attacks. Here's an example of how to set this header using Nginx:
add_header Strict-Transport-Security max-age=15768000;
The `max-age` parameter tells the browser for how long to cache the knowledge that this app wants SSL connections only. In this case, we're telling the browser to remember for half a year.
X-Frame-Options
Another type of attack that has gained in prominence in recent years is called Clickjacking. Clickjacking is a technique where an attacker hosts their own site, but includes a frame with content from your app. On top of the frame, they overlay carefully constructed content that tricks the user to click in certain areas (maybe it's a whack-a-mole game (click on the moles as they pop up) or a link "click here to win a VCR"). When the user clicks, the click is actually passed through to the underlying frame where it takes some undesirable action in your application.
The standard approach to fight clickjacking is to include Javascript in your app that causes it not to load when it is embedded in an frame. This is called frame-busting. The problem with frame-busting is that attackers have devised ways to counteract many different types of frame-busting logic. Knowing to include the code and keeping up to date with the state of the art is more than can be expected of most developers. That said, browsers can't just disable framing altogether - much of the web depends on it.
The X-Frame-Options header is a mechanism for app owners to tell modern browsers whether or not their content should be allowed to get framed. Our approach is to never allow framing of Fiesta content. Here's how we set X-Frame-Options with Nginx:
add_header X-Frame-Options DENY;
If there are specific pages that we want to be frameable, we don't set the header for those pages.
X-Content-Security-Policy
This last tip is a bit less trivial than the previous two. The basic idea is that we can limit the damage from XSS attacks by allowing app owners to specify trusted sources of content for a given page. If a site happens to have a vulnerability that allows a XSS attack the attacker won't be able to load arbitrary resources. This is obviously "treating the symptoms and not the cause": the best approach is just to be sure that your site never allows arbitrary content injection. That said, an extra layer of protection is always a good thing.
An X-Content-Security-Policy header tells the browser (as of now I think only Firefox supports this) what sources are allowed for different types of content. The value of the header is a complicated declaration of those sources. Here's an example that allows all content from the host domain, plus scripts and images from Google Analytics:
add_header X-Content-Security-Policy "default-src 'self'; \ script-src 'self' https://ssl.google-analytics.com; \ img-src 'self' https://ssl.google-analytics.com";
CSP also has a reporting mechanism to alert you when any violation occurs. This makes it useful as a warning signal of XSS vulnerabilities, even if only a fraction of your users are on a browser that supports the header. There's also a "Report-Only" mode that will send you reports but not block any content: perfect for testing and getting started with CSP. As I said, this one is a bit more complicated, but also quite powerful. Definitely worth a look.
Going Forward
As I mentioned in the Prologue, the recent attacks on CAs have proven how vulnerable SSL really is: it's really only as secure as the least-secure of all the CAs. Defaulting to SSL isn't enough, at some point we'll need to move away from the current CA system. Public-key pinning is a good first step, and something like network perspectives / Convergence is an interesting path for the future. If you're interested in this stuff I'd highly recommend checking out ImperialViolet and Moxie's Blog for more. They're both interesting and easy reading.
Mike