From MozillaWiki
Jump to: navigation, search


Project Page

Bugzilla Review Trackers

Milestone 1 Review




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 6 3 Dependent upon third party site practices 2 Attacker could replace 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 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 verification server and Mozilla ID API 1. Do not provide HTTP support only HTTPS 2. Provide documentation to 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 page and servers [Out of Mozilla's Control] Documentation - should use HTTPS & verify no cert errors Internal Attacker 9 3 Requires network proximity between targeted site and 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 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 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 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