<div dir="ltr"><div>tahoe-lafs actually had a feature like this originally and such a feature, by design, has a security vulnerability separate from cross-site scripting:<br></div><div><br></div>It goes by the conventional misnomer: cross-site reference forgery (CSRF).<div>
<div><br></div><div style>Suppose accessing the url "http://localhost:3456:/aliases/myalias" was equivalent to "<a href="http://localhost:3456/uri/.">http://localhost:3456/uri/.</a>.. 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.</div>
<div style><br></div><div style>I can, for example, make an html file on "<a href="http://nejucomos.evil.site.example.com/really/awesome/content.html">http://nejucomos.evil.site.example.com/really/awesome/content.html</a>" 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.</div>
<div style><br></div><div style>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?</div>
<div style><br></div><div style>There are a few things to notice about this security problem:</div><div style><br></div><div style>It doesn't require javascript.</div><div style><br></div><div style>It is distinct from cross site scripting. (More on that below.)</div>
<div style><br></div><div style>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*!)</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style><br></div><div style>Regards,</div><div style>Nathan</div><div style><br></div><div style>ps: related tickets:</div><div style><br></div><div style><a href="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">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</a><br>
</div><div style><br></div><div style>-especially this old one that pointed out this vulnerability in an old version of the web interface:</div><div style><br></div><div style><a href="https://tahoe-lafs.org/trac/tahoe-lafs/ticket/98">https://tahoe-lafs.org/trac/tahoe-lafs/ticket/98</a><br>
</div><div style><br></div><div style><br></div><div style>ps: A rant on these misnomers</div><div style><br></div><div style>"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.</div>
<div style><br></div><div style>"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*.</div>
<div style><br></div><div style>A real example of this was the Samy worm [1] on myspace, which involved no other websites (I believe):</div><div style><br></div><div style><a href="https://en.wikipedia.org/wiki/Samy_%28computer_worm%29">https://en.wikipedia.org/wiki/Samy_%28computer_worm%29</a><br>
</div><div style><br></div><div style>Also, an entertaining timeline from the perspective of the creator:</div><div style><br></div><div style><a href="http://blogoscoped.com/archive/2005-10-14-n81.html">http://blogoscoped.com/archive/2005-10-14-n81.html</a><br>
</div><div style><br></div><div style><br></div><div style><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 9:32 AM, Greg Troxel <span dir="ltr"><<a href="mailto:gdt@ir.bbn.com" target="_blank">gdt@ir.bbn.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I understand better where you are coming from now.<br>
<br>
So as is pretty clear, tahoe has a unapologetic security-first<br>
mentality.<br>
<br>
On the continuum, there are multiple things:<br>
<br>
dropbox: provider can read, less than 100% clear policies<br>
<br>
owncloud on a VPS: VPS provider could read, probably clearly may not<br>
<br>
owncloud in your facility: reliability issues<br>
<br>
tahoe, with red nodes (with keys) only in your own control<br>
<br>
tahoe, with red nodes in VPS, or ?<br>
<br>
So it really depends on your requirements and what you want. tahoe's<br>
strengths are<br>
<br>
surviving loss of servers<br>
<br>
hiding content from servers<br>
<br>
being able to use storage at nodes that are not "servers" in terms of<br>
cloud politics and service agreements<br>
<br>
So if you want the replicated/distributed part of tahoe but do not<br>
really need the security part, then accessing it from untrusted nodes<br>
could make sense. But then you'd need to ask yourself if that's really<br>
the right tool, given the other things out there. For your travel<br>
example, why not use one of the centralized services, or just a web<br>
server? As soon as you need a particular gateway you have a single<br>
point of failure again anyway.<br>
<br>
owncloud with tahoe backend makes sense because you can have a small VPS<br>
with access to vast storage, trading BW for capacity, which is usually<br>
cheaper in modern vps/cloud offerings.<br>
<br>
So I think it would be fine to have optional features to have redder<br>
gatewys; my only strong opinion is that they be off by default.<br>
<br>
When I talk about red and black, I mean by red that the node has the<br>
private data or the keys, while black nodes only have ciphertext.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</div></div></blockquote></div><br></div>