FireFox Same Site "Strict" Cookie Bypass via firefox/firefox-private protocol/schemes registered with the OS and using an external browser
Categories
(Firefox :: Installer, defect)
Tracking
()
People
(Reporter: iamnarendrabhati, Assigned: nipunshukla002)
References
(Regression)
Details
(Keywords: regression, reporter-external, sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main123+])
Attachments
(2 files)
|
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
|
232 bytes,
text/plain
|
Details |
Dear Team,
Here are the vulnerability details.
Description
SameSite is an attribute that can be set for cookies in web browsers. It is used to control how cookies are sent with cross-site requests. The SameSite attribute helps mitigate the risk of cross-site request forgery (CSRF) attacks and protects user privacy.
There are three possible values for the SameSite attribute:
-
Strict: When a cookie has the
SameSite=Strictattribute, it will only be sent in a first-party context. This means that the cookie will only be sent if the request originates from the same site as the one that set the cookie.Example:
Set-Cookie: mycookie=myvalue; SameSite=Strict; -
Lax:With
SameSite=Lax, cookies are allowed to be sent with top-level navigations and safe HTTP methods (like GET), but they will not be sent when the request is initiated by a third-party website through methods such as a cross-origin POST request.Example:
Set-Cookie: mycookie=myvalue; SameSite=Lax; -
None: Setting
SameSite=Noneallows cookies to be sent with both first-party and third-party requests. This is often used for scenarios where the cookie needs to be sent across different domains, such as when embedding content from one site into another.Example:
Set-Cookie: mycookie=myvalue; SameSite=None; Secure;
Uses of Same Site Cookies
CSRF Protection: CSRF attacks involve an attacker tricking a user's browser into making an unintended request to a different site where the user is authenticated. If cookies are sent automatically with every request, the attacker could exploit this to perform unauthorized actions on behalf of the user. SameSite helps mitigate this risk by preventing cookies from being sent in certain cross-site scenarios.
What is Browser Fails to Protect Same Site Cookies
If a browser fails to properly enforce the SameSite=Strict attribute for cookies, it can have security implications, particularly in the context of cross-site request forgery (CSRF) attacks. Here are the potential impacts:
-
CSRF Vulnerability: The primary purpose of SameSite=Strict is to protect against CSRF attacks by preventing cookies from being sent in cross-site requests. If a browser fails to enforce this attribute, it could expose users to CSRF vulnerabilities. An attacker might be able to initiate unauthorized actions on behalf of a user if their cookies are automatically included in requests to a different site.
Ex. Daps Website/Program run inside firefox website, might have using SameSite cookie protection (now days most of them are doing it for CSRF protection) Now developer will think that because they have used SameSite Strict cookies, they are safe from CSRF attacks but because of this bypass they are still vulnerable. -
Unauthorized Actions: CSRF attacks typically involve tricking a user's browser into performing actions on a target site without the user's consent. If SameSite=Strict is not enforced, an attacker could potentially perform actions, such as changing the user's account settings, making financial transactions, or performing any action that the user is authorized to do on the target site.
-
Cross-Site Tracking: SameSite=Strict also enhances privacy by preventing automatic cookie inclusion in cross-site requests. If this protection is not in place, third-party sites may have increased visibility into users' activities across different domains, leading to potential tracking and profiling.
-
Reduced Security by Design: SameSite=Strict is designed to be a security measure by default. If a browser fails to enforce it, the security posture of the web becomes weakened, as developers may rely on this protection when building and securing web applications.
Tested On
Windows 11 Pro
FireFox Window Version 121.0
The POC
Video https://drive.google.com/file/d/12SSLaTQHiNWHYt-53zC3yPO3_NjGLrg7/view?usp=sharing
POC Exploit Codes - Readily available below
https://g00gle.in/samefirefox/ss.php
https://g00gle.in/samefirefox/ss.html
https://g00gle.in/samefirefox/attacker.html
1.Browse https://g00gle.in/samefirefox/ss.php and First click on 1) FirstSet Same Site Cookie Button which will create the same site strict cookie name as SecretCookie and its value as IUHUIGIGAIIGIGUIGSUIGIGIGSIGUIGUIFFTFDTRFYVUVBHJBHJ for website https://com.egghunter.in
2. Go back and now click on 2 ) Verify Same Site Cookie Are Se now because the cookies are set as Strict you won't find them request to https://com.egghunter.in this is how FireFox browser is protecting user from CSRF Attacks because g00gle.in is cross domain which is requesting to "com.egghunter.in" both are cross domain so Strict Cookie won't be pass.
3. Now from Google Chrome browse this https://g00gle.in/samefirefox/attacker.html , there will be button to "Open In FireFox" open it and click on Open in prompt.
4. It will redirect from chrome to firefox with URL pointing to https://com.egghunter.in/showcookie.php but this time the SameSite cookies are sent to that server, which shows we bypass the SameSite cookie protection of firefox browser.
Suggestion
Do not send the same site a strict cookie via deeplink.
CVSS Score
-
Attack Vector (AV): Network (N)
- Reason: The attack is conducted remotely, targeting the network. This aligns with the scenario where a browser fails to protect SameSite=Strict cookies, and an attacker can exploit the vulnerability remotely.
-
Attack Complexity (AC): Low (L)
- Reason: Exploiting the failure in SameSite=Strict is not particularly complex and can be achieved with relatively low effort.
-
Privileges Required (PR): None (N)
- Reason: The assumption is that the attacker does not require any specific privileges to exploit the vulnerability. The attack can be carried out with minimal access.
-
User Interaction (UI): Required (R)
- Reason: Victim needs to interact with attacker URL.
-
Confidentiality (C): High (H)
- Reason: The failure to protect SameSite=Strict cookies can lead to a high impact on confidentiality, potentially exposing sensitive information (cookies).
-
Integrity (I): High (H)
- Reason: The integrity of the system is highly impacted by the vulnerability, as the attacker can tamper with data or perform unauthorized actions using CSRF attack which is most important part of introducing same site cookies.
-
Availability (A): Low (L)
- Reason: The assumption is that while the vulnerability has an impact on availability, it is not as severe as the impacts on confidentiality and integrity. The focus is on data manipulation rather than denial of service.
Impact
-
CSRF Vulnerability: The primary purpose of SameSite=Strict is to protect against CSRF attacks by preventing cookies from being sent in cross-site requests. If a browser fails to enforce this attribute, it could expose users to CSRF vulnerabilities. An attacker might be able to initiate unauthorized actions on behalf of a user if their cookies are automatically included in requests to a different site.
-
Unauthorized Actions: CSRF attacks typically involve tricking a user's browser into performing actions on a target site without the user's consent. If SameSite=Strict is not enforced, an attacker could potentially perform actions, such as changing the user's account settings, making financial transactions, or performing any action that the user is authorized to do on the target site.
-
Cross-Site Tracking: SameSite=Strict also enhances privacy by preventing automatic cookie inclusion in cross-site requests. If this protection is not in place, third-party sites may have increased visibility into users' activities across different domains, leading to potential tracking and profiling.
-
Reduced Security by Design: SameSite=Strict is designed to be a security measure by default. If a browser fails to enforce it, the security posture of the web becomes weakened, as developers may rely on this protection when building and securing web applications.
Comment 1•1 year ago
|
||
Reporter: Does clicking the same "Open in Firefox" link from within Firefox not achieve the same thing?
:mhughes / :nshukla: this protocol handler is new. What is its purpose? I can't tell from bug 1862450. Would it be OK if we used null principal for this type of load?
| Assignee | ||
Comment 2•1 year ago
|
||
The purpose of the protocol handler is to enable a Chromium extension to open websites in Firefox. I’m unfortunately not familiar with the fundamentals of null principal but as long as it still enables a system app to open a site in Firefox through the protocol there shouldn’t be any issues.
| Reporter | ||
Comment 3•1 year ago
|
||
@Gijs - No, it does not work when clickingg the same "Open in Firefox" link from within Firefox infact by clicking from firefox even does not open a normal URL like this "<a href="firefox://google.com">Open in Firefox</a>" looks like from firefox only we can call firefox but from external apps (What we seen this bug) we can call firefox.
But even if we call firefox from any other app like Chrome or something the bug is sill there, same site strict cookies are getting passed which is not an expected behaviour.
| Assignee | ||
Comment 4•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
| Reporter | ||
Comment 5•1 year ago
|
||
@Gijs @Nipun Shukla - Filled a new report https://bugzilla.mozilla.org/show_bug.cgi?id=1873364 for FireFox Focus iOS where, POC works within browser as well which means, clicking the same Prompt Link from within Firefox Focus will achieve the same thing.
Comment 6•1 year ago
|
||
(In reply to Narendra Bhati from comment #3)
infact by clicking from firefox even does not open a normal URL like this "<a href="firefox://google.com">Open in Firefox</a>"
Are you deliberately leaving out the http/https bits here, and/or does that make a difference? (Id est, in a quick test, using firefox:https://google.com/ on my mac at least shows me the "do you want to open this with Firefox Nightly" prompt when opened from Firefox beta.).
What do you mean by "does not open a normal URL"? And what happens instead? (if "nothing" when clicked, can you check the browser console?)
looks like from firefox only we can call firefox
Who is "we" here / what do you mean?
| Reporter | ||
Comment 7•1 year ago
|
||
Reply to Comment6 - Gijs
Yes, I tried "firefox:https://google.com" as well and it shows the prompt "do you want to open this with Firefox" from firefox but after clicking nothing happenes.
This only works when user call "firefox:https://google.com" from external browser.
"Who is "we" here / what do you mean?"
Sorry for the confusion, when I explain anything I mostly use WE keyword. We means I as an user.
| Assignee | ||
Comment 8•1 year ago
|
||
I did a bit of investigation around this -- it seems to always work when you're going from any external application to Firefox. That could be from Firefox Beta to Nightly like in Gijs example. However, if you put firefox:https://www.google.com in the Firefox install which receives the protocol (the one that would've launched) then this error is printed in the terminal:
JavaScript error: resource://gre/modules/ContentDispatchChooser.sys.mjs, line 117: NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIHandlerInfo.launchWithURI]
On a surface glance, this seems more like a (non-sec) issue in our original launchWithURI function than anything else. It looks like it doesn't know what to do when it tries to launch itself, although I haven't gone deeply enough in the code of that function yet to figure out where exactly it's failing. I also haven't filed a bug for it yet as I'm not entirely aware of the protocol when filing a non-sec bug that was found in a security issue. I think it wouldn't be an issue but I'll hold off until someone can confirm that for me.
Comment 9•1 year ago
|
||
:Nipun Shukla we are near the end of the beta cycle. 122.0b9 builds on 2024-01-12.
Though the patch is pending review, any concerns with timing/risk on an uplift for Fx122?
| Assignee | ||
Comment 10•1 year ago
|
||
I think it should still be possible to have it ready for uplift by Beta 9. However, if reviews take longer or if some unforeseen issues arise what would be the best course of action? Would this be a candidate for a release uplift into a 122 dot release or would it instead be landed onto 123?
Comment 12•1 year ago
|
||
(In reply to Nipun Shukla from comment #8)
I did a bit of investigation around this -- it seems to always work when you're going from any external application to Firefox. That could be from Firefox Beta to Nightly like in Gijs example. However, if you put
firefox:https://www.google.comin the Firefox install which receives the protocol (the one that would've launched) then this error is printed in the terminal:JavaScript error: resource://gre/modules/ContentDispatchChooser.sys.mjs, line 117: NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIHandlerInfo.launchWithURI]On a surface glance, this seems more like a (non-sec) issue in our original
launchWithURIfunction than anything else. It looks like it doesn't know what to do when it tries to launch itself, although I haven't gone deeply enough in the code of that function yet to figure out where exactly it's failing. I also haven't filed a bug for it yet as I'm not entirely aware of the protocol when filing a non-sec bug that was found in a security issue. I think it wouldn't be an issue but I'll hold off until someone can confirm that for me.
I know this one!
This is the result of some hacky code I added. Basically it does this to (attempt to) force a prompt that asks "what do you want to do with this protocol", because if we keep launching ourselves recursively with the same URI, that goes badly (e.g. bug 215554 and all its dupes).
See also: https://searchfox.org/mozilla-central/rev/52f45d12530f9f8da61c6c7237003b5d1499b6d1/toolkit/mozapps/handling/ContentDispatchChooser.sys.mjs#86-93 and https://searchfox.org/mozilla-central/rev/52f45d12530f9f8da61c6c7237003b5d1499b6d1/uriloader/exthandler/nsMIMEInfoImpl.cpp#366-382 .
Comment 13•1 year ago
|
||
Too late for 122.0, switching tracking to Fx123
Updated•1 year ago
|
Comment 14•1 year ago
|
||
Comment 15•1 year ago
|
||
| Reporter | ||
Comment 16•1 year ago
|
||
Dear All, Just a request. Please refrain from making the details of the recent bug public for the next few months. Other browsers are also vulnerable, and their teams are working on fixes. This measure aims to prevent potential misuse of the vulnerability. Your cooperation is appreciated.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 17•1 year ago
|
||
The patch landed in nightly and beta is affected.
:nshukla, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox123towontfix.
For more information, please visit BugBot documentation.
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 18•1 year ago
|
||
Comment on attachment 9371396 [details]
Bug 1873223 - Modified firefox and firefox-private protocol handler behavior r=Gijs,mhughes
Beta/Release Uplift Approval Request
- User impact if declined: This is a security issue that could conceivably expose user data if same site cookies aren't correctly protected. It's also rated as sec-moderate so it's ideal if we can
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): There is a risk that in cases where the system principal should be used, a null principal is used instead. This is furthered by the lack of automated testing in this area. However, it has been tested extensively locally by multiple people so the risk isn't very high.
- String changes made/needed:
- Is Android affected?: Yes
Comment 19•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Comment 20•1 year ago
|
||
Comment on attachment 9371396 [details]
Bug 1873223 - Modified firefox and firefox-private protocol handler behavior r=Gijs,mhughes
Approved for 123 beta 4, thanks.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 21•1 year ago
|
||
Updated•1 year ago
|
Updated•11 months ago
|
Updated•7 months ago
|
Description
•