XSS vulnerability due to window.opener (target="_blank" and window.open())
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mahara |
Fix Released
|
High
|
Aaron Wells | ||
1.10 |
Fix Released
|
High
|
Unassigned | ||
15.04 |
Fix Released
|
High
|
Unassigned | ||
15.10 |
Fix Released
|
High
|
Unassigned |
Bug Description
The Catalyst security team has pointed out to us that the practice of opening new browser windows via "target" links or the Javascript window.open() command. The problem is that in these cases, the Javascript and HTML standards require that the newly opened window/tab have access to the original window's "Window" object, via "window.opener". This allows the new window to control the navigation of the original window, and possibly access other DOM objects as well, depending on security policies.
The really bad part, though, is that the new window has access to window.opener, and navigation control via it, even if the new window is on a different domain than the original window. And this window.opener object remains there, even if the user goes to a new page or site in the new window, or the old window!
This allows for all kinds of cross-site-
CVE References
Changed in mahara: | |
status: | In Progress → Fix Committed |
status: | Fix Committed → In Progress |
Changed in mahara: | |
status: | In Progress → Fix Committed |
information type: | Private Security → Public Security |
Changed in mahara: | |
status: | Fix Committed → Fix Released |
In Mahara there are three main kinds of links we need to consider, each of which can use a different strategy:
1. User-generated links.
TinyMCE allows users to specify "new window" when creating a link, so this is rather easy to do. We will need to do the following:
1a. Disable the "Target" option in TinyMCE
1b. Add an HTMLPurifier setting to remove "target" attributes in links.
1c. (Maybe) scan the database for links with the "target" attribute, and remove them. This step is probably not necessary, though, because of our use of HTMLPurifier.
1d. Carefully check the code for other sources of user-generated links. For instance, the RSS block, do we run that through HTMLPurifier?
2. Hard-coded links in the Mahara code, directed at external websites.
These are usually "extra information" links on form pages. We want them to open in a new window, so that the user can read them without navigating away from the form. The easiest thing to do here, is to simply remove the target attribute, and rely on our JS functionality that warns you when you're about to navigate away from an incomplete form. When a user sees that, they'll be able to click "cancel" to stay on the page, and then manually open the link in a new window/tab.
3. Hard-coded links in the Mahara code, directed at internal Mahara URLs.
The most obvious example of this is for institution auth configuration. When you're on the institution auth page, and you create or edit the settings for an auth instance, the auth instance config opens in a pop-up window. There may be other places in the admin section where we also do this.
There are two main strategies we might use for these. The simplest, is to simply force the link to open in the same window, and return to that window when the task in the sub-window is complete. This will be functional, but clunky and probably annoying.
The more complicated route, but with a better user interface, would be to open the "pop-up" in an iframe, similar to what we do with block instance configuration. We may be able to use much of the code from the page editor to help with this, but it should be much simpler because it won't need as much flexibility (since it's not dynamically loading up arbitrary blocktypes).
Other ideas:
There is a possible workaround for this issue, which is to use an intermediate redirect page that strips out the window.opener field. So, instead, of creating a direct link to the new window's URL, you create a link to the redirect page. Then you tell the redirect page what URL you want to go to. Then the redirect page and the parent page erase their references to each other, and the redirect page redirects itself to the desired URL. But there are some indications that this approach might not work robustly across all browsers, might be possible to circumvent in some situations, and it may trigger pop-up window protections in some browsers. So it would be more secure to eliminate our use of mandatory pop-up windows altogether.