03 Aug Opener – The underestimated vulnerability
The opener vulnerability is based on a lack of hardening of externals links. The following code shows a basic sample of an external vulnerable link.
Capture 1 – Basic external link
An external link can be easily recognized by the attribute . When a link has this attribute, he will open in a new tab.
The “document.referrer” gives the url from where the user comes.
And the “opener.location.href” gives an access to the parent tab.
The child tab can use the opener property to redirect the tab to a new location.
An attacker can redirect the parent tab to a custom page which requires authentication.
For the use case the website vuln-opener.nes-lab.intra was made vulnerable to the opener vulnerability:
Capture 2 – Basic external link with the security Same Origin Policy (SOP)
The evil domain h4ck3r-fr0m-sp4c3.intra contains the following code:
Capture 3 – Evil code
- The link doesn’t have the property “noopener”, so in the child tab the object “opener” is not empty
- The child tab redirects the parent tab to a custom page (document.referrer contains the url of the parent tab).
- The child tab shows a custom message :
Capture 4 – Malicious redirect
The parent tab is now owned by the hacker:
Capture 5 – Page owned by the hacker
An attacker can use this vulnerability to steal users’ credentials by making a fake authentication page.
The vulnerability can be spotted by the user if they take care of the url.
In order to fix this vulnerability, all links with the property need to have this property:
Chrome blocks the opener object if the property “rel” contains “noopener” or “noreferrer”. But we advise you to put both keywords.
Capture 6 – Secure external link
Capture 7 – Secure external link
If you are vulnerable and you cannot patch all links, you can use the following code:
Capture 8 – Patch all links dynamically
Written by Guillaume NUEL