[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