Closed Bug 1145788 Opened 11 years ago Closed 11 years ago

Broken auth and session management in hello.firefox.com

Categories

(Hello (Loop) :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: kathuriaranjan, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Build ID: 20140715214327 Steps to reproduce: Suppose there are 3 people here , V (victim) , A1(Attacker-1), A2(Attacker-2) ! 1)-Now victim V registers himself on hello.firefox.com, and starts a new conversation. 2)-Now he invites Attacker (A1) and sends him a link on his email id say attacker1@mail.com 3)-Now what A1 will do is not to use that link and further send it to A2 (Attacker-2) and A2 will go to that link and and accepts the invitation. 4)-Now the conversation is between the V and A2, even that link is never sent to any A2. 5)-Even if A2 leaves the conversation he can pass on this link to any other Attacker. Actual results: Actual results are that teven A2 was not invites at all , still he can have a conversation with V. Expected results: The token which comes in the form https://hello.firefox.com/[token] should be validate only with the email address to which the invitation is sent , e.g if A sends the request token to B then only B should be able to access that token (because the token should be linked with the email address)
Component: Untriaged → General
Product: Firefox → Loop
Version: 31 Branch → unspecified
Flags: needinfo?(sescalante)
This isn't a security problem, it's an intended aspect of the rooms design. The "Victim" in your scenario shouldn't be sending a room URL to an "Attacker", and should have the expectation that the room link can be shared (indeed sharing links is meant to be easy).
Group: core-security
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Flags: needinfo?(sescalante)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.