If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Sec review for alpha (but public) Firefox ID deployment

RESOLVED DUPLICATE of bug 644776

Status

mozilla.org
Security Assurance: Applications
RESOLVED DUPLICATE of bug 644776
7 years ago
7 years ago

People

(Reporter: thunder, Unassigned)

Tracking

Details

(Reporter)

Description

7 years ago
* A quick intro to what this app does.

Firefox ID (aka Mozilla ID) is a service for issuing and verifying identity assertions to websites. An identity assertion is a cryptographically signed JSON document that verifies to the website that a browser session is associated with an email address. This allows a website to sign in a user, using their email address as the ID, without any additional passwords being required.

* Where is the source code located?

http://hg.mozilla.org/services/server-identity

* Is there a stage server running that we can also test against? If so, please indicate what machine the web server is running on.

Yes. See below for how to create an account in our staging area (note: user db is shared with sync, so it's the same as the sync staging ldap).

The staging service is deployed on http://web4.dev.svc.mtv1.mozilla.com/. It can be tested by visiting a page that uses the API, such as this one:

http://evilonastick.com/id/

* Where would you like the bugs filed in bugzilla? Please specify the product, component and if anyone specific should be copied on the bugs.

no component in bugzilla yet. Maybe websites/other for now? Make sure you Cc me (:thunder) and JR (:jrconlin)

* Please describe if this app will be connecting to any internal or external services or if it is able to interact with the OS.

JR, please comment here. I believe the app interacts with LDAP (bound as the user only) and MongoDB.

* Does this app support logins or multiple roles? If so, we'll need test accounts created for each available role.

Yes, it supports logins. It does not have multiple roles. Test accounts can be created at will by using the Sync set-up flow. Use the following server to create an account in our staging area:

https://dev-auth.services.mozilla.com/

* What is the worst case scenario that could happen with this system, data or connected systems? (This is used to help understand the criticality of this server.)

It is important to keep the user login data secure. It is the same login data as the Sync service uses.

However, the service itself is not critical, and we will tell web developers testing against it that it should not be counted on to be correct--if it gives incorrect assertions to web developers that's OK.

* Does this website contain an administration page? If so, have the admin page blockers (listed here) all been addressed?

The app does not have an administrator role (access to multiple users' data or anything of the sort). It does have a user admin page, where a logged-in user may see/remove associations made with other sites.

http://web4.dev.svc.mtv1.mozilla.com/{your_email_address}

* This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review?

Urgent - we'd like to go public early next week (11th). We do have a backup plan if this falls through, but our developer evangelism story will be much more effective if we have this service set-up.
(Reporter)

Comment 1

7 years ago
Adding Ben to Cc - he has also been thinking about how to attack this thing.

He pointed out to me a potential CSRF attack on /authorize, depending on what it's checking. JR said it uses the Origin header, if so we might be in the clear.
> * Please describe if this app will be connecting to any internal or external
> services or if it is able to interact with the OS.
> 
> JR, please comment here. I believe the app interacts with LDAP (bound as the
> user only) and MongoDB.

Yes. The app attempts to bind to LDAP in order to authenticate the user's account and password. No info is read from LDAP other than the users UID. This value is used internally as a unique identifier for the user.

All additional information (user email, site association, etc.) are stored in a separate database, currently Mongo. 

The data is stored in two tables who's schema is described in oidserver/storage/mongo.py
Depends on: 648795
(In reply to comment #1)
> He pointed out to me a potential CSRF attack on /authorize, depending on what
> it's checking. JR said it uses the Origin header, if so we might be in the
> clear.

Sid informs me that FF4 does not yet support the Origin header in this particular case (only in CORS AJAX requests):

  https://wiki.mozilla.org/Security/Features#Origin_Header_.2F_Sec-From

I'm told webkit does support the Origin header in all cases, but haven't yet tested this.
I've verified this: FF4 does not send Origin on form post, Chrome does.

Best to implement classic CSRF protection: assign a new random token on session creation, store it in the backend, include it as a variable in every <form method="post">. On every call with side-effect (POST, usually), check that form variable = session-stored nonce. Best if your framework does this automatically, of course. Happy to help with this, just let me know!
so at first glance the CSRF attack on email selection is thwarted because the value of the form variable is the email itself, which is great.

There does appear to be a login CSRF problem: I can log you in as me by submitting to /login, which doesn't cause an immediate problem, but might in the future.

This is by no means a complete review, I just wanted to check out the CSRF issue a bit more. Let me know if I can continue to help, but also don't want to step on existing review work.

Updated

7 years ago
Whiteboard: [pending secreview]
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Whiteboard: [pending secreview]
Duplicate of bug: 644776
You need to log in before you can comment on or make changes to this bug.