WUI: ambiently accessible pages should framebust in order to prevent UI redressing attacks

[davidsarah]

If an ambiently accessible WUI page (one that does not require a capability to access, such as the Welcome page) is loaded in a frame or iframe, the loading frame might be able to perform some UI redressing or clickjacking attacks.

For example, the loading frame could entice the user to click the "Create a directory" button, when it should not have the authority to create a directory on that grid.

This is not a very strong attack. In any case, it can be prevented by including some framebusting code on ambiently accessible WUI pages (or all WUI pages).

[davidsarah]

How not to framebust: ​http://seclab.stanford.edu/websec/framebusting/framebust.pdf

The way to do it securely seems to be to send an ​X-Frame-Options: DENY header.

[davidsarah]

According to ​https://developer.mozilla.org/en-US/docs/The_X-FRAME-OPTIONS_response_header , X-Frame-Options is supported by:

• Internet Explorer 8.0
• Firefox 3.6.9 (Gecko 1.9.2.9)
• Opera 10.50
• Safari 4.0
• Chrome 4.1.249.1042

I think there might be some benefit in including the header for all WUI pages, not just ambiently accessible ones. In conjunction with #1797, that would simplify reasoning about some of the attacks we were worried about in the 2012-08-28 conference call.

[ChosenOne]

I am trying to take this, but I have serious problems finding the appropriate code to patch. It looks like a lot of HTTP handling is scattered through all files in src/web/, which makes it particularly hard to add a security header for all HTTP responses :(

It is unclear to me what the childFactory methods in web/root.py do and the nevow guides weren't very helpful. If they are called for each incoming request, I would consider writing a function that takes a context (ctx) and sets the desired headers for the corresponding request (IRequest(ctx) it seems).

Otherwise I would have to patch the request handlers for every HTTP method (i.e. render_FOO). A pointer for this would also be helpful.

If it's not explicitly undesired, I am considering adding other security headers in a follow-up and might therefore do some changes that are not exactly required for the X-Frame-Options patch.

Oh, and on a side-note: I would suggest to set the X-Frame-Options header to SAMEORIGIN and not DENY. This way, HTML files hosted on tahoe can be framed by other files in the grid. I assume that some users might require this. If there is consensus to take DENY, I will happily obey ;-)