XSS via window.opener
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
High
|
Unassigned | ||
3.1 |
Fix Released
|
High
|
Unassigned | ||
3.2 |
Fix Released
|
High
|
Unassigned | ||
3.4 |
Fix Released
|
High
|
Unassigned |
Bug Description
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:/
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.
Changed in evergreen: | |
importance: | Undecided → High |
milestone: | none → 3.3.1 |
Changed in evergreen: | |
assignee: | nobody → Jason Stephenson (jstephenson) |
Changed in evergreen: | |
assignee: | Jason Stephenson (jstephenson) → nobody |
tags: | added: signedoff |
Changed in evergreen: | |
milestone: | 3.3.1 → 3.3.2 |
Changed in evergreen: | |
assignee: | nobody → Jane Sandberg (sandbej) |
Changed in evergreen: | |
milestone: | 3.3.2 → 3.3.3 |
Changed in evergreen: | |
milestone: | 3.3.3 → 3.3.4 |
Changed in evergreen: | |
status: | New → Confirmed |
Changed in evergreen: | |
status: | Confirmed → Fix Released |
status: | Fix Released → Confirmed |
information type: | Private Security → Public Security |
Changed in evergreen: | |
status: | Confirmed → Fix Committed |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
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)... /developer. mozilla. org/en- US/docs/ Web/Security/ Same-origin_ policy
https:/
Hope this helps a bit,
Yamil