Security/Reviews/MozillaID
From MozillaWiki
Contents
Background
Project Page
https://intranet.mozilla.org/Projects/MozillaID
Bugzilla Review Trackers
Links
https://wiki.mozilla.org/MozillaID
https://wiki.mozilla.org/MozillaID/Spec
https://wiki.mozilla.org/MozillaID/InternalSpec
https://wiki.mozilla.org/MozillaID/HTML_Client
https://wiki.mozilla.org/File:DataFlow.png
Architecture
Data Flow
Threat Model
Likelihood and impact ratings are based on 1-5 scale without consideration for mitigating controls. In other words, the risk rating provides justification for the need of the proposed mitigation.
| ID | Threat | Proposed Mitigation | Threat Agent | Rating (L * I) | Likelihood | Notes | Impact | Notes | Status |
| 1 | Sites using Mozilla ID could interact with the user over an insecure protocol (HTTP) | [Out of Mozilla's Control] Documentation - Advise sites using Mozilla ID of best practices for securely interacting with users at their site (e.g. HTTPS best practices) | Public Attacker - Man in the middle attacker with network proximity to victim or site.com | 6 | 3 | Dependent upon third party site practices | 2 | Attacker could replace site.com with a phishing site | feature / bug link |
| 2 | CSRF Login Attack - force victim to Mozilla API as the attacker's user | 1. CSRF token support on login page 2. Set HSTS for identity.mozilla.org | Public Attacker | 2 | 2 | . | 1 | Minimal direct risk when used by itself. May be combined with another issue which requires user to be authenticated. | feature / bug link |
| 3 | Classic CSRF to force authenticated victim to pick particular email address for a site | CSRF token within pick email | Malicious site | 4 | 2 | CSRF attack would need to be targeted since the email address is submitted during the selection process | 2 | Successful attack would allow attacker to force which email address a targeted user authorizes with a site. Could be used if attacker has compromised one of user's email accounts. | feature / bug link |
| 4 | Clickjacking of Popup to influence authorized email selection or to force previously associated user login to change email with site | x-frame-options: deny | Malicious site | 4 | 2 | Clickjacking attacks are more complex, but gaining in popularity | 2 | Site could influence selected email. No known benefit | feature / bug link |
| 5 | Clickjacking of Iframe Login to force new user to associate with site | Acceptable Risk - user would be convinced to enter all pertinent user data into a mock page for clickjacking to work. Attacker would more likely just allow user to submit this to the evil site instead of clickjacking the data through. | Public Attacker | 1 | 1 | Requires clickjacking user to enter password. | 1 | No known benefit of forcing user to create account if already fooled to enter sufficient data to create account. | feature / bug link |
| 6 | Man in the middle intercepts or modifies traffic between browser and Mozilla ID API | 1. No support for HTTP on MozillaAPI 2. HSTS 3. Secure Flag for cookies 4. Be as strict as possible with checking origin of postmessage / sending to specific origins | Public Attacker - Man in the middle attacker with network proximity to victim or site using Mozilla ID | 6 | 3 | Network monitoring point is between victim and Mozilla API. Common attack on shared networks. | 2 | Exposure would include username & password. Number of users would be minimal since attack requires network proximity to victim. Attack still possible at last hop before Mozilla infrastructure but additional controls present on these devices. | feature / bug link |
| 7 | Man in the middle intercepts or modifies traffic between site.com verification server and Mozilla ID API | 1. Do not provide HTTP support only HTTPS 2. Provide documentation to site.com indicating which certificate should be expected and links to validating cert authenticity. | Public Attacker | 9 | 3 | Requires network proximity between targeted site and mozilla API servers | 3 | Would compromise identification process of all users for targeted site | feature / bug link |
| 8 | Man in the middle intercepts or modifies traffic between the site.com page and site.com servers | [Out of Mozilla's Control] Documentation - site.com should use HTTPS & verify no cert errors | Internal Attacker | 9 | 3 | Requires network proximity between targeted site and site.com server | 3 | Would compromise identification process of all users for targeted site | feature / bug link |
| 9 | Man in the middle intercepts traffic between Mozilla API server and back end databases | Encrypted connection or private vlan | Malicious Insider/Employee | 15 | 3 | Requires network access to restricted server network and monitoring capability | 5 | Would compromise identification process of all users for all sites | feature / bug link |
| 10 | ID assertion replay attack (via xss) with assertion obtained from other site | 1. ID Assertion must include audience within encrypted JWT. 2. API & Site validation of ID assertion must verify audience is correct. 3. Include Nonce so ID assertion can only be used 1 time. Mitigates concern of token be replayed even if the user logs out of site.com | Public Attacker | 6 | 3 | More advanced attack requiring an understanding of the protocol. Requires obtaining a valid ID assertion for the victim user. | 2 | Allows access as the targeted user | feature / bug link |
| 11 | Brute force attack against Mozilla API login | Threshold based captcha per username & per IP address | Public Attacker | 12 | 3 | An extensive brute force would be loud but could continue unchecked if automated defenses are not present. | 4 | A brute force attack could identify a large number of user passwords | feature / bug link |
| 12 | Weak password policy for MozillaAPI accounts allows easy guessing of passwords | Adhere to password strength policy | Public Attacker | 20 | 5 | A brute force attack is easy to mount and could be performed by any user | 4 | A weak password policy could result in the compromise of many user accounts. | feature / bug link |
| 13 | Malicious site forges Audience of another site to obtain ID assertion for user against another site | 1. Audience is obtained from event.origin 2. No risk from an attacker modifying the audience for calls to the api (via proxy, wget, etc) | Malicious Site | 0 | 0 | No known negative impacts | feature / bug link | ||
| 14 | Site passes verification of ID assertion via request/response through user - subject to user changing result | [Out of Mozilla's Control] Provide guidance for sites to avoid this design pattern | Public Attacker | 4 | 2 | Possible a site using MozillaID API will incorrectly design their solution | 2 | Allows any user to forge control of an email address | feature / bug link |
| 15 | Malicious/Insecure Site.com discloses everything obtained from MozillaAPI service | Establish clear expectationswith users as they interact with MozillaAPI regarding what they are exposing and to whom | Malicious Site | 6 | 3 | Likely that some site interacting with Mozilla API and is not under Mozilla control, is eventually compromised | 2 | Compromise is completely out of the control of Mozilla. Impact to mozilla is exposure of emails that have been authorized by the user through Mozilla API for use at the specific site. | feature / bug link |
| 16 | Theft of identity.mozilla.com session cookie | 1. Set cookie domain to subdomain, not parent 2. Set Secure flag 3. Set HTTPOnly Flag 4. Set STS 5. Use short life span for session (inactivity & absolute) | Public Attacker | 8 | 2 | Minimal risk for xss which would be predominant method of obtaining sesison cookie | 4 | allows attacker access to user's account on all supported sites | feature / bug link |
| 17 | Unexpected user controlled data passed to the API isnot properly handled | 1. Perform input validation to ensure received data is well formed 2. Use appropriate output escaping/parameterization to safely use data with any connected systems (e.g. output to html, output to SQL) | Public Attacker | 5 | 5 | Standard fuzzing would send unexpected data | 1 | API should robuestly handle unexpected data | feature / bug link |
| 18 | Phishing due to user misreading the service's URL address bar | 1. Will be minimized with native chrome in milestone 2 2. Monitoring domain registrations / safe browsing databases | Public Attacker | 6 | 3 | Data shows that users fall victim to phishing attacks | 2 | Impact is limited to the specific user that has entered their credentials to the phishing site. | feature / bug link |
| 19 | Internal (to Mozilla) attacks leading to disclosure of email addresses and/or site affiliations of users and/or linking email addresses together to a comprehensive identity | 1. Internal operating security policies 2. For additional discussion | Malicious Insider/Employee | 15 | 3 | Data shows that large organizations have internal data breaches. | 5 | Large amount of user data would be disclosed | feature / bug link |
