Preventing web browsers from doing what attackers tell them to
Kurt explains how using security headers can provide extra protection from malicious content and web attacks.
If you remember when web apps were simple and hosted on a single site, you are by definition old; however, you probably also know that when apps are networked, the whole is greater than the sum of its parts.
For example, suppose you have two separate web apps, such as your retirement fund web site and a mortgage calculation web site, that are useful apps on their own. However, if you link these apps together, allowing users to specify their income and how much they currently pay for rent/mortgage and then calculate what kind of mortgage they can afford, then the whole thing is much more useful because they can figure out whether it's better to put money into their retirement fund or their mortgage payments and test various financial scenarios. You could also tie these into additional applications and sites, like your mutual funds, your tax calculations, and so on for even more functionality.
Of course, all this functionality comes at a cost: complexity. And, this added complexity gives attackers more avenues of approach. For example, an attacker could embed a copy of your bank's website using an
Strict-Transport-Security is one of the simplest and most effective of the new security headers. HTTP Strict Transport Security (HSTS) allows you to specify that a domain (and optional subdomains) should only be served over HTTPS instead of HTTP. The idea is that when a user accesses your website from a safe location the first time (e.g., they register from home), you send them an HSTS header saying "user HTTPS for at least the next year." Then, when the user accesses your site from a coffee shop, for example, their browser only allows access to it via HTTPS, preventing man-in-the-middle attacks. In Apache, you can add the following header to serve HSTS headers for this site and all subdomains that are valid for 180 days:
Header set Strict-Transport-Security "max-age=15552000; includeSubDomains"
HSTS headers should only be served over HTTPS; so, to get people from your HTTP site to your HTTPS site, I recommend using a redirect. Alternatively, you can get whitelisted in some browsers (well, in Google Chrome ), which is ideal because then clients will always be protected.
To prevent framing by hostile sites, you can specify which sites are allowed to put your content within an
iframe. The problem is that this action is handled on the client side, and not all browsers support
X-Frame-Options or all the capabilities they provide .
X-Frame-Options has three settings:
Deny, which means no framing is allowed at all;
Allow-From, which lets you list specific sites and URLs that can embed the page in an
SAMEORIGIN, which allows anything from the same origin (basically the same domain) to embed it within an
Deny for any content that should never be embedded and use
Allow-From specifically to allow resources to be embedded as needed.
With the modern tendency to combine web applications across multiple domains and organizations, you need to allow a web page on site A to trigger a request to site B (e.g., for an image or form). Traditionally, this behavior has led to a lot of security problems. For example, attackers can get users to visit a hostile site or load hostile content (e.g., by serving it over an ad network) and then trigger their web browser to load elements from another site, such as their bank, or their email service. Here, however, you run into a chicken-and-egg problem.
If you visit site A, and it tells you to load a resource from site B, how does your web browser know whether this action is allowed? Even if site B has a security policy with data served via HTTP headers that will let you know whether your browser is allowed to make the request, how do you know whether you are supposed to do so? The solution is that your web browser makes a "preflight" request, using the
OPTIONS request method (as opposed to
TRACE, and so on) for the resource, at which time site B's security policy is served via HTTP headers. Your web browser then processes these headers and decides whether or not it is allowed to make the request.
A large number of
Access-Control-* headers  are available that you can send (Table 1). Basically, you can control which URLs are allowed to make requests, how the request can be made, whether the client can send credentials when making the request, which headers the client can use, and more.
Various Access-Control-* Options
URI that may access this resource (e.g.,
Headers the browser is allowed to access
How long it can be cached by the browser
Whether or not credentials can be used in the request
Methods allowed to be used by the browser (e.g., GET, POST, etc.)
Which headers can be used when making the request
Read full article as PDF:
The Raspberry Pi Foundation has announced an even smaller version of the tiny computer that will fit into a DIMM slot.
A new class of problems lets a malicious app pre-configure an invisible privilege update.
New Hack language adds static typing and other conveniences.
New crypto policy system will offer easier configuration and more uniform security.
Ubuntu founder denounces insecurity in proprietary, close-source software blobs.
Vulnerability affects many Linux web servers
The Bavarian capital shuns Microsoft, Google, and other alternatives to implement an open source groupware solution.
Phone vendor partnerships bring Mark Shuttleworth's dream of Ubuntu on a phone a step closer to reality.
Donors will get to vote on new features for the free video editor.
Debian project puts init out to pasture and says no to Ubuntu's Upstart.