#674 new enhancement

controlled access to your WUI

Reported by: zooko Owned by: nobody
Priority: major Milestone: soon
Component: code-frontend-web Version: 1.3.0
Keywords: wui confidentiality privacy anti-censorship websec Cc:
Launchpad Bug:

Description (last modified by zooko)

Currently the Welcome Page of the WUI is reachable without knowing any secret, for example, this one: http://testgrid.allmydata.org:3567 . (If you configure your WUI to listen for connections only from localhost then that prevents people from connecting to it from other hosts, but it doesn't prevent CSRF attacks in which someone posts a web page to Tahoe, and when you view that page with JavaScript enabled, or click on a button on that page, then it accesses your WUI.)

It would be good to have a page which is access-controlled by use of a secret capability even though it isn't specific to a file or directory. The entire Welcome Page might belong no that Access Controlled Welcome Page, or maybe only the sensitive pieces would go onto the Access Controlled Welcome Page.

As an example (this might or might not be a good idea), the Access Controlled Welcome Page could have a log of the caps of all of your recent uploads/downloads.

Change History (14)

comment:1 Changed at 2009-04-28T04:06:56Z by nejucomo

A nitpick on which threat scenario this prevents:

This prevents CSRF attacks which maliciously embed an easily guessable action-causing request into a context for the victim to consume.

Whether or not Javascript is used is irrelevant. In particular, preventing CSRF attacks will not protect against malicious Javascript which has the wapi as its origin.

It *would* protect against CSRF attacks launched via Javascript, as well as any other CSRF attacks from a _different_ origin.

Additionally, the implementation should consider non-Javascript CSRF attacks from *the same origin*. For example a request format of "http://$HOST:$PORT/$WUI_SECRET/uri/$FILE_READ_CAP" would *not* protect against relative urls from the $HOST:$PORT origin (such as a malicious html page within a Tahoe grid).

For this reason, it seems like file/directory retrieval URLs should not contain the $WUI_SECRET in their URL. Their own cap already provides protection against forgery, and this prevents the relative path, same origin, CSRF.

comment:2 Changed at 2009-04-28T04:15:29Z by nejucomo

I should have provided more details for my last post.

Javascript from the same origin should be able to grab the $WUI_SECRET from its location (and may be able to grab it from another window even in the scheme where the $WUI_SECRET is not present in retrieval URLs).

A same-origin CSRF that exploits the "http://$host/$WUI_SECRET/uri/$FILE_READ_CAP" url might be html containing <img src="http://../../admin?delete_all_shared=true">.

comment:3 Changed at 2009-07-11T11:23:12Z by warner

good point. I suppose that means making the $WUI_SECRET pages come from a completely different origin, by using a separate port number or something. We'd still need $WUI_SECRET, of course.

We'll have to have a rule that says we never emit unescaped external content on any page served below $WUI_SECRET . That means not using this namespace for delivering files or directories, and it also means being careful about escaping node nicknames and log messages and anything else that we might want to serve from that space.

comment:4 Changed at 2009-07-11T11:23:28Z by warner

  • Component changed from unknown to code-frontend-web

comment:5 Changed at 2010-02-11T20:04:18Z by davidsarah

  • Keywords wui confidentiality privacy added

comment:6 Changed at 2010-12-16T01:27:25Z by davidsarah

  • Keywords anti-censorship added

comment:7 Changed at 2011-07-25T22:31:53Z by zooko

  • Description modified (diff)

comment:8 Changed at 2013-09-14T17:39:42Z by zooko

  • Description modified (diff)
  • Keywords websec added

comment:9 Changed at 2013-12-29T02:30:09Z by zooko

#1911 was a new related ticket

comment:10 Changed at 2015-04-12T21:44:28Z by daira

  • Milestone changed from undecided to 1.12.0

comment:11 Changed at 2016-03-22T05:02:25Z by warner

  • Milestone changed from 1.12.0 to 1.13.0

Milestone renamed

comment:12 Changed at 2016-06-28T18:17:14Z by warner

  • Milestone changed from 1.13.0 to 1.14.0

renaming milestone

comment:13 Changed at 2020-06-30T14:45:13Z by exarkun

  • Milestone changed from 1.14.0 to 1.15.0

Moving open issues out of closed milestones.

comment:14 Changed at 2021-03-30T18:40:19Z by meejah

  • Milestone changed from 1.15.0 to soon

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.