1725385 - Race Condition which doesn't destroy session (DELETE request not sent like it is in Chrome)

Status: RESOLVED WONTFIX

(Web Compatibility :: Site Reports, task)

Description

[u631114]

Hi team,
this begins when i was testing a private program and find that firefox is making this issue when i tried to reproduced in chrome and other browsers.

demo site:- zinc-app.com

#steps:-

1. open demo site in firefox latest version.
   2 create account in demo site or login into it.
2. now copy the cookies and press logout.
3. now you are logout.
4. now paste the same cookies and refresh the page.
5. now you aare inside account.

now you can try this on chrome browser (latest) , that cookies will be destroyed instant on logout.

i reported this to program thought that it is site's vulnerability but they told me this is firefox issue which is called Race condition which makes this happen

Comment 1

[:Gijs (he/him)]

(In reply to Gaurav from comment #0)

3. now copy the cookies and press logout.
4. now you are logout.
5. now paste the same cookies and refresh the page.

What do these steps mean? Which cookies are you copying/pasting, and how are you doing that? Are you using devtools, or burp, or something else? Perhaps a screencast would help?

Also, I don't want to sign up into this "demo site" with my work address, but it does not allow other addresses. Can you provide steps that work more generically?

Comment 2

[u631114]

hi , thanks for following up.

First i want to say demo means this site you can test , this site also run bug bounty program and i was testing this and their security team told me that this is firefox issue not web app, so i reported here.

let's start

1. Which cookies are you copying/pasting
   -> login to https://zinc-app.com/ , once you enter into account copy your session cookies.

2. how are you doing that?
   -> i used cookie extension for firefox and chrome to test this.

i screen recorded this behaviour

for firefox :- https://drive.google.com/file/d/1FvCpnApkZ55RCZKgn5HLCt9XM7lwBsRe/view?usp=sharing
for chrome :- https://drive.google.com/file/d/16L5qwbaOICQzlzfpAWDILckVZaGH4bht/view?usp=sharing

Comment 3

[:Gijs (he/him)]

I don't see why this is a browser issue. If you can replicate the login cookies completely, of course the site treats you as logged in, as long as the session is valid.

If logout doesn't destroy the validity of the session on the server (making the data in the cookies useless) then that's a server-side issue with the application. If the people making the application think it's a Firefox issue, we're going to need a lot more details from them as to why they believe that to be the case - it looks like the click on the "Sign out" button is supposed to navigate to zinc-app.com/logout, and the request to that endpoint should give the server time and opportunity to invalidate the session, irrespective of which browser makes that request, so that subsequent requests with the old cookies no longer treat you as logged in.

The reason it doesn't work in Chrome in your video is that the cookie import doesn't fully restore the cookies - you can see pretty clearly in your video (at about 00:40) that only the hide-notification-banner and saw-suggested-organizations-page cookies get restored, not the auth/anonymous_id/user_id/intercom-session cookies, which do get restored in the Firefox video.

Comment 4

[u631114]

but according to the team, there is a DELETE request which is made on logout button. firefox doesn't generate DELETE request whereas chrome does.

Comment 5

[:Gijs (he/him)]

(In reply to Gaurav from comment #4)

but according to the team, there is a DELETE request which is made on logout button. firefox doesn't generate DELETE request whereas chrome does.

That was nowhere in your report, nor is it visible in your video. I also don't understand why the website can't do this thing entirely in the backend, without relying on a client-side additional request, but I guess that's a separate issue...

Can you create a more minimal testcase, or provide login details that allow reproducing the problem with the zinc app? Did any more diagnosis happen about why the DELETE request is not sent in Firefox?

Comment 6

[u631114]

hi ,

provide login details that allow reproducing the problem with the zinc app

yeah, sure but zinc app does login via otp

below i wrote my email which i used to login. before login please text me on twitter so i can provide you otp code.

my email for zinc app :- [e-mail]
my twiiter :- https://twitter.com/crypt0gr4ph3r

Comment 7

[:Gijs (he/him)]

(In reply to Gaurav from comment #6)

hi ,

provide login details that allow reproducing the problem with the zinc app

yeah, sure but zinc app does login via otp

below i wrote my email which i used to login. before login please text me on twitter so i can provide you otp code.

This doesn't sound very workable longer-term... It also appears that I can't register with my own hackerone email? :-\

(In reply to :Gijs (he/him) from comment #5)

(In reply to Gaurav from comment #4)

but according to the team, there is a DELETE request which is made on logout button. firefox doesn't generate DELETE request whereas chrome does.

Actually, is this based on a conversation on hackerone? Can you just add user gijsk to the hackerone ticket so I can talk directly to the zinc-app folks?

Comment 8

[u631114]

Actually i reported 5 months ago to the zinc team. after that they never responded to me back. and due to bad responce i left that program on hackerone.

please login now with email "[e-mail]" , once i got otp i will provide here instantly.

Comment 9

[:Gijs (he/him)]

I don't think it's workable to ask you for an OTP code every time we log in, especially as the flow we'd have to be testing in 2 or more browsers is a logout one, so we'd need a new one every time we run a testcase.

At this point I don't think this is a Firefox security issue, but if the site cooperates we can investigate the web compat issue with the DELETE not being sent - we'd need a lot more context to figure out why that wouldn't happen before we can bounce this back to relevant engineers with a minimal testcase, if it is indeed a browser issue.