Het Bijstere Spoor

Clickjacking allows
an attacker to trick your users into clicking parts of your interface without
their consent. A simple way to describe describe this is, an attacker will embed
your application in their site as an iframe. On top of the iframe they can
show a completely different interface. You're thinking you're clicking buttons
on your own interface, while in fact you are hitting the 'Delete my account'
button in for example GMail.

Because this technique completely operates with frames, it can be
circumvented by using a 'Frame busting' technique. As a bonus, this will also
disallow for example Digg to steal and monetize your content.

Frame busting can be achieved with a simple javascript technique:

Security through javascript?

If you think this sounds like a bad idea, you are probably right. Users might
simply have javascript disabled, and I also don't like relying on UI developers
too much to implement preventive security measures (although I realize in most
cases you do have to).

In Internet Explorer the situation is worse, IE allows you to specify the
non-standard attribute security="restricted":

This attribute tells IE to not allow executing of javascript in the iframe,
which actually is not a bad security measure for other types of attacks. In this
case however, it allows the attacker to disable the framebusting script.

X-Frame-Options

Thankfully, Internet Explorer 8 introduces a new feature that allows the site
owner to disallow frames altogether, which is in my opinion an even better
protection mechanism, because it doesn't rely on javascript to be executed.

The name of the http header is specified as such:

You only have to specify one of these two, 'sameorigin' means the page
can only be framed from an html page hosted on the same domain, deny will
kill framing altogether.

PHP example:

Firefox also appears to
have started implementing this feature, and there's afeature request for
webkit open as well.

Protecting yourself

Unfortunately you can safely assume most sites don't implement either of
these security measures. For firefox users I would therefore strongly recommend
using the NoScript plugin. Not only
does it implement the X-FRAME-OPTIONS for firefox, it also actively detects
clickjacking attempts.

Reference: hackademix.net

Via: Jeremiah Grossman.

A proposal for a Site Security Policy has been proposed by mozilla employee Brandon Sterne. This is an extremely important specification for the web, and could be a big step ahead for security on the web.

<rant>

Over the last decade websites have transformed into feature-rich web applications, with the introduction of Javascript and XMLHTTPRequest, Flash and whatnot. While great for user experience, this has also brought huge security implications, resulting in over 80% of all documented security vulnerabilities in 2007 being carried out using XSS.

While implementing all this new fancy stuff, browser vendors have been slacking thinking about the security implications and essentially the responsibility of safe browsing has been put on the user. (Remember the 90's advice of disabling cookies while browsing?). Browsers have become better over time, but one single XSS hole on any site can still have devastating effects for you and your users.

With the demand for web development and web developers still way higher than the supply, education is in a sorry state too. In job interviews I've conducted it's been rare to find a junior who knows of the concept XSS, and finding one who can explain the implications of CSRF, is, well, I've yet to meet one. I don't claim to be a security expert myself, but I feel everybody who's in the profession of web development, should at least be aware of the basic attack vectors and how to prevent them.

“If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.”

- Weinberg’s Second Law

</rant>

With the Site Security Policy we're given the ability to lock down certain types of behaviours. It allows us to disable javascript included from unknown domains (a whitelist approach), and HTTP requests initiated by external domains, essentially fixing the CSRF problem completely. Additionally, it defines a way for a browser to log attempts to violate the policy.

For the actual implementation details, I'd suggest just reading the spec, even though its still a proposal, it's good reading material.

So whats next?

The spec needs to be finished. While the current policy is distributed through HTTP headers, some people seem to prefer an external file, like how crossdomain.xml or robots.txt is implemented. The latter would have my vote, because the policy can then be easily cached, which can save some bytes in the end. It would also be easier for people to upload a policy file to a server where there's no scripting available and allows the policy to be enforced for a complete domain, instead having to add it to each and every script.

And last but not least, browser vendors would need to implement it. Sterne works at Mozilla, so that's a good sign already. Personally, I can't wait.