Can JavaScript loaded from Tahoe access all your content which is loaded from Tahoe? #615

New issue

Open

opened 2009-02-10 08:24:29 +00:00 by zooko · 19 comments

zooko commented

2009-02-10 08:24:29 +00:00

Several web security experts (who will remain unnamed in this ticket since they have yet to show me a working exploit) have said that if have a page containing JavaScript in one window or tab of a web browser, and you have another page in a different window or tab of that browser, that the web browser will inspect the "origin" of the JavaScript and the "origin" of the other page to decide whether the JavaScript will be allowed to read or change parts of the other page (including its URL).

By "origin", these web security experts tell me, web browsers mean "host and port number" (or possibly they look at only the top two elements of the host domain name). Since all pages that are stored on tahoe and that you are viewing in a web browser are coming from the same host (sometimes localhost or 127.0.0.1) and port number, this means any JavaScript that you view through your tahoe node can access all the URLs of all the other pages you have loaded (or possibly have ever loaded since you launched your browser) from Tahoe. (Furthermore, just to make things worse, these web security experts allege that it might be possible for the JavaScript program to stay running in your browser even after you close that tab or window and continue to access your other tabs or windows which were loaded from the same "origin".)

If true, this is bad. Because those other pages, while they are loaded from the same host and portnumber, could actually be from very different origins. One might be a cute game that you want to play that was passed along from a friend of a friend. Another might be your personal finance database with all of your bank account numbers and billing information. We would like it if the web browser would allow you to play the fun game in one window, and edit your personal finance document in another window, without giving the game the ability to read (and therefore to upload) or change your personal document. Even though both pages were loaded from http://127.0.0.1:4567 or from http://testgrid.allmydata.org:3567 or whatever.

In the long run it might be possible for us to arrange to do this, such as by embedding a unique string, possibly the verifycap or possibly an incrementing string, into the domain name, or by taking advantage of some not-yet-created mechanism to tell web browsers "No, no, these two things are of different origins even though they are loaded from the same host and port.".

In the short run, it might be wise to avoid looking at pages in tahoe if they might have malicious content on them, unless you first turn off JavaScript in your web browser. Hopefully someone will help us understand exactly how dangerous this situation is, by posting a working exploit or some sort of proof that is is safe.

Several web security experts (who will remain unnamed in this ticket since they have yet to show me a working exploit) have said that if have a page containing [JavaScript](wiki/JavaScript) in one window or tab of a web browser, and you have another page in a different window or tab of that browser, that the web browser will inspect the "origin" of the [JavaScript](wiki/JavaScript) and the "origin" of the other page to decide whether the [JavaScript](wiki/JavaScript) will be allowed to read or change parts of the other page (including its URL). By "origin", these web security experts tell me, web browsers mean "host and port number" (or possibly they look at only the top two elements of the host domain name). Since all pages that are stored on tahoe and that you are viewing in a web browser are coming from the same host (sometimes localhost or 127.0.0.1) and port number, this means any [JavaScript](wiki/JavaScript) that you view through your tahoe node can access all the URLs of all the other pages you have loaded (or possibly have ever loaded since you launched your browser) from Tahoe. (Furthermore, just to make things worse, these web security experts allege that it might be possible for the [JavaScript](wiki/JavaScript) program to *stay running* in your browser even after you close that tab or window and continue to access your other tabs or windows which were loaded from the same "origin".) If true, this is bad. Because those other pages, while they are loaded from the same host and portnumber, could actually be from very different *origins*. One might be a cute game that you want to play that was passed along from a friend of a friend. Another might be your personal finance database with all of your bank account numbers and billing information. We would like it if the web browser would allow you to play the fun game in one window, and edit your personal finance document in another window, without giving the game the ability to read (and therefore to upload) or change your personal document. Even though both pages were loaded from <http://127.0.0.1:4567> or from <http://testgrid.allmydata.org:3567> or whatever. In the long run it might be possible for us to arrange to do this, such as by embedding a unique string, possibly the verifycap or possibly an incrementing string, into the domain name, or by taking advantage of some not-yet-created mechanism to tell web browsers "No, no, these two things are of different origins even though they are loaded from the same host and port.". In the short run, it might be wise to avoid looking at pages in tahoe if they might have malicious content on them, unless you first turn off [JavaScript](wiki/JavaScript) in your web browser. Hopefully someone will help us understand exactly how dangerous this situation is, by posting a working exploit or some sort of proof that is is safe.

zooko added the

labels 2009-02-10 08:24:29 +00:00

zooko added this to the undecided milestone 2009-02-10 08:24:29 +00:00

swillden commented

2009-02-10 15:13:29 +00:00

Owner

Replying to zooko:

In the long run it might be possible for us to arrange to do this, such as by embedding a unique string, possibly the verifycap or possibly an incrementing string, into the domain name, or by taking advantage of some not-yet-created mechanism to tell web browsers "No, no, these two things are of different origins even though they are loaded from the same host and port.".

One option is to use loopback addresses other than 127.0.0.1. The entire 127/8 class A is technically reserved for loopback, and so any of the 2^24^-2 (127.0.0.0 and 127.255.255.255 aren't allowed) addresses in that range should be usable to connect to your Tahoe node. The node could issue 304 redirects to automatically shift you from one "host" to another.

Some possible problems with this:

(1) I don't know if all IP implementations around actually honor the "unusual" loopback addresses. Linux does. Windows appears to (at least, 'ping 127.42.94.19' works).

(2) Javascript implementations may know that 127.x.x.x is all the same host and allow cross-address connections.

(3) It's not clear to me how Tahoe should know when to issue redirects.

Another option is to use cookies. A cookie can also be made specific to a host/domain but also to a path. As I understand it (haven't tested), Javascript loaded from path A should not have access to cookies set specific to path B. If Tahoe were to set per-path cookies on first access to a path, then refuse later requests that don't include the right cookie, then Javascript from path B would not be able to successfully load URLs on path A, because it wouldn't have the cookie.

There are numerous downsides to the cookie approach, and the only advantages I see are if it perhaps works around (1) or (2) and the fact that it allows arbitrarily-large authentication strings.

Replying to [zooko](/tahoe-lafs/trac/issues/26559): > In the long run it might be possible for us to arrange to do this, such as by embedding a unique string, possibly the verifycap or possibly an incrementing string, into the domain name, or by taking advantage of some not-yet-created mechanism to tell web browsers "No, no, these two things are of different origins even though they are loaded from the same host and port.". One option is to use loopback addresses other than 127.0.0.1. The entire 127/8 class A is technically reserved for loopback, and so any of the 2^24^-2 (127.0.0.0 and 127.255.255.255 aren't allowed) addresses in that range should be usable to connect to your Tahoe node. The node could issue 304 redirects to automatically shift you from one "host" to another. Some possible problems with this: (1) I don't know if all IP implementations around actually honor the "unusual" loopback addresses. Linux does. Windows appears to (at least, 'ping 127.42.94.19' works). (2) Javascript implementations may know that 127.x.x.x is all the same host and allow cross-address connections. (3) It's not clear to me how Tahoe should know when to issue redirects. Another option is to use cookies. A cookie can also be made specific to a host/domain but also to a path. As I understand it (haven't tested), Javascript loaded from path A should not have access to cookies set specific to path B. If Tahoe were to set per-path cookies on first access to a path, then refuse later requests that don't include the right cookie, then Javascript from path B would not be able to successfully load URLs on path A, because it wouldn't have the cookie. There are numerous downsides to the cookie approach, and the only advantages I see are if it perhaps works around (1) or (2) and the fact that it allows arbitrarily-large authentication strings.

warner added

c/code-frontend-web

and removed

c/unknown

labels 2009-03-08 22:01:29 +00:00

zooko commented

2009-10-28 05:03:51 +00:00

Author

#821 (A script in a file viewed through the WUI can obtain the file's read cap) was a duplicate of this. David-Sarah posted some interesting notes to #821, and if they don't copy those notes to here then please go read them there.

zooko commented

2009-10-28 05:05:45 +00:00

Author

#127 was also an old ticket that, if I understand it correctly, mentioned both this issue and the different issue of "Referer Header cap leakage" (which is an issue deserving of a ticket of its own, but apparently not currently having one).

daira commented

2009-10-28 06:32:32 +00:00

#127 seems to be almost exclusively about Referer header cap leakage, and I've changed its summary to reflect that.

#821 (now reopened) describes a less serious security problem that would still be present even if every page had a distinct origin. Note that the fix suggested for that bug will only work if this one is also fixed, i.e. #821 is dependent on this bug. #127 seems to be almost exclusively about Referer header cap leakage, and I've changed its summary to reflect that.

daira added

p/critical

and removed

p/major

labels 2009-10-28 06:32:32 +00:00

daira commented

2009-10-29 23:09:51 +00:00

Replying to [swillden]comment:1:

Another option is to use cookies. A cookie can also be made specific to a host/domain but also to a path. As I understand it (haven't tested), Javascript loaded from path A should not have access to cookies set specific to path B. If Tahoe were to set per-path cookies on first access to a path, then refuse later requests that don't include the right cookie, then Javascript from path B would not be able to successfully load URLs on path A, because it wouldn't have the cookie.

There are numerous downsides to the cookie approach ...

Yes. The following paper (which is essential reading for this ticket) explains why this can't work from a security point of view:

Beware of Finer-Grained Origins
Collin Jackson and Adam Barth
In Web 2.0 Security and Privacy. (W2SP 2008)
http://crypto.stanford.edu/websec/origins/fgo.pdf
"Cookie Paths. One classic example of a sub-origin privilege is the ability to read cookies with "path" attributes. In order to read such a cookie, the path of the document's URL must extend the path of the cookie. However, the ability to read these cookies leaks to all documents in the origin because a same-origin document can inject script into a document with the appropriate path (even a 404 "not found" document) and read the cookies. This "vulnerability" has been known for a number of years ... This vulnerability was "fixed" by declaring the path attribute to be a convenience feature rather than a security feature."

Replying to [swillden]comment:1: > Another option is to use cookies. A cookie can also be made specific to a host/domain but also to a path. As I understand it (haven't tested), Javascript loaded from path A should not have access to cookies set specific to path B. If Tahoe were to set per-path cookies on first access to a path, then refuse later requests that don't include the right cookie, then Javascript from path B would not be able to successfully load URLs on path A, because it wouldn't have the cookie. > There are numerous downsides to the cookie approach ... Yes. The following paper (which is essential reading for this ticket) explains why this can't work from a security point of view: * Beware of Finer-Grained Origins * Collin Jackson and Adam Barth * In Web 2.0 Security and Privacy. (W2SP 2008) * <http://crypto.stanford.edu/websec/origins/fgo.pdf> * "Cookie Paths. One classic example of a sub-origin privilege is the ability to read cookies with "path" attributes. In order to read such a cookie, the path of the document's URL must extend the path of the cookie. However, the ability to read these cookies leaks to all documents in the origin because a same-origin document can inject script into a document with the appropriate path (even a 404 "not found" document) and read the cookies. This "vulnerability" has been known for a number of years ... This vulnerability was "fixed" by declaring the path attribute to be a convenience feature rather than a security feature."

daira commented

2009-11-01 06:41:25 +00:00

If you like this bug, you may also like #827 (Support forcing download using "Content-Disposition: attachment" in WUI).

If you like this bug, you may also like #827 (*Support forcing download using "Content-Disposition: attachment" in WUI*).

daira commented

2009-11-07 07:56:45 +00:00

I believe I have a solution for this:

For file types that are not viewable in typical browsers, clicking the file link would download it as per #827. This limits the problem to the small number of types where not being able to view them directly in the browser is a significant usability problem (XHTML, images, and text).
Images and text are easy, since they don't contain scripts (provided that we can defeat browser sniffing that might cause it to treat files served as these types as something more dangerous).
The difficult problem is XHTML. For that case, we can serve a page containing a "parent script", and a full-page iframe with src="javascript:child_script". javascript: URLs are (or should be) treated as having a special origin that does not compare equal to any other origin, even one for an identical URL. So now we have two scripts running in different origins that are able to obtain references to each other, which implies that they can communicate using a cross-origin comms technique such as Subspace ( http://www.collinjackson.com/research/papers/fp801-jackson.pdf ). The parent script then loads the actual XHTML of the page using an XMLHttpRequest, and passes it to the child script, which rewrites its own frame with that content. The parent script shuts down the comms channel immediately after passing the content, so that scripts in the loaded page can't use it.

(I originally thought that it would be possible to create a blank iframe using src="about:blank", and have the parent script inject HTML into it directly using part of the technique described in http://softwareas.com/injecting-html-into-an-iframe . However, if that were possible then it would be a browser security bug, because you shouldn't be able to inject content into a frame with a different origin even if you have a direct reference to it. And we don't really want to rely on exploiting browser security bugs ;-)

Anyway, I think this adequately isolates the injected page. Obviously it needs extensive testing in different browsers; we're relying on the fact that, although the injected page can obtain a reference to its parent (which has an origin shared by other WUI pages) using document.top, the same-origin policy shouldn't allow it to arbitrarily interfere with that parent (even though it can communicate with it). So this is not an example of the "sub-origin" approaches that are criticised in the !Jackson/Barth paper.

img tags in the injected page should still work because those aren't subject to the same-origin policy. (It would be a bug if web content could read the pixels of an image, but that wouldn't be a Tahoe-specific bug.) Similarly for nested frames or iframes in the injected page (the contents of these shouldn't be accessible to the injected page because their origins won't compare equal to the unique origin generated for the javascript: URL).

I believe I have a solution for this: * For file types that are not viewable in typical browsers, clicking the file link would download it as per #827. This limits the problem to the small number of types where not being able to view them directly in the browser is a significant usability problem (XHTML, images, and text). * Images and text are easy, since they don't contain scripts (provided that we can defeat browser sniffing that might cause it to treat files served as these types as something more dangerous). * The difficult problem is XHTML. For that case, we can serve a page containing a "parent script", and a full-page iframe with `src="javascript:child_script"`. `javascript:` URLs are (or should be) treated as having a special origin that does not compare equal to any other origin, even one for an identical URL. So now we have two scripts running in different origins that are able to obtain references to each other, which implies that they can communicate using a cross-origin comms technique such as Subspace ( <http://www.collinjackson.com/research/papers/fp801-jackson.pdf> ). The parent script then loads the actual XHTML of the page using an `XMLHttpRequest`, and passes it to the child script, which rewrites its own frame with that content. The parent script shuts down the comms channel immediately after passing the content, so that scripts in the loaded page can't use it. (I originally thought that it would be possible to create a blank iframe using `src="about:blank"`, and have the parent script inject HTML into it directly using part of the technique described in <http://softwareas.com/injecting-html-into-an-iframe> . However, if that were possible then it would be a browser security bug, because you shouldn't be able to inject content into a frame with a different origin even if you have a direct reference to it. And we don't really want to rely on exploiting browser security bugs ;-) Anyway, I **think** this adequately isolates the injected page. Obviously it needs extensive testing in different browsers; we're relying on the fact that, although the injected page can obtain a reference to its parent (which has an origin shared by other WUI pages) using `document.top`, the same-origin policy shouldn't allow it to arbitrarily interfere with that parent (even though it can communicate with it). So this is not an example of the "sub-origin" approaches that are criticised in the !Jackson/Barth paper. `img` tags in the injected page should still work because those aren't subject to the same-origin policy. (It would be a bug if web content could read the pixels of an image, but that wouldn't be a Tahoe-specific bug.) Similarly for nested frames or iframes in the injected page (the contents of these shouldn't be accessible to the injected page because their origins won't compare equal to the unique origin generated for the `javascript:` URL).

daira commented

2009-11-07 07:59:23 +00:00

Last line of the previous comment has been fixed ~~should be "... to the javascript: origin)."~~.

Last line of the previous comment has been fixed ~~should be "... to the `javascript:` origin)."~~.

daira commented

2009-11-07 08:09:56 +00:00

Ooh, this is interesting:

http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html

If url identifies a resource that is its own trust domain (e.g. it identifies an e-mail on an IMAP server or a post on an NNTP server) then return a globally unique identifier specific to the resource identified by url, so that if this algorithm is invoked again for URLs that identify the same resource, the same identifier will be returned.

If url does not use a server-based naming authority, or if parsing url failed, or if url is not an absolute URL, then return a new globally unique identifier.

I don't know whether this is new proposed HTML5 behaviour, or what browsers currently implement. If the latter, then we could try using an IMAP or NNTP server for the WUI -- bizarre, but possibly simpler than my iframe suggestion above, if it works.

Ooh, this is interesting: <http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html> > If url identifies a resource that is its own trust domain (e.g. it identifies an e-mail on an IMAP server or a post on an NNTP server) then return a globally unique identifier specific to the resource identified by url, so that if this algorithm is invoked again for URLs that identify the same resource, the same identifier will be returned. > If url does not use a server-based naming authority, or if parsing url failed, or if url is not an absolute URL, then return a new globally unique identifier. I don't know whether this is new proposed HTML5 behaviour, or what browsers currently implement. If the latter, then we could try using an IMAP or NNTP server for the WUI -- bizarre, but possibly simpler than my iframe suggestion above, if it works.

zooko modified the milestone from undecided to 2.0.0

2010-02-23 03:09:02 +00:00

daira modified the milestone from 2.0.0 to 1.8.0

2010-04-12 19:16:36 +00:00

daira self-assigned this 2010-04-12 19:16:36 +00:00

zooko commented

2010-07-26 04:52:23 +00:00

Author

Wade Simmons tried to figure out how to exploit this and couldn't do it: http://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004787.html

Wade Simmons tried to figure out how to exploit this and couldn't do it: <http://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004787.html>

zooko modified the milestone from 1.8.0 to soon

2010-08-06 01:37:43 +00:00

daira commented

2011-07-30 22:55:07 +00:00

Replying to davidsarah:

Ooh, this is interesting:

http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html

If url identifies a resource that is its own trust domain (e.g. it identifies an e-mail on an IMAP server or a post on an NNTP server) then return a globally unique identifier specific to the resource identified by url, so that if this algorithm is invoked again for URLs that identify the same resource, the same identifier will be returned.

If url does not use a server-based naming authority, or if parsing url failed, or if url is not an absolute URL, then return a new globally unique identifier.

I don't know whether this is new proposed HTML5 behaviour, or what browsers currently implement. If the latter, then we could try using an IMAP or NNTP server for the WUI -- bizarre, but possibly simpler than my iframe suggestion above, if it works.

Doesn't work, because Firefox 5 doesn't support news: or nntp: or imap: internally.

Replying to [davidsarah](/tahoe-lafs/trac/issues/615#issuecomment-370297): > Ooh, this is interesting: > > <http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html> > > > If url identifies a resource that is its own trust domain (e.g. it identifies an e-mail on an IMAP server or a post on an NNTP server) then return a globally unique identifier specific to the resource identified by url, so that if this algorithm is invoked again for URLs that identify the same resource, the same identifier will be returned. > > > If url does not use a server-based naming authority, or if parsing url failed, or if url is not an absolute URL, then return a new globally unique identifier. > > I don't know whether this is new proposed HTML5 behaviour, or what browsers currently implement. If the latter, then we could try using an IMAP or NNTP server for the WUI -- bizarre, but possibly simpler than my iframe suggestion above, if it works. Doesn't work, because Firefox 5 doesn't support `news:` or `nntp:` or `imap:` internally.

daira commented

2011-07-30 23:01:31 +00:00

Essential reading on how different browsers handle unique origins (as needed for comment:370295 and similar fixes to work): http://code.google.com/p/browsersec/wiki/Part2#Origin_inheritance_rules

Essential reading on how different browsers handle unique origins (as needed for [comment:370295](/tahoe-lafs/trac/issues/615#issuecomment-370295) and similar fixes to work): <http://code.google.com/p/browsersec/wiki/Part2#Origin_inheritance_rules>

warner commented

2011-11-29 19:34:34 +00:00

FYI, here's a description of how the browser's window.history JS interface works: http://www.adequatelygood.com/2010/7/Saner-HTML5-History-Management , which relates to the "back-jacking" attack.

FYI, here's a description of how the browser's `window.history` JS interface works: <http://www.adequatelygood.com/2010/7/Saner-HTML5-History-Management> , which relates to the "back-jacking" attack.

zooko commented

2012-03-29 16:09:30 +00:00

Author

If not, another good way to make progress on this ticket would be to start implementing David-Sarah's technique from comment:370295. Maybe the first step on that would be to write a design document specifying exactly what the comment:370295 technique accomplishes? Maybe we should create a new ticket just for the comment:370295 technique and retire this ticket?

All right, what does it take to make progress on this ticket? I have seen a demo exploit that relies on the user following a link from protected content to malicious content -- the "back-jacking" attack. A good way to make progress on this ticket would be to make a system test that exercises the system through a live browser and demonstrates the attack! That would be cool. Anybody game to do that? If not, another good way to make progress on this ticket would be to start implementing David-Sarah's technique from [comment:370295](/tahoe-lafs/trac/issues/615#issuecomment-370295). Maybe the first step on that would be to write a design document specifying exactly what the [comment:370295](/tahoe-lafs/trac/issues/615#issuecomment-370295) technique accomplishes? Maybe we should create a new ticket just for the [comment:370295](/tahoe-lafs/trac/issues/615#issuecomment-370295) technique and retire this ticket?

daira commented

2012-03-29 18:49:14 +00:00

Mozilla and other browsers have been making good progress recently on implementing the HTML5 sandbox spec. That's a better approach than what I suggested in comment:370295, since it's making use of a fully specified browser feature rather than the behaviour of an implementation-dependent corner case. So, as long as we only relied on the specified behaviour, any security holes in it would be browser bugs and would be the vendors' responsibility to fix.

Mozilla and other browsers have been making good progress recently on implementing the HTML5 sandbox spec. That's a better approach than what I suggested in [comment:370295](/tahoe-lafs/trac/issues/615#issuecomment-370295), since it's making use of a fully specified browser feature rather than the behaviour of an implementation-dependent corner case. So, as long as we only relied on the specified behaviour, any security holes in it would be browser bugs and would be the vendors' responsibility to fix.

daira commented

2012-03-31 02:04:32 +00:00

Replying to davidsarah:

Mozilla and other browsers have been making good progress recently on implementing the HTML5 sandbox spec.

The Mozilla ticket is https://bugzilla.mozilla.org/show_bug.cgi?id=341604 .

Replying to [davidsarah](/tahoe-lafs/trac/issues/615#issuecomment-370307): > Mozilla and other browsers have been making good progress recently on implementing the HTML5 sandbox spec. The Mozilla ticket is <https://bugzilla.mozilla.org/show_bug.cgi?id=341604> .

ChosenOne commented

2012-07-05 12:30:08 +00:00

Owner

One could use Content Security Policy (CSP) to disallow any JavaScript except the one that tahoe needs to operate.

This will break WebApps on tahoe, but foil attacks too. Mh.

One could use Content Security Policy (CSP) to disallow any [JavaScript](wiki/JavaScript) except the one that tahoe needs to operate. This will break WebApps on tahoe, but foil attacks too. Mh.

nejucomo commented

2012-11-15 02:50:38 +00:00

While this ticket is about "accessing all your content" such as recovering the caps of victims, an attacker has a bootstrapping problem. Attack scripts must either:

Run in the same origin as the tahoe gateway; or
Violate security guarantees despite the same origin policy.

I've just posted a proof-of-concept attack in #1859 which can inject js into the tahoe grid and then execute it, starting from any domain. Therefore the latter attack approach can be upgraded to the former.

While this ticket is about "accessing all your content" such as recovering the caps of victims, an attacker has a bootstrapping problem. Attack scripts must either: * Run in the same origin as the tahoe gateway; or * Violate security guarantees despite the same origin policy. I've just posted a proof-of-concept attack in #1859 which can inject js into the tahoe grid and then execute it, starting from any domain. Therefore the latter attack approach can be upgraded to the former.

TheJH commented

2015-04-26 23:52:34 +00:00

Owner

I made a PoC that shows one possible way to exploit this. Use a Tahoe-LAFS instance that is connected to the testnet, browse to different URLs in the testnet, then navigate the same tab to this URL:

(@@http://localhost:3456/file/URI%3ACHK%3A6hxsjrbtiyjohpj7i7bn6dqixi%3Ail3humxxej53gg6bpr3l5ecxrqdg6wnd5ceuq33vqtrivvrhlfeq%3A1%3A6%3A1262/@@named=/historysteal.html@@)

Click anywhere on the page. The following attack will happen:

The evil HTML file opens itself in a second tab using "window.open(location.toString(), 'foo')" (requires a click to bypass popup blockers). Then the evil HTML file in the second tab can
access the first tab using "window.opener". The evil second tab does this again and again:

run window.parent.history.go(-1) to let the first tab go one step back in the browsing history
grab the current URL of the first tab using window.parent.location.toString()
send the URL out to the attacker's server

This will work until a page with a different origin is reached.

After the attack has run, you'll see the URLs that you have visited in the same tab before.

This is a copy of the HTML file:
https://var.thejh.net/lafs_historysteal.html.bin

I made a PoC that shows one possible way to exploit this. Use a Tahoe-LAFS instance that is connected to the testnet, browse to different URLs in the testnet, then navigate the same tab to this URL: (@@http://localhost:3456/file/URI%3ACHK%3A6hxsjrbtiyjohpj7i7bn6dqixi%3Ail3humxxej53gg6bpr3l5ecxrqdg6wnd5ceuq33vqtrivvrhlfeq%3A1%3A6%3A1262/@@named=/historysteal.html@@) Click anywhere on the page. The following attack will happen: ------------------------- The evil HTML file opens itself in a second tab using "window.open(location.toString(), 'foo')" (requires a click to bypass popup blockers). Then the evil HTML file in the second tab can access the first tab using "window.opener". The evil second tab does this again and again: - run window.parent.history.go(-1) to let the first tab go one step back in the browsing history - grab the current URL of the first tab using window.parent.location.toString() - send the URL out to the attacker's server This will work until a page with a different origin is reached. ------------------------- After the attack has run, you'll see the URLs that you have visited in the same tab before. This is a copy of the HTML file: <https://var.thejh.net/lafs_historysteal.html.bin>