1430650 - cors in accounts.firefox.com

Status: RESOLVED DUPLICATE of bug 1272248

(Cloud Services :: Server: Firefox Accounts, defect)

Description

[Dipak Prajapati]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180103231032

Steps to reproduce:

1) go to https://accounts.firefox.com/settings

2) follow the video poc:https://youtu.be/8cK_VEOjXlE



Expected results:

POORLY IMPLEMENTED, BEST CASE FOR ATTACK:
Access-Control-Allow-Origin: https://attacker.com

Access-Control-Allow-Credentials: true

POORLY IMPLEMENTED, EXPLOITABLE:
Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

BAD IMPLEMENTATION BUT NOT EXPLOITABLE:
Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

or just

Access-Control-Allow-Origin: *

even this is not good from development point of view but due to own rules of CORS if Access-Control-Allow-Origin set to * we don’t get benefit Access-Control-Allow-Credentials: true means no cookie access of the victim.

When you can’t exploit even if above misconfigurations are present:

Comment 1

[:Gijs (he/him)]

Can someone redirect this to the sync server-side folks so they can have a look? Thanks.

Comment 2

[Lina Butler (ex-Mozilla)]

Adding :rfkelly, :bobm, and :ulfr, who might have more insight here.

Comment 3

[Ryan Kelly [:rfkelly]]

Thanks for the report!


This behaviour is known and intentional.  The Firefox Accounts API does not use cookies or other browser state for authentication, so there's no risk of CSRF attacks here.  An attacker can make requests against api.accounts.mozilla.com from their webpage, yes, but that doesn't give them any more power than if they were to just make direct HTTP calls to the API from e.g. curl.

Some previous discussion on CORS for this service, for context:

  https://github.com/mozilla/fxa-auth-server/issues/550#issuecomment-78123218

If there's a way for an attacker to use this to forge requests using the user's local browser state, that's definitely a serious issue and please provide more details.  But I don't see an exploit here as-is.

Comment 4

[Dipak Prajapati]

Answer to RYAN KELLY


This behaviour is known and intentional.  The Firefox Accounts API does not use cookies or other browser state for authentication, so there's no risk of CSRF attacks here.  An attacker can make requests against api.accounts.mozilla.com from their webpage, yes, but that doesn't give them any more power than if they were to just make direct HTTP calls to the API from e.g. curl.


ANS:

during password changing (the request looks like this)

=====================
POST /v1/account/login HTTP/1.1
Host: api.accounts.firefox.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://accounts.firefox.com/
Content-Type: application/json
Content-Length: 138
Origin: https://evil.com
Connection: close

{"email":"[e-mail]","authPW":"3309033d0a50bxxxxxxxxxxxxxb43e29e4bdd5cd0432be6xxxxxxxx904b","reason":"password_check"}
======================



AND THIS IS THE RESPONSE


======================
HTTP/1.1 200 OK
access-control-allow-origin: https://evil.com
access-control-expose-headers: WWW-Authenticate,Server-Authorization,Timestamp,Accept-Language
cache-control: no-cache
Content-Type: application/json; charset=utf-8
Date: Wed, 17 Jan 2018 11:25:26 GMT
public-key-pins: pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="; max-age=5184000; includeSubdomains
strict-transport-security: max-age=15552000; includeSubDomains
timestamp: 1516188326
vary: origin,accept-encoding
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: DENY
x-xss-protection: 1; mode=block
Content-Length: 160
Connection: Close

{"uid":"224850ad9XXXXXXXX5ce2f18c9a","sessionToken":"b8bdce358bbaXXXXXXXXXXXXXXXXXX036c6ff4cc7b93fXXXXXX5c590497","verified":true,"authAt":15XXXX8326}
==========================



HERE USER ID , SESSIONtOKEN ETC CAN BE ATTACKED
:
:
{"uid":"224850ad9XXXXXXXX5ce2f18c9a","sessionToken":"b8bdce358bbaXXXXXXXXXXXXXXXXXX036c6ff4cc7b93fXXXXXX5c590497","verified":true,"authAt":15XXXX8326}

Comment 5

[Mark Hammond [:markh] [:mhammond]]

Can we make bug 1272248 public?

Comment 6

[Ryan Kelly [:rfkelly]]

Sorry, I still don't understand what kind of attack you're proposing here.

> during password changing (the request looks like this)

Who is initiating this request?  The user, or the attacker owning evil.com?  Where did "authPW" come from?

> HERE USER ID , SESSIONtOKEN ETC CAN BE ATTACKED

Attacked how?

If a webpage on evil.com is able to initiate this request and receive the response, then that webpage must already know the user's account password - otherwise where did "authPW" come from in the request body?  And if it already know's the user's account password, it could easily proxy requests to our API on the backend in order to overcome CORS restrictions.

Comment 7

[Ryan Kelly [:rfkelly]]

> Can we make bug 1272248 public?

Done, thanks Mark.