[tahoe-dev] Tahoe WUI enhancement suggestion

[Callme Whatiwant]

tahoe-lafs actually had a feature like this originally and such a feature,
by design, has a security vulnerability separate from cross-site scripting:

It goes by the conventional misnomer: cross-site reference forgery (CSRF).

Suppose accessing the url "http://localhost:3456:/aliases/myalias" was
equivalent to "http://localhost:3456/uri/... some cap" where "myalias" was
an alias for "some cap".  This has subverted capabilities security!  Now in
order to access the content at "some cap", I no longer need to know the
capability because I can use the alias url.

I can, for example, make an html file on "
http://nejucomos.evil.site.example.com/really/awesome/content.html" that a
victim is tricked into loading.  On that page, there is html which causes a
PUT to the alias URL above.  Now, when a victim views that last link, I
have just overwritten whatever file they had stored under that alias.

Sometimes people counter with details like: "But actually most browsers
don't allow puts to localhost from a non-localhost domain, at least since
2011, except for Safari and the ios browser", but are those really details
you want to depend on for security?

There are a few things to notice about this security problem:

It doesn't require javascript.

It is distinct from cross site scripting.  (More on that below.)

It doesn't require the attacker to actually have their own (dubious
looking) site: These kinds of attacks can often be inserted in forum
comments or tweets or image links.  (For example, the attack could be *in a
file stored inside the user's tahoe grid*!)

Capabilities protect against this kind of attack because the attacker
cannot know a capability without someone telling it to them.  That's the
design goal of capabilities and any violation of this in practice are
security vulnerabilities against LAFS.

It may be possible to create a web interface which prevents this attack and
does not require a "log in" of any sort to the web interface.  An example
is something like: the user sends their browser to "http://.../aliases" and
that page returns a list of links who's names are aliases.  However, I
believe a cross-site attack could abuse whatever feature this was, so the
partial protection doesn't seem to warrant the complexity of this new
feature, IMO.


Regards,
Nathan

ps: related tickets:

https://tahoe-lafs.org/trac/tahoe-lafs/query?description=~csrf&or&description=~xsrf&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&order=priority

-especially this old one that pointed out this vulnerability in an old
version of the web interface:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/98


ps: A rant on these misnomers

"Cross-Site Reference Forgery" is a horrible name.  Consider a traditional
user forum website which has a CSRF vulnerability that allows a malicious
link which makes a GET request to delete a user's account.  Now, an
attacker can post that link *on that site* in one of the user forums.  It's
still obviously an attack, but it does not involve any other site.  Also,
"reference" should be "URL" and "forgery" is also misleading, since URLs
are *designed* to be freely composed from scratch.

"Cross-Site Scripting" (aka XSS) is also a horrible name for some similar
reasons (including that the conventional acronym is not a true acronym).
 Suppose there's a tradition user forum website which has an XSS
vulnerability on the site, but it has no other vulnerabilities such as
CSRF.  Now an attacker can create an attack script *on that site* which
*does anything the user could do* such as making a new post.  So again *no
other site is involved*.

A real example of this was the Samy worm [1] on myspace, which involved no
other websites (I believe):

https://en.wikipedia.org/wiki/Samy_%28computer_worm%29

Also, an entertaining timeline from the perspective of the creator:

http://blogoscoped.com/archive/2005-10-14-n81.html





On Wed, Jun 19, 2013 at 9:32 AM, Greg Troxel <gdt at ir.bbn.com> wrote:

>
> I understand better where you are coming from now.
>
> So as is pretty clear, tahoe has a unapologetic security-first
> mentality.
>
> On the continuum, there are multiple things:
>
>   dropbox: provider can read, less than 100% clear policies
>
>   owncloud on a VPS: VPS provider could read, probably clearly may not
>
>   owncloud in your facility: reliability issues
>
>   tahoe, with red nodes (with keys) only in your own control
>
>   tahoe, with red nodes in VPS, or ?
>
> So it really depends on your requirements and what you want.  tahoe's
> strengths are
>
>   surviving loss of servers
>
>   hiding content from servers
>
>   being able to use storage at nodes that are not "servers" in terms of
>   cloud politics and service agreements
>
> So if you want the replicated/distributed part of tahoe but do not
> really need the security part, then accessing it from untrusted nodes
> could make sense.  But then you'd need to ask yourself if that's really
> the right tool, given the other things out there.  For your travel
> example, why not use one of the centralized services, or just a web
> server?  As soon as you need a particular gateway you have a single
> point of failure again anyway.
>
> owncloud with tahoe backend makes sense because you can have a small VPS
> with access to vast storage, trading BW for capacity, which is usually
> cheaper in modern vps/cloud offerings.
>
> So I think it would be fine to have optional features to have redder
> gatewys; my only strong opinion is that they be off by default.
>
> When I talk about red and black, I mean by red that the node has the
> private data or the keys, while black nodes only have ciphertext.
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130627/b8fa18d2/attachment.html>