Context Navigation

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

Reported by:	davidsarah	Owned by:
Priority:	normal	Milestone:	1.13.0
Component:	code-frontend-web	Version:	1.8.2
Keywords:	security ambient wui redressing review-needed	Cc:
Launchpad Bug:

Description (last modified by ChosenOne)

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).

Change History (16)

comment:1 Changed at 2011-07-31T04:36:13Z by 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.

comment:2 Changed at 2012-08-28T18:11:05Z by 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.

comment:3 Changed at 2013-11-30T14:29:16Z by ChosenOne

Description modified (diff)

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 ;-)

comment:4 Changed at 2013-11-30T15:25:19Z by ChosenOne

OK, it seems easy enough to do this for uri/ and file/ resources by patching FileHandler and URIHandler classes in root.py. See this commit on my feature branch

I have yet to figure out how to do this for things like /statistics, /status, etc. It seems undesirable to re-implement this for every subpage in its own file in src/web/. This would mean that every new subresource would have to remember doing this again to ensure that no URL is left behind ;)

Wouldn't it make sense to build a tiny abstraction layer on top of nevow's rend.Page that ensures proper response headers and is to be used in all files? This would still require changes in all files, but these could be less careful, as we just replace rend.Page references.