[tahoe-lafs-trac-stream] [tahoe-lafs] #1455: WUI: ambiently accessible pages should framebust in order to prevent UI redressing attacks
tahoe-lafs
trac at tahoe-lafs.org
Sat Nov 30 14:29:17 UTC 2013
#1455: WUI: ambiently accessible pages should framebust in order to prevent UI
redressing attacks
-----------------------------+---------------------------------------------
Reporter: davidsarah | Owner:
Type: defect | Status: new
Priority: minor | Milestone: undecided
Component: code- | Version: 1.8.2
frontend-web | Keywords: security ambient wui redressing
Resolution: |
Launchpad Bug: |
-----------------------------+---------------------------------------------
Old description:
> 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).
New description:
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).
--
Comment (by 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
;-)
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1455#comment:3>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list