XSS via window.opener

[Galen Charlton]

Quoting a Koha security bug reported filed yesterday by Chris Cormack:

"If you click on a link that opens a new tab/window to another site, that tab has access to the original window through JavaScript. The browsing context is related, even if the domains are totally different.

The tab retains access to the original window's object via window.opener, even if you navigate to another page or domain, in the new or original window. Access to the Window object means the new window can use Window.location to open a different URL in the original window, perfect for phishing attacks.

Depending on the site's Same-Origin Policy settings, the new window may have access to other parts of the original window's DOM as well.

Every graphical web browser is likely to be affected. Text browser, such as Lynx are probably safe

Any 'A HREF' that contains a target of of '_blank' or '_new' or a fixed name is vulnerable. Previous security best practice often suggested creating a random fixed name for an unpredictable namespace - that won't help with this problem!
Targets of '_self' and '_parent' are safe.

You can check a potentially problematic _blank link in the wild by using WebDev tools to change the link href to https://mathiasbynens.be/demo/opener and seeing what happens to the original tab when you open the link. "

At first glance, most/all of the target="_blank" links in Evergreen go to pages that are fully under Evergreen's control, but it would be a good idea to double-check.

[Yamil (ysuarez)]

Galen, out of curiosity and for documenting what had been done (and how) so far, can you comment on what types of code queries you ran? In case a few of us run the same exact search, and thus all come up with the same results.

My first try would be a very simple, and non exhaustive...

cd Open-Ils/

grep -ir -e _new *
grep -ir -e ['"]_new['"] *
grep -ir -e _blank *
grep -ir -e ['"]_blank['"] *
grep -ir href *
grep -ir href * | grep -ir -e _new *
grep -ir href * | grep -ir -e _blank *

I can volunteer to check more closely than that, but may need additional pointers.

Also, I had previously thought about making 856 tags links open in a new window. I suspect that is something we might want to advice against?

Finally, here is some info on one way, of many, to change for those that are curious (I was)...
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

Hope this helps a bit,
Yamil

[Galen Charlton (gmc)]

Hi,

On Fri, Mar 18, 2016 at 3:18 PM, Yamil <email address hidden> wrote:
> Galen, out of curiosity and for documenting what had been done (and how)
> so far, can you comment on what types of code queries you ran? In case a
> few of us run the same exact search, and thus all come up with the same
> results.

cd Evergreen
git grep target=._|grep -v target=._self

> Also, I had previously thought about making 856 tags links open in a new
> window. I suspect that is something we might want to advice against?

Correct.

> Finally, here is some info on one way, of many, to change for those that are curious (I was)...
> https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

Same origin policy isn't enough -- opening
http://example.com/malicious.html in a new window will still give
malicious code on that page access to window.opener.location and the
ability to point the source window at a different URL.

[Jeff Davis (jdavis-sitka)]

Located URIs in the OPAC and web client now open in a new tab (target="_blank"), per bug 1777954. So this is more of an issue for EG than it used to be.

My understanding is that adding rel="noopener" to the link prevents this attack in Chrome/Chromium, Safari, Opera, and Firefox 52+. For Edge and older browsers, adding noreferrer (rel="noopener noreferrer") would do the trick, but I'm not sure whether we should do that since some vendors still support referring URL authentication.

More info:

https://mathiasbynens.github.io/rel-noopener/
https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/
https://www.owasp.org/index.php/Reverse_Tabnabbing

[Jeff Davis (jdavis-sitka)]

Security branch user/jeffdavis/lp1559239-target-blank-noopener adds rel="noopener" when opening external links in a new tab in the OPAC, per my previous comment.

I have not attempted to address the fairly widespread use of _blank in web client JS. There may be some cases where external links are being opened that way.

[Jason Stephenson (jstephenson)]

The web staff client appears to be immune to this attack from 856 URLs. I was not able to make the opener location change in Chromium or Firefox when opening the link via the web staff client.

The OPAC, on the other hand, is vulnerable. I could change the opener's location in both Firefox and Chromium via some simple JavaScript of my own. I also tested with the demo page from Mathias Bynens and got similar results.

Jeff Davis' patch fixes the latter for me. I've tested it with master in both Chromium and Firefox.

I've pushed a signoff branch to the security repo:

user/dyrcona/lp1559239-target-blank-noopener-signoff

I think we should put this in with the next releases. In the meantime, more testing will not hurt.

[Jane Sandberg (sandbergja)]

Thanks for the fix, Jeff; the testing, Jason; and the clear explanation, Galen. I can confirm that window.opener is already null from the Web client, and that Jeff's commit fixes the issue for the OPAC. I've pushed an additional signoff to the security repo in a branch called user/sandbergja/lp1559239-target-blank-noopener-signoff

[Jeff Davis (jdavis-sitka)]

Here's another signed-off security fix that has missed several releases (compare bug 1822630). If there are no outstanding concerns with the fix, can it be committed? Is there something else that should be done to ensure these fixes make it into the next round of releases?