Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

tabnabbing #1602

Closed
securitydave opened this issue Apr 3, 2023 · 24 comments
Closed

tabnabbing #1602

securitydave opened this issue Apr 3, 2023 · 24 comments
Assignees
@elarlang @securitydave
Labels
1) Discussion ongoing Issue is opened and assigned but no clear proposal yet V50 Group issues related to Web Frontend _5.0 - Not blocker This issue does not block 5.0 so if it gets addressed then great, if not then fine.

Comments

@securitydave
Copy link

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
@elarlang
Copy link
Collaborator

elarlang commented Apr 3, 2023

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:

@elarlang elarlang added the 2) Awaiting response Awaiting a response from the original poster label Apr 3, 2023
@securitydave
Copy link
Author

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?

@securitydave
Copy link
Author

At caniuse.com, "noopener" and "noreferrer" are well supported.

@elarlang
Copy link
Collaborator

elarlang commented Apr 4, 2023

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

@securitydave
Copy link
Author

securitydave commented Apr 4, 2023 •
edited
Loading

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>

@elarlang
Copy link
Collaborator

elarlang commented Apr 5, 2023

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:

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

@elarlang
Copy link
Collaborator

elarlang commented Apr 5, 2023

@securitydave - if there are no other arguments, I'll close this issue (in the future).

@securitydave
Copy link
Author

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.

@elarlang
Copy link
Collaborator

elarlang commented Apr 6, 2023

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: #959

@elarlang elarlang added 1) Discussion ongoing Issue is opened and assigned but no clear proposal yet and removed 2) Awaiting response Awaiting a response from the original poster Will be closed if no response/opposite arguments labels May 25, 2023
@elarlang
Copy link
Collaborator

Decision to make - should we have level3 requirement to cover opener configuration.

@securitydave
Copy link
Author

As already stated, I advise including rel="noopener" on links supplying a non-blank target. I think it's a requirement.

@tghosth tghosth added the _5.0 - prep This needs to be addressed to prepare 5.0 label Jul 10, 2023
@tghosth
Copy link
Collaborator

tghosth commented Jul 10, 2023

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?

@elarlang
Copy link
Collaborator

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 target attribute with some name (not _self or _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 (#1299)

Like I wrote here: #1602 (comment)

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:

@tghosth
Copy link
Collaborator

tghosth commented Jul 27, 2023

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?

@elarlang
Copy link
Collaborator

Depends on how many more years 5.0 takes :)

but all the arguments were written in my previous comment.

@tghosth
Copy link
Collaborator

tghosth commented Sep 28, 2023 •
edited
Loading

@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/

@elarlang
Copy link
Collaborator

I don't know the answer right now, need to do "the lab" first.

@tghosth
Copy link
Collaborator

tghosth commented Sep 28, 2023

Ok so let me know please :)

@elarlang elarlang added the V50 Group issues related to Web Frontend label Dec 6, 2023
@tghosth
Copy link
Collaborator

tghosth commented Jan 24, 2024

Any update @elarlang ?

@elarlang
Copy link
Collaborator

Nope. It is low priority task here and it requires some research.

@elarlang elarlang removed the _5.0 - prep This needs to be addressed to prepare 5.0 label Oct 15, 2024
@elarlang elarlang added the _5.0 - Not blocker This issue does not block 5.0 so if it gets addressed then great, if not then fine. label Oct 15, 2024
@jmanico
Copy link
Member

jmanico commented Nov 7, 2024

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%

@ryarmst
Copy link
Collaborator

ryarmst commented Nov 7, 2024

@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.

@ryarmst
Copy link
Collaborator

ryarmst commented Nov 8, 2024

@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.

@tghosth tghosth closed this as completed Nov 8, 2024
@jmanico
Copy link
Member

jmanico commented Nov 8, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@elarlang elarlang

@securitydave securitydave

Labels
1) Discussion ongoing Issue is opened and assigned but no clear proposal yet V50 Group issues related to Web Frontend _5.0 - Not blocker This issue does not block 5.0 so if it gets addressed then great, if not then fine.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@jmanico @tghosth @ryarmst @elarlang @securitydave