OWASP
tabnabbing
5.3.11 (additional requirement) or 5.6.1 (new section) Verify that links to external pages which specify a target include rel="noopener noreferrer" to prevent tabnabbing. Tabnabbing is an attack in a linked-to page (not under the application's control) which replaces the linked-from tab in the user's browser with a malicious look-alike page. CWE-1022
noreferrer - it is separate topic and it is covered in ASVS.
noopener - Have you checked and verified it is still an actual issue with modern browsers?
Related MDN:
- https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/noopener
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy
I cannot find "noopener" nor "noreferrer" in 4.0.3. Is it in 5.0? Is there a generated doc of 5.0 which I can search?
With "browser supporting" my point is - did you actually put it to work or you just read it from somewhere?
If I remember correctly I tested it and found, that browsers have changed their behavior on the topic, but I'll do the test one more time.
Referrer leakage is separate problem from opener and referrer leakage is covered by:
| # | Description | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 14.4.6 | Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties. | ✓ | ✓ | ✓ | 116 |
Tested just now on chrome Version 111.0.5563.112 64-bit on Windows 10 and found that either noopener or noreferrer defends from tabnabbing. I agree with you that noopener is the logical solution. However I will still advice developers to include rel="noopener noreferrer" in links which specify a target. Perhaps it will help on some obscure browser version!
Here's my test code:
cwe1022test.html:
<html>
<body>
<p>test page</p>
<p><a href="cwe1022attack.html" target="abc">no defense</a></p>
<p><a href="cwe1022attack.html" target="abc" rel="noopener">noopener</a></p>
<p><a href="cwe1022attack.html" target="abc" rel="noreferrer">noreferrer</a></p>
</body>
</html>
cwe1022attack.html:
<html>
<body>
<p>attack page</p>
<script>window.opener.location = "cwe1022fake.html";</script>
</body>
</html>
cwe1022fake.html:
<html>
<body>
<p>fake page</p>
</body>
</html>
I asked
noopener - Have you checked and verified it is still an actual issue with modern browsers?
and ..
If I remember correctly I tested it and found, that browsers have changed their behavior on the topic, but I'll do the test one more time.
So, I did.
From the issue description:
Tabnabbing is an attack in a linked-to page (not under the application's control) which replaces the linked-from tab in the user's browser with a malicious look-alike page.
The (scope)problem with your test:
- problem statement is describing navigation away from an application (cross-origin and cross-site requests)
- test-code is done only in same-origin scope
window.opener object is sent only with same-origin request AND when target attribute is set AND target attribute value is some name (e. g. is not _blank, _self etc). Proof-of-Concept is available here: https://elarlang.eu/opener.html
both values (noopener and noreferrer) for rel attribute disable sending opener.
So, by default with modern browsers we don't have noopener problem for cross-origin requests. See:
- https://mathiasbynens.github.io/rel-noopener/
- https://github.com/whatwg/html/issues/4078
- https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/noopener
- https://chromestatus.com/feature/6140064063029248
You can open cross-origin opener spreading with Cross-Origin-Opener-Policy and the question is, should we have separate requirement for that.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy
@securitydave - if there are no other arguments, I'll close this issue (in the future).
This is great news that compliant browsers may fix this. However, I would still recommend including rel="noopener" on links supplying a non-blank target. Your reference https://mathiasbynens.github.io/rel-noopener/ recommends as such. Now my concern is only whether some still commonly-used browsers may be vulnerable. Your test is convincing for chrome. Thank you.
There is quite a big difference between recommending and requiring. In ASVS we put requirements which everyone need to follow, it means we don't put "it would be nice if you do this". Only "you need to do this". From current information, I would say it's not worth requirement.
For older browsers - an application need to check user's browser and let him/her know if it needs update. Requirement(s) for that are cooking here: https://github.com/OWASP/ASVS/issues/959
Decision to make - should we have level3 requirement to cover opener configuration.
As already stated, I advise including rel="noopener" on links supplying a non-blank target. I think it's a requirement.
So @securitydave is proposing a new requirement:
Verify that links to external pages which specify a target, include rel="noopener" to prevent tabnabbing.
In principle modern browsers should fix this but it could be a problem in older browsers.
As such, @elarlang is proposing that it should be level 3 early based on the lower likelihood of it being an actual problem.
Have I understood everything correctly?
Have I understood everything correctly?
Recap, just in case.
From only rel="noopener" point of view, I would say that we don't need separate requirement. Opener is sent only when
- user is using too old browser (before 2021)
- OR (the request is done in same-origin context AND link has
targetattribute with some name (not_selfor_target).
Old browsers problem is covered with:
V14.5.7 [ADDED] Verify that the web application warns users who are using an old browser which does not support HTTP security features on which the application relies. The list of old browsers must be periodically reviewed and updated.
Other set of conditions - first the likelihood for the problem to happen is close to 0 and second, the attacker need to control resources in the same-origin context where the link points. If those conditions are filled, the opener issue is not your largest problem. Also we should not have many application in the same-origin context (https://github.com/OWASP/ASVS/issues/1299)
Like I wrote here: https://github.com/OWASP/ASVS/issues/1602#issuecomment-1497104029
You can open cross-origin opener spreading with Cross-Origin-Opener-Policy and the question is, should we have separate requirement for that.
If we going to create new requirement, then I think we should set the wider focus and look for COOP and COEP response headers:
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy
- Global browser support 89.55%
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy
- Global browser support 91.61%
2021 is not that long ago, I think we should probably still be recommending something to prevent this. Especially because older browsers might not support COOP/COEP. Can we include both sets of requirements?
Depends on how many more years 5.0 takes :)
but all the arguments were written in my previous comment.
@elarlang do the COOP and COEP response headers definitely prevent the same thing as the rel=noopener attribute. Should this be one requirement or two?
Reading here it felt like it was not exactly the same thing: https://web.dev/why-coop-coep/
2021 is ancient in terms of browser version.
I agree with @elarlang in that If we going to create new requirement, then I think we should set the wider focus and look for COOP and COEP response headers:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy Global browser support 89.55% https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy Global browser support 91.61%
@tghosth
do the COOP and COEP response headers definitely prevent the same thing as the rel=noopener attribute. Should this be one requirement or two?
Yes, but only the COOP header is required for this (when set with the proper config). From MDN:
COOP will process-isolate your document and potential attackers can't access your global object
COOP and COEP together permit Cross-Origin Isolation, but that is separate from this discussion.
The extent to which browser support COOP and COEP is likely in line with the extent to which they protect against tab nabbing by default. Based on my understanding, I think we can drop this with no action for now.
@elarlang Recommending closing this issue for these reasons:
- Tabnabbing is mitigated by the browsers by default with high and increasing (over time) support
- There is insufficient evidence of impact from not implementing a strict COOP configuration
- I think there could be an argument for a strict COOP for L3 apps as a defense in depth mechanism, but present requirements should cover existing attack vectors
- There is insufficient evidence of impact from not implementing a strict COEP configuration
- Combined COOP and COEP to achieve Cross-Origin Isolation is necessary to unlock browser features, but not a security requirement
- Both headers are relatively new, seemingly widely misunderstood (or unknown), and have some differences in browser support of directives
If someone looks at this in the future, I think it is worth evaluating whether there are XS-Leak type attacks that are impactful and not sufficiently mitigated by other ASVS requirements.