controlled access to your WUI

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

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

[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">.

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