MozillaWiki - User contributions [en]

Security/Projects/Minion

2012-10-03T16:19:40Z

Mfuller:

<cite>
Minion is a security testing framework built by Mozilla to bridge the gap between developers and security testers. To do so, it enables developers to scan their projects using a friendly interface.
</cite>

NOTE - this project is at a ''very'' early stage in its development.

* Source code: https://github.com/ygjb/minion - public
* Task management: https://trello.com/b/DlVPzGaS - currently private, contact one of the Minion developers to get access
Developers:
* [[User:Psiinon|Psiinon]]
* TBA

==Initial Diagram==
[[File:Minon_diagram.png]]

==Components==
===Web Interface===
====Overview====
The Web UI is responsible for:
* Generating the web UI (not surprisingly)
* Authenticating and managing users and user sessions
====Notes====
* Log in using Persona (BrowserID) (can be restricted by domain for use on central server by organizations)
* Menu -> New Scan, Running Scans, Completed Scans
** Future: Group Scans (member of groups, permissions, see other scans by group members/project)
* New Scan
** Basic: URL, Port
** Advanced: Login information, technologies used (customize scan such as SQLmap for SQL)
** Future: Scan type based on plugin (web app, client code, etc)
It should maintain as little data in memory as possible - all data should be retrieved from the Task Engine (and/or db?). This will allow us to run multiple Web UI servers for one service.
====Questions====
* Should this also provide a REST based API, or will we rely on the one implemented by the Task Engine?
* Will it need access to the db or will it get all data from the Task Engine?

===Task Engine===
====Overview====
The task engine is responsible for:
* Managing Minions
* Persisting all info to the db
* Providing a REST API
====Notes====
* Instance started when user clicks start scan
* Collects provided information
* Starts scan based on provided information
* Launches tools (Minions) and awaits responses
It should persist all data to a db and maintain as little data in memory as possible. This will allow us to run multiple Task Engine servers for one service, with all of the synchronization happening via the db (which would probably be clustered).

===Minions (Scanners)===
* Receive kickoff from task engine
* Scan target
* Send results back to task engine in necessary format (JSON)

===Target===
* Site hosted by developer
* Can be hosted or running locally

==Configuration Abstraction==
To pass data between components, a standard configuration and data scheme must be used. For Minion, we have decided to use JSON and a REST API as the format for passing data. For example, the user interface will collect the necessary options, then call the task engine and pass it a JSON string of those options. The task engine will read the options and use each installed tool's REST API to make requests to the tool (some tools may need different options than others). The tool will pass its results back to the task engine as a JSON string and the task engine will compile all returned results into a single JSON string which will be returned to the interface. The interface will deconstruct the string into human-readable results and display them on the results page.

===Basic Tool Requirements===
Each tool takes a number of base options as well as optional options that can improve the scan's accuracy or increase its functionality.

====Zed Attack Proxy====
Base options: URL

Optional: spider depth-level, CSRF tokens, authentication information, parameters to fuzz

====Garmr====
Base options: URL

Optional: parameters to test

Note: most options with Garmr involve output, which should be handled without interaction from the user.

====Skipfish====
Base options: URL

Optional: authentication credentials, cookie values, non-standard header information, scan time limit (see http://code.google.com/p/skipfish/wiki/SkipfishDoc for a full list)

Note: Skipfish has a lot of additional options that include domains to exclude in crawling, domains to ignore in testing, wordlist generation, folder output, etc. To make it as easy to use as possible, the Skipfish plugin should include defaults for all of these options so that the user will never need to worry about the options.

==Installation Notes==
PYTHONPATH="$PYTHONPATH:$HOME/minion/task_engine"
PYTHONPATH="$PYTHONPATH:$HOME/minion/plugins"
export PYTHONPATH

sudo easy_install bottle

Security/RiskRatings

2012-09-13T20:56:32Z

Mfuller: /* Impact */

This document is under construction
==Calculating Risk Ratings==
The Security Assurance team calculates risk ratings using a basic methodology capturing the business importance of given actions being requested, and the impact should the action not be adequatly completed.

As all our work is being tracked via bugzilla we are using the <i>importance</i> flags that are already available to classify this work so it can be properly prioritized.

When assessing an item using the tables below, we consider the request in the context of each of the headings, and score each item based on its matching values.

Importance to the business
{| border="1" class="fullwidth-table"
| align="center" |'''Rank'''
| align="center" |'''Priority'''
| align="center" |'''Type'''
| align="center" |'''Definition'''
|-
|5||P1||Incident||An active threat vector to Mozilla
|-
|4||P2||Mozilla Initiative||A project wide initiate to achieve a specific goal (ie. k9o, basecamp)
|-
|3||P3||Overall Mozilla Quarterly Goal||Specific quarterly goal that spans functional areas (includes ongoing goals like "keep Firefox safe")
|-
|2||P4||Team Quarterly Goal (Any Team)||The specific action or bug is directly related to the publicly stated quarterly goals of that area
|-
|1||P5||Age||Reviews that were previously uncategorized but are now older than 'x' time <b><i>need to define x</b></i>
|-
|0||None||Other||Any other request that does not fall into the above categories
|}

==Impact==
The impact of a item is the potential outcome if the threat or negative action is realized. The table below indicates the severity of the impact and what that means across several domains as examples.

{| border="1" class="fullwidth-table"
| align="center" style="background:#f0f0f0;"|'''Rank'''
| align="center" style="background:#f0f0f0;"|'''Impact'''
| align="center" style="background:#f0f0f0;"|'''Operational'''
| align="center" style="background:#f0f0f0;"|'''User'''
| align="center" style="background:#f0f0f0;"|'''Privacy'''
| align="center" style="background:#f0f0f0;"|'''Engineering'''
| align="center" style="background:#f0f0f0;"|'''Reputation'''
|-
|5||blocker||down until fixed or permanently removed||Complete control over the users device||Violation of Privacy Policy with production data||Platform or Application configuration changes needed.||Negative press in mainstream media
|-
|4||critical||Significant Outage (intl store)||The ability to execute scripts and code that is sandboxed on the users device||Violation of Privacy Policy||Reimplementation of core components required.||Negative press in industry media
|-
|3||major||Moderate Outage, complaints from users||Specific information about specific users can be obtained||Moderate concerns over Privacy issues||New development required to resolve issues.||Negative comments from user base
|-
|2||normal||Minor Outage, in line with SLAs||User behaviour can be trended||Minor concerns over Privacy issues||Multiple bug fixes and changes required.||Negative comments from community members
|-
|1||minor||Ops Team Notified||Browser crashes||Unresolved privacy issues inline with Privacy Policy||Platform or Application configuration changes needed.||Negative comments from stakeholders
|-
|}

Total Priority Score = ( (total of impact scores X priority value) / max impact score) X 100)

== What Scores Mean ==
{| border="1"
|
| align="center" style="background:#f0f0f0; style="width: 10%;"|'''Critical (100+)'''
| align="center" style="background:#f0f0f0; style="width: 10%;"|'''High (99-76)'''
| align="center" style="background:#f0f0f0; style="width: 10%;"|'''Medium (75-26)'''
| align="center" style="background:#f0f0f0; style="width: 10%;"|'''Low (25-0)'''
|-
|Effort Estimation || 1 Month || 2 Weeks || 2 Days || <1 Day
|-
|Review Type || Group (Scheduled on SecReview Calendar) || Group (Scheduled on SecReview Calendar) || Individual Reviewer || Individual Reviewer
|-
|Required Documents from development team
{| border="1"
|Architecture Diagram
|-
|Application Diagram,
|-
|Data Flow Enumeration,
|-
|Threat Model
|}
|
{| border="1"
|Required at input
|-
|Required at input
|-
|Required at input
|-
|Created During review with Security Lead
|}
|
{| border="1"
|Created during review
|-
|Created during review
|-
|Created during review
|-
|Created during review
|}
|
None required,
but may speed review
|
None required,
but may speed review
|-
| How Documented || SecReview Wiki || SecReview Wiki || SecReview Wiki -or- in Secreview bug (with indidication of no-wiki) || In SecReview Bug
|-
|}

=Previous Working Copy=
==Calculating Risk Ratings==
The infrastructure security team calculates risk ratings using a basic methodology capturing the likelihood of a threat becoming a successful attack, and the impact should the attack be completed.

When assessing a threat using the tables below, consider the threat in the context of each of the headings, and score each threat for each column. Select the highest score and record that as the impact or likelihood.

=== Example ===

Consider the threat "URL Shorteners get a copy of URLs shared by F1 Users" from the [[Security/Reviews/F1#Threat Model|Mozilla F1 security review]].

Looking at the [[Security/RiskRatings#Likelihood|Likelihood table]] we see:
* Probability is 5 since it is already happening (Ongoing Issue)
* Technical is also 5 since URL shorteners are relatively easy to enumerate

Going to the [[Security/RiskRatings#Impact|Impact table]] we see that:
* Operational impact is zero since it has not effect on the stability of the service
* User impact is 2 since user behaviour can be trended.
* Privacy impact is 4 since sharing information with 3rd parties is a violation of our privacy policies.
* Financial impact is 1 since it is extremely low cost to resolve the issue
* Engineering impact is 3 since replacing the functionality requires authoring new software.
* Reputation impact is 3 since there may be negative comments from our users who do not wish to use the shortening service

The highest Likelihood score is 5, and the highest impact score is 4 (Privacy).

To calculate the risk score simply multiply the likelihood by the impact, in the case of the issue discussed above, the Risk Rating would be 20.

==Likelihood==

{| border="1" class="fullwidth-table"
| align="center" style="background:#f0f0f0;"|'''Likelihood'''
| align="center" style="background:#f0f0f0;"|'''Probability'''
| align="center" style="background:#f0f0f0;"|'''Technical'''
|-
|1||Shouldn't happen||Advanced Attack with requirement of multiple vulnerabilities to exploit
|-
|2||Once every few years||Advanced Attack
|-
|3||Once a year||Moderate difficulty attack vector
|-
|4||Multiple times a year||Common attack vector, requires manual exploit creation
|-
|5||Ongoing issue||Common attack vector, easy to mount with available tools
|}

==Impact==
The impact of a finding is the potential outcome if the threat is realized. The table below indicates the severity of the impact and what that means across several domains within an organization.

{| border="1" class="fullwidth-table"
| align="center" style="background:#f0f0f0;"|'''Impact'''
| align="center" style="background:#f0f0f0;"|'''Operational'''
| align="center" style="background:#f0f0f0;"|'''User'''
| align="center" style="background:#f0f0f0;"|'''Privacy'''
| align="center" style="background:#f0f0f0;"|'''Financial'''
| align="center" style="background:#f0f0f0;"|'''Engineering'''
| align="center" style="background:#f0f0f0;"|'''Reputation'''
|-
|1||Ops Team Notified||Browser crashes||Unresolved privacy issues inline with Privacy Policy||Low cost to remediate||Platform or Application configuration changes needed.||Negative comments from stakeholders
|-
|2||Minor Outage, in line with SLAs||User behaviour can be trended||Minor concerns over Privacy issues||Director approval to pay cost to remediate||Multiple bug fixes and changes required.||Negative comments from community members
|-
|3||Moderate Outage, complaints from users||Specific information about specific users can be obtained||Moderate concerns over Privacy issues||Requires budget changes to remediate||New development required to resolve issues.||Negative comments from user base
|-
|4||Significant Outage (intl store)||The ability to execute scripts and code that is sandboxed on the users device||Violation of Privacy Policy||Requires Board review to pay for remediation||Reimplementation of core components required.||Negative press in industry media
|-
|5||Service will be mothballed.||Complete control over the users device||Violation of Privacy Policy with Production Data||Extreme cost for remediation (e.g. MoCo/Mofo can't afford to)||Complete redesign and rewrite||Negative press in mainstream media
|}

=== Risk Rating Methodologies Used Elsewhere ===

'''[http://msdn.microsoft.com/en-us/library/aa302419.aspx#c03618429_011 DREAD] from Microsoft''' ([http://blogs.msdn.com/b/david_leblanc/archive/2007/08/13/dreadful.aspx blog post])
Uses five categories:
* Damage - how bad would an attack be?
* Reproducibility - how easy it is to reproduce the attack?
* Exploitability - how much work is it to launch the attack?
* Affected users - how many people will be impacted?
* Discoverability - how easy it is to discover the threat?

When a given threat is assessed using DREAD, each category is given a rating. For example, 3 for high, 2 for medium, 1 for low and 0 for none. The sum of all ratings for a given exploit can be used to prioritize among different exploits.

'''[https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology OWASP Risk Rating Methodology]'''
Similar to Yvan's in that it uses '''Risk = Likelihood * Impact''' but produces a rating from 0 to 9 (or three groups 1-3, 4-6, 7-9 which equate to Low, Medium, and High).

Security/Projects/Minion

2012-09-06T18:05:30Z

Mfuller: /* Configuration Abstraction */

<cite>
Minion is a security testing framework built by Mozilla to bridge the gap between developers and security testers. To do so, it enables developers to scan their projects using a friendly interface.
</cite>

NOTE - this project is at a ''very'' early stage in its development.

* Source code: https://github.com/ygjb/minion - public
* Task management: https://trello.com/b/DlVPzGaS - currently private, contact one of the Minion developers to get access
Developers:
* [[User:Psiinon|Psiinon]]
* TBA

==Initial Diagram==
[[File:Minon_diagram.png]]

==Components==
===Web Interface===
* Log in using Persona (BrowserID) (can be restricted by domain for use on central server by organizations)
* Menu -> New Scan, Running Scans, Completed Scans
** Future: Group Scans (member of groups, permissions, see other scans by group members/project)
* New Scan
** Basic: URL, Port
** Advanced: Login information, technologies used (customize scan such as SQLmap for SQL)
** Future: Scan type based on plugin (web app, client code, etc)

===Task Engine===
* Instance started when user clicks start scan
* Collects provided information
* Starts scan based on provided information
* Launches tools (Minions) and awaits responses

===Minions (Scanners)===
* Receive kickoff from task engine
* Scan target
* Send results back to task engine in necessary format (JSON)

===Target===
* Site hosted by developer
* Can be hosted or running locally

==Configuration Abstraction==
To pass data between components, a standard configuration and data scheme must be used. For Minion, we have decided to use JSON and a REST API as the format for passing data. For example, the user interface will collect the necessary options, then call the task engine and pass it a JSON string of those options. The task engine will read the options and use each installed tool's REST API to make requests to the tool (some tools may need different options than others). The tool will pass its results back to the task engine as a JSON string and the task engine will compile all returned results into a single JSON string which will be returned to the interface. The interface will deconstruct the string into human-readable results and display them on the results page.

===Basic Tool Requirements===
Each tool takes a number of base options as well as optional options that can improve the scan's accuracy or increase its functionality.

====Zed Attack Proxy====
Base options: URL

Optional: spider depth-level, CSRF tokens, authentication information, parameters to fuzz

====Garmr====
Base options: URL

Optional: parameters to test

Note: most options with Garmr involve output, which should be handled without interaction from the user.

====Skipfish====
Base options: URL

Optional: authentication credentials, cookie values, non-standard header information, scan time limit (see http://code.google.com/p/skipfish/wiki/SkipfishDoc for a full list)

Note: Skipfish has a lot of additional options that include domains to exclude in crawling, domains to ignore in testing, wordlist generation, folder output, etc. To make it as easy to use as possible, the Skipfish plugin should include defaults for all of these options so that the user will never need to worry about the options.

Security/Projects/Minion

2012-09-06T17:37:39Z

Mfuller: /* Basic Tool Requirements */

<cite>
Minion is a security testing framework built by Mozilla to bridge the gap between developers and security testers. To do so, it enables developers to scan their projects using a friendly interface.
</cite>

NOTE - this project is at a ''very'' early stage in its development.

* Source code: https://github.com/ygjb/minion - public
* Task management: https://trello.com/b/DlVPzGaS - currently private, contact one of the Minion developers to get access
Developers:
* [[User:Psiinon|Psiinon]]
* TBA

==Initial Diagram==
[[File:Minon_diagram.png]]

==Components==
===Web Interface===
* Log in using Persona (BrowserID) (can be restricted by domain for use on central server by organizations)
* Menu -> New Scan, Running Scans, Completed Scans
** Future: Group Scans (member of groups, permissions, see other scans by group members/project)
* New Scan
** Basic: URL, Port
** Advanced: Login information, technologies used (customize scan such as SQLmap for SQL)
** Future: Scan type based on plugin (web app, client code, etc)

===Task Engine===
* Instance started when user clicks start scan
* Collects provided information
* Starts scan based on provided information
* Launches tools (Minions) and awaits responses

===Minions (Scanners)===
* Receive kickoff from task engine
* Scan target
* Send results back to task engine in necessary format (JSON)

===Target===
* Site hosted by developer
* Can be hosted or running locally

==Configuration Abstraction==
To pass data between components, a standard configuration and data scheme must be used. For Minion, we have decided to use JSON as the format for passing data. For example, the user interface will collect the necessary options, then call the task engine and pass it a JSON string of those options. The task engine will read the options, split them into new JSON strings as necessary to send to each installed tool (some tools may need different options than others). The tool will pass its results back to the task engine as a JSON string and the task engine will compile all returned results into a single JSON string which will be returned to the interface. The interface will deconstruct the string into human-readable results and display them on the results page.

===Basic Tool Requirements===
Each tool takes a number of base options as well as optional options that can improve the scan's accuracy or increase its functionality.

====Zed Attack Proxy====
Base options: URL

Optional: spider depth-level, CSRF tokens, authentication information, parameters to fuzz

====Garmr====
Base options: URL

Optional: parameters to test

Note: most options with Garmr involve output, which should be handled without interaction from the user.

====Skipfish====
Base options: URL

Optional: authentication credentials, cookie values, non-standard header information, scan time limit (see http://code.google.com/p/skipfish/wiki/SkipfishDoc for a full list)

Note: Skipfish has a lot of additional options that include domains to exclude in crawling, domains to ignore in testing, wordlist generation, folder output, etc. To make it as easy to use as possible, the Skipfish plugin should include defaults for all of these options so that the user will never need to worry about the options.

Security/Projects/Minion

2012-09-06T17:37:02Z

Mfuller:

<cite>
Minion is a security testing framework built by Mozilla to bridge the gap between developers and security testers. To do so, it enables developers to scan their projects using a friendly interface.
</cite>

NOTE - this project is at a ''very'' early stage in its development.

* Source code: https://github.com/ygjb/minion - public
* Task management: https://trello.com/b/DlVPzGaS - currently private, contact one of the Minion developers to get access
Developers:
* [[User:Psiinon|Psiinon]]
* TBA

==Initial Diagram==
[[File:Minon_diagram.png]]

==Components==
===Web Interface===
* Log in using Persona (BrowserID) (can be restricted by domain for use on central server by organizations)
* Menu -> New Scan, Running Scans, Completed Scans
** Future: Group Scans (member of groups, permissions, see other scans by group members/project)
* New Scan
** Basic: URL, Port
** Advanced: Login information, technologies used (customize scan such as SQLmap for SQL)
** Future: Scan type based on plugin (web app, client code, etc)

===Task Engine===
* Instance started when user clicks start scan
* Collects provided information
* Starts scan based on provided information
* Launches tools (Minions) and awaits responses

===Minions (Scanners)===
* Receive kickoff from task engine
* Scan target
* Send results back to task engine in necessary format (JSON)

===Target===
* Site hosted by developer
* Can be hosted or running locally

==Configuration Abstraction==
To pass data between components, a standard configuration and data scheme must be used. For Minion, we have decided to use JSON as the format for passing data. For example, the user interface will collect the necessary options, then call the task engine and pass it a JSON string of those options. The task engine will read the options, split them into new JSON strings as necessary to send to each installed tool (some tools may need different options than others). The tool will pass its results back to the task engine as a JSON string and the task engine will compile all returned results into a single JSON string which will be returned to the interface. The interface will deconstruct the string into human-readable results and display them on the results page.

===Basic Tool Requirements===
Each tool takes a number of base options as well as optional options that can improve the scan's accuracy or increase its functionality.

====Zed Attack Proxy====
Base options: URL
Optional: spider depth-level, CSRF tokens, authentication information, parameters to fuzz

====Garmr====
Base options: URL
Optional: parameters to test
Note: most options with Garmr involve output, which should be handled without interaction from the user.

====Skipfish====
Base options: URL
Optional: authentication credentials, cookie values, non-standard header information, scan time limit (see http://code.google.com/p/skipfish/wiki/SkipfishDoc for a full list)
Note: Skipfish has a lot of additional options that include domains to exclude in crawling, domains to ignore in testing, wordlist generation, folder output, etc. To make it as easy to use as possible, the Skipfish plugin should include defaults for all of these options so that the user will never need to worry about the options.

Security/Projects/Minion

2012-08-29T21:22:01Z

Mfuller:

Security/Projects/Minion

2012-08-29T18:19:12Z

Mfuller:

File:Minon diagram.png

2012-08-29T18:18:26Z

Mfuller: Initial minion diagram

Initial minion diagram

Security/Projects/Minion

2012-08-29T15:26:39Z

Mfuller: Created page with "Placeholder page for Minion Project"

Placeholder page for Minion Project

WebAppSec/Filing In Bugzilla

2012-08-21T21:31:52Z

Mfuller: /* Optional Information */

This page explains, step-by-step, how to file a web security bug in Bugzilla using all the proper flags, keywords, whitboard tags, etc.

==Filing a Web Security Bug in Bugzilla==
===Selecting a Product and Component===
Begin by opening a new bug: https://bugzilla.mozilla.org/enter_bug.cgi

Type the affected hostname (e.g. "blog.mozilla.com") into the search box at the top of the page. The box will autocomplete your search with available options. If no result is found, you can search manually or file a bug under "Other."

To file manually, most website bugs will be filed in "Other Products" at the bottom of the page.

[[Image:BugzillaProcess0.png]]

The "Websites" section under "Other" contains most sites.

[[Image:BugzillaProcess1.png|700px]]

Next, select a component from the list. If the website with the vulnerability is not listed, select "Other."

[[Image:BugzillaProcess2.png|800px]]

===Provide a Summary===
Provide a descriptive summary of the bug. Sample titles include:
* XSS in getpersonas.mozilla.com ID Parameter
* mozilla.org CSRF vulnerability on Profile Page

Check the list of similar bugs that are found and try to make sure the bug has not yet been reported.

===Enter a Description===
Provide as much information about the bug as possible. This should include:
* A full URL of the vulnerable page
* Any accounts or user profiles used to test the vulnerability
* The vulnerable parameter if applicable
* Tests you have used to verify the issue
* The payload used if applicable
** For example, if the issue is XSS, please provide the exact XSS payload you used
* What the expected behavior is
* Any other information that could be useful in reproducing the bug

===Setting Security Flags===
Security flags are used to keep sensitive bugs hidden until the problem is resolved. This is done to protect our websites and users from attack during the time it takes to fix an issue. Marking a bug as security sensitive will still allow you to see updates to the bug, it will simply hide it from the public.

For website vulnerabilities, please check the following box (note that you may need to click "Show Advanced Fields" to see it):
* Many users could be harmed by this security problem: it should be kept hidden from the public until it is resolved.

If you are in the Websites group for Mozilla, you may also see another checkbox which can be selected:
* Security-Sensitive Websites Bug

Checking one of these boxes is sufficient to hide the security issue.

===Optional Information===
The following options will further help the security team respond to your bug, but are not required for a basic bug report.

====Additional Information====
For the "Version" drop-down, leave "unspecified" selected unless the vulnerability affects a specific version of Firefox. Change "Operating System" to "All" unless the vulnerability affects only one version of an OS. The same is true for "Hardware."

====Selecting a Severity====
For the "Severity" drop-down box, use the ratings listed on the WebAppSec Wiki here to determine a rating: [https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings#Rating WebAppSec Wiki]

Typically, XSS uses "Critical" and vulnerabilities that expose information are "Major." Any SQL injection attacks are considered a "Blocker." Please use the ratings list to determine the exact rating for the vulnerability.

====Attachments====
Please include attachments such as:
* Screenshots of the issue (such as an XSS alert box executing)
* A POC script
* A demo video

Please do not include videos or attachments that explain the issue generically (for example, a YouTube video explaining what XSS is).

====Adding Keywords====
Keywords assist the security team in filtering and searching for bugs. Properly supplying keywords will help a bug receive the correct attention. A full list of keywords is available here: https://bugzilla-stage.mozilla.org/describekeywords.cgi but the only ones applicable to website security bugs are:
* sec-critical
* sec-high
* sec-moderate
* sec-low
* sec-other

Keywords also help categorize the kind of bug (i.e. XSS, CSRF, etc). Please use the list here to determine the appropriate keywords: https://wiki.mozilla.org/Security_Severity_Ratings

====Whiteboard Tags====
Whiteboard tags are not typically used with web security vulnerabilities. Please use keywords as described above.

====Additional Options====
A URL may be provided that links to the vulnerable page.

The "Blocks" and "Depends On" options may be set if the submitted bug either blocks another bug with a known Bugzilla bug number or relies on another bug before it can be fixed. In the case of web security bugs, these options are often not set unless the bug is discovered during a security review, in which case it blocks the original review request bug.

===What Happens Next?===
After the bug is reported, an email alert is sent to all applicable members of the security team who have subscribed to alerts from Bugzilla. Once this email is sent, a member of the team will take a look at the bug and attempt to confirm whether it is a security risk. We may ask for more information if we are not able to replicate the issue.

Once the vulnerability is confirmed, the bug's status is changed from "Unconfirmed" to "New." We will then attempt to locate a developer who has worked on the project and ask him or her to assist us in fixing the bug. Depending on the complexity, you may get multiple emails from Bugzilla as the security team member and the developer attempt to fix the issue.

Once a fix has been developed, it often needs to progress through a development and stage environment before being pushed to production. Once the fix is running on the production environment and the vulnerability is confirmed to no longer exist, the bug will be marked Resolved -> Fixed.

This process may take anywhere from a day to a few weeks to complete. During this time, please do not file duplicate bugs as it only slows down the progress of fixing the first. If you feel a bug is not being given the attention it deserves, feel free to leave a comment on the bug asking for an update. This will re-email everyone involved and can remind us of a bug we may have forgotten.

Security/ReviewProcess

2012-08-21T18:30:33Z

Mfuller: /* Detailed Testing Procedures */

This page contains draft documentation of our security review processes.

= Security Review Processes =
==Web Application Review Process==
Web applications vary dramatically in design and functionality making it difficult to create a single use-case checklist for security reviews. However, most applications undergo the following checks during the security review process.

===General Web Application Review Process===
Many of these questions are taken from the secure coding guidelines page: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines

====Access Information====
* How is the application accessed?
* Is the application internal or publicly available?
* If it is internal, what mechanism prevents non-members from accessing it?
* Are there links to user-only resources displayed to non-users?
* Are login pages secured with SSL over HTTPS?
* If HTTPS is used, is Strict Transport Security set?

====Infrastructure and Backends====
* What languages do the applications use?
* What database language is used if applicable?
* Are the running versions up to date?
* What server is it running on?

====Accounts and Passwords====
* If the mechanism to prevent general access is a password, how is the signup process handled?
* How is account information stored?
* Are passwords properly stored within databases if applicable?
* Is a password policy in place?
* Are accounts locked-out after a number of invalid logins?
* Are passwords 8 characters or greater?
* Do passwords use both numbers and letters (and possibly symbols)?
* Is there a blacklist of common passwords?
* Do passwords expire after X days and require a reset?
* Are invalid logins logged?
* Is there a lockout after X invalid attempts?
* Is the error message for lockout generic (does not include if user/pass is valid)?
* How are password resets handled (i.e. email, security question, etc.)?
* Do emails sent after signup/reset contain a session link? (should not)
* Do email verification codes expire after one use or 8 hours?
* Is password reuse limited/prevented?

====Session Management====
* How long are session cookies stored?
* Are session tokens 128-bit or greater?
* Is session ID token creation handled by the server (or cryptographically if locally)?
* Do authenticated sessions timeout after 15 minutes?
* Is the Secure Flag enabled for all set cookies?
* Is the HTTP-Only flag used to disable malicious script access to the session ID?
* Are new session ids created on login?
* On logout, are session ids invalidated?

====Third-Party Resources====
* Are third-party resources used (i.e. JavaScript libraries, images, CSS, etc.)?
* Can those resources be trusted / are they from reputable sources?
* Is there a chance the resource could be compromised?
* Is it possible to host the resources locally to mitigate risks?
* Is a third-party responsible for storage of user data?
* Does the application connect with services like Facebook, Twitter, etc?

====Data Handling====
* What kind of data is transferred between the user and the application?
* Is this data generated by the user or generated automatically?
* Can the data be trusted?
* How is the data sent to the application (i.e. JSON format, plain-text, GET/POST, etc.)?
* How is the data handled by the server/application?
* Can the data be manipulated in transit?
* What happens if the data is altered?
* What is done with the data once it is received (i.e. stored in a database, displayed to users)?
* Is any data storage done via cookies? If so, what kind of data is stored via this method?

====Uploaded Data====
* Can the user upload data to the application?
* Are extensions, file size, file type (not only based on extension), etc. checked?
* Are files renamed upon upload?
* Is the correct content-type used?

====Data Sensitivity====
* What kind of data is being stored and/or manipulated by the application?
* Does this data need to be encrypted in transit? In storage?
* What is the impact if this data is lost/stolen?
* Is secure/sensitive data sent over SSL?

====Application Administration====
* Is there an administration console?
* Can it be accessed publicly?
* How is it secured if so?
* Are correct methods used to prevent admin actions from being performed outside of the admin console (i.e. using CSRF tokens)?
* Are there any configuration pages that should not be made public?

====Security Coding Flaws====
* Have all user inputs been sanitized?
* Is a maximum size for data (input or uploads) defined?
* Do all URL variables pass through sanitization?
* Is data from databases escaped properly?
* Are CSRF tokens used to prevent POSTs from outside websites?
* If a database is used, are protections against SQL injection in place?
* Is validation done on the server side (not just client-side)?
* Is output encoded in addition to sanitization of input?
* Does the user ever send data to the OS level?
* Are x-frame options sent to “deny” or “sameorigin”?
* Is debug mode disabled?

===Additional Resources===
Template for the above checks: https://docs.google.com/document/d/1SAzDuMwKUNN4_gdotqcv0oeZwLngjXjNYuZ2HZZaXp4/edit

Also, please view the WebAppSec Wiki: https://wiki.mozilla.org/WebAppSec

==WordPress Plugin Review Process==
Before being installed, all WordPress plugins must be reviewed by the security team. These reviews are simpler than full site reviews and ensure that the plugin being installed does not compromise the security of the blog/site.

See the WebAppSec link for additional information about WordPress: https://wiki.mozilla.org/WebAppSec/Wordpress_Security_Review_Process

===Common Attack Vectors===
The most common WordPress security issues present in plugins are cross-site scripting vulnerabilities (both persistent and reflected). Other vulnerabilities to check for include privilege escalation, remote code execution, logic errors, and SQL injection.

===Review Process Overview===
A majority of the plugin review process involves manual inspection of the plugin and review of the plugin's code. The following steps outline a basic process followed when reviewing plugins.
* A test installation of WordPress is used (see Turnkey WordPress: http://www.turnkeylinux.org/wordpress)
** The WordPress version must match that of the blog on which the plugin will be installed.
* If the plugin is being installed on a high profile blog, a staging installation may already be available. It is best to test here to replicate the production environment as best as possible.
* The plugin to be tested is downloaded from WordPress using the most recent version available.
* Security testing is performed (see next section for detailed testing information).
* If any issues are detected, the developer is contacted and asked to release a fix.
* A blocking bug is created pertaining to the fix. If the developer does not respond within a reasonable time frame, our developers may fix the issue on a local installation.

===Detailed Testing Procedures===
* Determine the functionality of the plugin. Most plugins add a set of features to the admin page, but some are much more complex.
** Do the features allow non-admin users to add data or enter input on the site?
** Is that data treated as unsafe (i.e. not used directly in SQL statements or reflected back to other users or admins)?
** Does the plugin alter the login process, add additional users, or grant additional rights to non-admins?
** If a plugin modifies post text (such as creating links out of certain words), does it do the same for user-comments?
*** This is dangerous - a plugin such as this should only allow admins to enter data that will be handled.
* View the settings page for the plugin and test the inputs for cross-site scripting and SQL injection vulnerabilities.
** Note that some plugins enable the use of unfiltered HTML within the admin page. This behavior is allowed unless the plugin also exposes this functionality to non-admins.
** Ensure that unfiltered HTML is being used in expected places. For example, unfiltered HTML may be allowed when editing posts, but some input boxes can be XSS'ed with "/><script>alert(1);</script>. This breaks out of the settings input box and allows unfiltered code execution on the settings page.
* View the methods used to save settings. Some plugins use POST (desirable) and others use GET.
** Where GET is used, especially check all settings for potential XSS as an admin can be sent a link containing the XSS and it will be executed immediately (or following login).
** If POST is used, check for potential CSRF issues. A nonce should be used to protect the admin page from CSRF.
* View the code of the plugin itself (this can be done in WordPress by clicking Plugins > Editor and selecting the plugin).
** Check for all input accepted by the plugin ($_GET, $_REQUEST, $_POST).
** Fuzz all inputs for potential XSS and SQL injection vulnerabilities.

Do the varied nature of plugins, it is impossible to have a "one stop" checklist. Each plugin must be manually checked and the testing procedures altered depending on the functionality. The above process is a general guideline and does not apply to every plugin.

= Security Review Documentation =
== Structure of a Security Review ==

This document covers five distinct activities and the documentation they produce when a security review is performed. Note that this guidance is prescriptive in that each component of a security review document should be produced, or a statement explaining why it wasn't should be included.

The goal of this document is to ensure that the Security Assurance team has a consistent format for the documentation we produce without enforcing a strict structure on how security review and testing is performed.

=== Architecture Diagram ===

An architecture diagram illustrates how the various components of the service communicate with one another.

The goal of the architecture diagram is to give the audience a high-level visual representation of how the different components of a system will interact together.

An example of this is the diagram below, which is from the old Mozilla F1 service.

[https://wiki.mozilla.org/images/thumb/7/78/F1design.png/392px-F1design.png Mozilla F1 Architecture Diagram]

The F1 service had multiple components:
* a Firefox Add-on that hosted a pane loaded from the Mozilla F1 service that facilitated posting ('sharing') content across multiple services
* a back-end that abstracted the 'sharing' process such that a core set of common functions to facilitate easy incorporation of addition services without client updates

Rather than providing a detailed assessment of how messages are passed between the various components, this diagram illustrates how the different components interact with one another, but not details about the interactions, or what data is shared between them.

The goal of this diagram is to provide a concise overview of the system that provides a frame of reference when someone new to the system is reviewing supporting documentation or code.

==== Key Attributes ====
* Clarity; brief descriptions of which components are communicating
* Illustrates the boundaries between different services

==== Additional Examples ====
* [https://people.mozilla.com/~yboily/identity/assets/images-1/s31.b.jpeg BrowserID Protocol High Level]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg Apps MarketPlace] TODO - Replace Me With A Simple Diagram!

=== Detailed Application Diagram ===
A Detailed Application Diagram is essentially a Data-flow diagram; a data flow diagram enumerates each application or service that is a component of a system, and illustrates each of the paths data can flow through.

[https://wiki.mozilla.org/images/2/22/BrowserID-Threat-Model.png BrowserID Detailed Diagram]

Note that a data-flow diagram is only one example of how this information. The goal is to effectively communicate to the audience how data moves through the system, where different operations are performed, and if detailed enough, how different roles within the system can access different operations.

When designing the detailed application diagram it can be useful to assemble a list of each of the subjects in a system.

TODO - add references for subject/object/operations in relation to access control models.

==== Key Attributes ====
* Clarity; labels for objects are brief, and contain clear references that can be used to cross-reference other documentation
* Detailed; ensure that all roles and operations are clearly presented

==== Additional Examples====
* [https://wiki.mozilla.org/images/b/bf/MozillaF1-Diagram.png Mozilla F1 Detailed Application Diagram]
* [https://wiki.mozilla.org/images/e/ee/BrowserID-Protocol.png BrowserID Protocol]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg AppStore Threat Model]

=== Data-flow Enumeration ===

Data-flow enumeration is an important supplement to the Detailed Application Diagram; it acts as a reference for someone reading the diagram to look up the nature of what information is associated with a call or request between two components.

At a minimum, the flow enumeration should be a table indicating an identifier, subject, object, and the operation being performed.

In the example below, an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID provisioning enumeration], the subject, object, and operation are labelled origin, destination, and description, respectively.

{| border="1" class="fullwidth-table"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Origin'''
| align="center" style="background:#f0f0f0;"|'''Destination'''
| align="center" style="background:#f0f0f0;"|'''Description'''
|-
|1.A||Relying Party||Implementation Provider|| An interaction with the Relying party invokes the Implementation Provider (IP).
|-
|1.B||Implementation Provider||Identity Authority||The IP either has an expired certificate, or no certificate, and directs the client to an Identity Authority landing page for authentication. This authentication process is out of scope of the protocol, and implementation dependent.
|-
|1.C||Identity Authority||Identity Authority||Code from the IP landing page invokes genKeyPair() to generate a keypair.
|-
|1.D||Identity Authority||Implementation Provider||The IP saves the keypair in the client
|}

In addition to including the subject, object, operation columns, it can be helpful to include an explicit list of fields which are considered sensitive.

==== Additional Examples ====
* [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID Data-flow Enumeration]

=== Threat Analysis ===

When performing a security review of an application one of the most important components is a threat analysis. There is a great deal of documentation on how to perform threat analysis, and a number of different techniques that can be used:

* [https://www.owasp.org/index.php/Threat_Risk_Modeling OWASP Threat Risk Modelling]
* [http://msdn.microsoft.com/en-us/security/aa570413 Microsoft Application Threat Modelling]
* [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf NIST Risk Management Guide][pdf]

For the purposes of a Mozilla Security Review, the means by which someone identifies the threats and risks associated with an application is important, but not specified. If you have questions about how to perform this type of analysis, please contact a member of our team!

The resulting threat analysis should be formatted in a clear format, including the following details:

* ID - a identifier for the threat
* Title - a concise description of the threat
* Threat - a description of the threat
* Mitigations - a recommendation for a control that can be implemented [1]
* Threat Agent - a list of the potential actors considered that would exploit a vulnerability.
* Notes - Related comments that contribute to the analysis, but don't belong in other columns
* Rating - A qualitative scoring for a vulnerability in the context of this application [2]
* Impact - A qualitative score representing the impact should a vulnerability be exploited
* Likelihood - A qualitative score representing the likelihood of a vulnerability being exploited. [3]

See [https://wiki.mozilla.org/Security/RiskRatings Risk Ratings] for details of how to calculate the qualitative scores.

TODO - Glossary Threat, Threat Agent, Vulnerability, Exploit
[1] In the case of a threat analysis that contains multiple threats that can be resolved by one or more different controls it may be beneficial to include a separate control table, and list references to controls in that table instead.
[2] The rating is calculated by multiplying the impact by the likelihood. This is a naive method, but it's what we have!
[3] In the case where different threat agents have different likelihoods, list the likelihoods highest to lowest, in the same order as the threat agents.

Below is an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model BrowserID Threat Analysis]:

{| border="1" class="fullwidth-table sortable"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Title'''
| align="center" style="background:#f0f0f0;"|'''Threat'''
| align="center" style="background:#f0f0f0;"|'''Proposed Mitigations'''
| align="center" style="background:#f0f0f0;"|'''Threat Agent'''
| align="center" style="background:#f0f0f0;"|'''Rating'''
| align="center" style="background:#f0f0f0;"|'''Likelihood'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
| align="center" style="background:#f0f0f0;"|'''Impact'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
|-
| 1||SIA may introduce compliance issues||Operating a Secondary Identity Authority may induce compliance requirements with regards to logging user information||Part of the goal of BrowserID is to have Primary Identity Authorities take on this risk as part of their other operations. This can be somewhat mitigated by eliminating support for the webfinger verification process.||Governments, Lawyers||12||3||Governments and other legal actors have the ability to request information from us, either through subpoenas, NSLs, etc. While we hold information that can link user identities to services this information will be a source of risk.||4 – Reputation||Although we are required to comply, and Mozilla would fight such a request to the degree permitted, we would still receive negative press.
|-
| 2||Webfinger Information Leak||Use of the webfinger service for verification discloses each authentication attempt from the Relying Party to the Identity Authority||Implement verification using certificates||Malicious Identity Authority||25||5||This information disclosure is a part of the protocol.||5 – Privacy||This is probably a clear violation of our privacy policies.
|-
| 3||Chrome Code Injection||Attacker controlled parameters could permit injection of script into browser chrome.||Ensure that any data controlled by the user or relying party is emitted using output encoding.||Malicious Relying Party, Malicious User, Malicious Identity Authority||4||1||Code review and testing should prevent this occuring. The technical complexity of this attack is higher than a vanilla XSS.||4 – User||This gives an attacker the ability to execute code in the context of browser chrome.
|}

==== Additional Examples ====
* Mozilla F1 Threats [https://wiki.mozilla.org/Security/Reviews/F1#Threat_Model]
* BrowserID Threats [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model]

=== Security Testing ===

The security test plan is a brief explanation of security testing that should be performed, and should include an explanation of what tasks are to be performed, and the approximate amount of time spent performing those tasks.

WebAppSec/Filing In Bugzilla

2012-08-21T18:11:57Z

Mfuller:

This page explains, step-by-step, how to file a web security bug in Bugzilla using all the proper flags, keywords, whitboard tags, etc.

==Filing a Web Security Bug in Bugzilla==
===Selecting a Product and Component===
Begin by opening a new bug: https://bugzilla.mozilla.org/enter_bug.cgi

Type the affected hostname (e.g. "blog.mozilla.com") into the search box at the top of the page. The box will autocomplete your search with available options. If no result is found, you can search manually or file a bug under "Other."

To file manually, most website bugs will be filed in "Other Products" at the bottom of the page.

[[Image:BugzillaProcess0.png]]

The "Websites" section under "Other" contains most sites.

[[Image:BugzillaProcess1.png|700px]]

Next, select a component from the list. If the website with the vulnerability is not listed, select "Other."

[[Image:BugzillaProcess2.png|800px]]

===Provide a Summary===
Provide a descriptive summary of the bug. Sample titles include:
* XSS in getpersonas.mozilla.com ID Parameter
* mozilla.org CSRF vulnerability on Profile Page

Check the list of similar bugs that are found and try to make sure the bug has not yet been reported.

===Enter a Description===
Provide as much information about the bug as possible. This should include:
* A full URL of the vulnerable page
* Any accounts or user profiles used to test the vulnerability
* The vulnerable parameter if applicable
* Tests you have used to verify the issue
* The payload used if applicable
** For example, if the issue is XSS, please provide the exact XSS payload you used
* What the expected behavior is
* Any other information that could be useful in reproducing the bug

===Setting Security Flags===
Security flags are used to keep sensitive bugs hidden until the problem is resolved. This is done to protect our websites and users from attack during the time it takes to fix an issue. Marking a bug as security sensitive will still allow you to see updates to the bug, it will simply hide it from the public.

For website vulnerabilities, please check the following box (note that you may need to click "Show Advanced Fields" to see it):
* Many users could be harmed by this security problem: it should be kept hidden from the public until it is resolved.

If you are in the Websites group for Mozilla, you may also see another checkbox which can be selected:
* Security-Sensitive Websites Bug

Checking one of these boxes is sufficient to hide the security issue.

===Optional Information===
The following options will further help the security team respond to your bug, but are not required for a basic bug report.

====Additional Information====
For the "Version" drop-down, leave "unspecified" selected unless the vulnerability affects a specific version of Firefox. Change "Operating System" to "All" unless the vulnerability affects only one version of an OS. The same is true for "Hardware."

====Selecting a Severity====
For the "Severity" drop-down box, use the ratings listed on the WebAppSec Wiki here to determine a rating: [https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings#Rating WebAppSec Wiki]

Typically, XSS uses "Critical" and vulnerabilities that expose information are "Major." Any SQL injection attacks are considered a "Blocker." Please use the ratings list to determine the exact rating for the vulnerability.

====Attachments====
Please include attachments such as:
* Screenshots of the issue (such as an XSS alert box executing)
* A POC script
* A demo video

Please do not include videos or attachments that explain the issue generically (for example, a YouTube video explaining what XSS is).

====Adding Keywords====
Keywords assist the security team in filtering and searching for bugs. Properly supplying keywords will help a bug receive the correct attention. A full list of keywords is available here: https://bugzilla-stage.mozilla.org/describekeywords.cgi but the only ones applicable to website security bugs are:
* sec-critical
* sec-high
* sec-moderate
* sec-low
* sec-other

====Whiteboard Tags====
As with keywords, whiteboard tags assist the security team is sorting and categorizing security bugs. This page lists the available whiteboard tags: https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings

Be sure to include both the severity tag as well as the infrasec tag.

As an example, a reflected XSS vulnerability would have whiteboard tags: [ws:high][infrasec:xss]

====Additional Options====
A URL may be provided that links to the vulnerable page.

The "Blocks" and "Depends On" options may be set if the submitted bug either blocks another bug with a known Bugzilla bug number or relies on another bug before it can be fixed. In the case of web security bugs, these options are often not set unless the bug is discovered during a security review, in which case it blocks the original review request bug.

===What Happens Next?===
After the bug is reported, an email alert is sent to all applicable members of the security team who have subscribed to alerts from Bugzilla. Once this email is sent, a member of the team will take a look at the bug and attempt to confirm whether it is a security risk. We may ask for more information if we are not able to replicate the issue.

Once the vulnerability is confirmed, the bug's status is changed from "Unconfirmed" to "New." We will then attempt to locate a developer who has worked on the project and ask him or her to assist us in fixing the bug. Depending on the complexity, you may get multiple emails from Bugzilla as the security team member and the developer attempt to fix the issue.

Once a fix has been developed, it often needs to progress through a development and stage environment before being pushed to production. Once the fix is running on the production environment and the vulnerability is confirmed to no longer exist, the bug will be marked Resolved -> Fixed.

This process may take anywhere from a day to a few weeks to complete. During this time, please do not file duplicate bugs as it only slows down the progress of fixing the first. If you feel a bug is not being given the attention it deserves, feel free to leave a comment on the bug asking for an update. This will re-email everyone involved and can remind us of a bug we may have forgotten.

WebAppSec/Filing In Bugzilla

2012-08-20T20:49:06Z

Mfuller:

File:BugzillaProcess2.png

2012-08-20T19:59:51Z

Mfuller:

File:BugzillaProcess0.png

2012-08-20T19:53:37Z

Mfuller: Process for submitting websites security bugs in bugzilla

Process for submitting websites security bugs in bugzilla

File:BugzillaProcess1.png

2012-08-20T19:49:56Z

Mfuller: The bugzilla process for website security bugs

The bugzilla process for website security bugs

WebAppSec

2012-08-20T19:39:13Z

Mfuller: /* Mozilla Web Application Security */

= Mozilla Web Application Security =

Welcome to the home page for Mozilla Web Application Security. This page will provide security information related to Mozilla hosted web applications and web services.

== Secure Development Guidance ==

[[WebAppSec/Web_App_Severity_Ratings|Web Application Security Severity Ratings]]

[[WebAppSec/Secure_Coding_Guidelines|Secure Coding Guidelines]]

[[WebAppSec/Secure_Coding_QA_Checklist|Secure Coding QA Checklist]]

== Request a Security Review ==
Are you releasing a Mozilla web application or service? If so, the Mozilla infrasec team can review the code and running application for security flaws.

[[WebAppSec/Security_Review_Request|Security Review Request]]

[[WebAppSec/Wordpress_Security_Review_Process|Wordpress Theme or Plugin - Security Install Process]]

==Filing a Web Security Bug==
For instructions regarding the use of Bugzilla to file a web security bug, visit: [[WebAppSec/Filing_In_Bugzilla|Filing a Web Security Bug in Bugzilla]]

== Presentations ==
Infrastructure security will be presenting on various security topics on a regular basis. These courses are free and open to anyone that would like to attend. For those that are remote, please join us on air.mozilla.org to remotely watch the presentation.

===Schedule-2012===

===Schedule-2011-Archive===

===='''April 23, 2011 - Stanford Open Source Bootcamp'''====
* Topic: Securing Web Applications through Hands On Security Hacking
* Slides: [http://people.mozilla.org/~mcoates/WebAppSec-Training.html Securing Web Applications]

===='''[https://wiki.mozilla.org/WebAppSec/Presentations/2011-07-14-MobileHacking July 14, 2011 - Mobile Hacking]'''====
* Topic: Blake Turrentine presents Mobile Hacking courseware for BlackHat 2011
* Time: 6pm-9:30pm Pacific
* Location: Mountain View (10 Forward) (Sorry, no streaming)
* Remote Participation: No, lab element requires in-person attendance
* Limited Space - [https://wiki.mozilla.org/WebAppSec/Presentations/2011-07-14-MobileHacking#RSVP RSVP Required]
===='''July 20, 2011 - Hands-On Hacking Brownbag - Cross Site Scripting''' ====
* Topic: Cross Site Scripting
* Time: 12pm-1pm Pacific
* Location: Mountain View (10 Forward)
* Remote Participation: Yes, streaming via air.mozilla.org
* '''''Important''''' Lab Setup - Please setup your VM test instance prior to the session - [http://people.mozilla.org/~mcoates/WebSecurityLab.html#installation instructions]
* 10 minute online video - [http://www.youtube.com/watch?v=_Z9RQSnf8-g&feature=channel_video_title Cross Site Scripting]
* Archived [http://www.slideshare.net/michael_coates/cross-site-scripting-mozilla-security-learning-center Slides]

===='''August 16, 2011 - Hands-On Hacking Brownbag - SQL Injection'''====
* Topic: SQL Injection
* Time: 12pm-1pm Pacific
* Location: Mountain View (10 Forward)
* Remote Participation: Yes, streaming via [http://air.mozilla.org air.mozilla.org]
* Lab Setup - Please setup your VM test instance prior to the session - [http://people.mozilla.org/~mcoates/WebSecurityLab.html instructions]
* 10 minute online video - [http://www.youtube.com/watch?v=pypTYPaU7mM&feature=channel_video_title Injection Attacks]
* Archived [http://www.slideshare.net/michael_coates/sql-injection-mozilla-security-learning-center Slides]

===='''August 25, 2011 - OWASP Bay Area Chapter Meeting '''====
* Topic: Application Security Topics
** 6:00 PM - 6:30 PM .............Check-in, registration, networking
** 6:30 PM – 6:35 PM ........... Welcome Remarks/Agenda - Mandeep Khera
** 6:35 PM - 7:45 PM ............ Enabling Browser Security in Web Applications- Michael Coates, Mozilla
** 7:45 PM – 8:30 PM…......... Blackhat spam SEO - Julien Sobrier, Zscaler
* Time: 6pm-9:30pm Pacific
* Location: Mountain View (10 Forward)
* Remote Participation: Yes, streaming via [http://air.mozilla.org air.mozilla.org]
* RSVP Required (for in person) [http://www.regonline.com/owaspsiliconvalleychaptermeeting RSVP Here]

===='''September 21, 2011 - CEF Logging for Attack Aware Applications'''====
* Topic: Implementing CEF logging to improve the security of web based applications
* Time: 12pm-1pm Pacific
* Location: Mountain View (10 Forward)
* Remote Participation: Yes, streaming via [http://air.mozilla.org air.mozilla.org]
* Archived Video , Slides - Will be available after the session

===='''December 5, 2011 - Cross-Site Request Forgery and other cross domain technologies'''====
* Topic: Dealing with CSRF, the talk will also cover Cross-Origin Resource Sharing and the postMessage API
* Time: 12pm-1pm Pacific
* Location: Mountain View (10 Forward)
* Remote Participation: Yes, streaming via [http://air.mozilla.org air.mozilla.org]
* Archived Video , Slides - Will be available after the session

===='''December 14, 2011 - What You See and What You Get - An Attacker's perspective'''====
* Topic: The talk covers how an attacker views a software system, how that differs from more common perspectives and what that teaches us about how to make secure products
* Time: 5-6pm GMT
* Location: Adsetts Learning Center (room 6619), Sheffield Hallam University, UK
* Remote Participation: No
* Archived Video - to be made available soon

====Future Topics====
* Future topics: Content Security Policy, Strict Transport Security, Clickjacking & X-Frame-Options
* Hands-On Hacking Classes Planned For Each Month
* Submit an idea for a topic or brownbag to webappsec@mozilla.org

== Security Learning Materials ==
=== Online Videos ===
* [http://www.youtube.com/user/AppsecTutorialSeries 10 Minute Security Training Videos] (More to come)
** [http://www.youtube.com/watch?v=CDbWvEwBBxo Application Security Basics]
** [http://www.youtube.com/watch?v=pypTYPaU7mM&feature=related Injection Attacks]
** [http://www.youtube.com/watch?v=_Z9RQSnf8-g&feature=channel_video_title Cross Site Scripting]
** Additional videos under development
=== Security Presentations ===
* [http://www.slideshare.net/michael_coates/cross-site-scripting-mozilla-security-learning-center Cross Site Scripting Basics]
* [http://www.slideshare.net/michael_coates/sql-injection-mozilla-security-learning-center SQL Injection Basics]
=== Security Guides ===
* [https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheat Sheet]
* [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat Sheet]
=== Good Reads===
* [https://www.owasp.org/index.php/Top_10_2010 OWASP Top 10 Application Security Risks]

== Mozilla WebAppSec Mailing List ==
Interested in discussing web application security concerns and the impact on Mozilla web applications? Then this is the list for you. Please note, this is a public list and is not the appropriate channel to discuss open security vulnerabilities (please file a bug in bugzilla).

webappsec@mozilla.org

https://mail.mozilla.org/listinfo/webappsec

Infrastructure Security Blog - http://blog.mozilla.com/webappsec/

WebAppSec/Filing In Bugzilla

2012-08-20T19:37:15Z

Mfuller: Created page with "=Filing a Web Security Bug in Bugzilla= This page explains, step-by-step, how to file a web security bug in Bugzilla using all the proper flags, keywords, whitboard tags, etc."

=Filing a Web Security Bug in Bugzilla=
This page explains, step-by-step, how to file a web security bug in Bugzilla using all the proper flags, keywords, whitboard tags, etc.

WebAppSec/Wordpress Security Review Process

2012-08-20T19:28:11Z

Mfuller:

Note: This document is maintained on the internal mana website at the following [https://mana.mozilla.org/wiki/display/INFRASEC/Wordpress+Enhancements+Security+Review+Process link]. This is a copy of that document.

=Purpose=

Document the security and installation process for wordpress enhancements including themes and plugins

=Wordpress Theme or Plugin=

* A mozillian finds/creates a new theme or plugin
* The Mozillian files a [https://wiki.mozilla.org/WebAppSec/Security_Review_Request security review request] for review of the theme/plugin
* Infrasec reviews the theme for security issues
* IT installs the theme *after* Infrasec okays it
* IT activate the theme on blog.mozilla.com
* The Mozillian can then pick out the new theme if you're a blog admin

Note: Based on the quantity of security reviews and urgency of many projects please provide several weeks for this entire process.

=Why Require a Security Review?=

A surprising large number of cross site scripting vulnerabilities have been found within wordpress themes and plugins. This kind of vulnerability could allow an attacker to compromise users visiting the wordpress site, steal admin wordpress credentials or even rewrite the entire page.

=The Review Process=
Please view our Security Review Process Wiki page here: https://wiki.mozilla.org/Security/ReviewProcess#WordPress_Plugin_Review_Process

Security/ReviewProcess

2012-08-20T19:26:45Z

Mfuller: /* WordPress Plugin Review Process */

This page contains draft documentation of our security review processes.

= Security Review Processes =
==Web Application Review Process==
Web applications vary dramatically in design and functionality making it difficult to create a single use-case checklist for security reviews. However, most applications undergo the following checks during the security review process.

===General Web Application Review Process===
Many of these questions are taken from the secure coding guidelines page: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines

====Access Information====
* How is the application accessed?
* Is the application internal or publicly available?
* If it is internal, what mechanism prevents non-members from accessing it?
* Are there links to user-only resources displayed to non-users?
* Are login pages secured with SSL over HTTPS?
* If HTTPS is used, is Strict Transport Security set?

====Infrastructure and Backends====
* What languages do the applications use?
* What database language is used if applicable?
* Are the running versions up to date?
* What server is it running on?

====Accounts and Passwords====
* If the mechanism to prevent general access is a password, how is the signup process handled?
* How is account information stored?
* Are passwords properly stored within databases if applicable?
* Is a password policy in place?
* Are accounts locked-out after a number of invalid logins?
* Are passwords 8 characters or greater?
* Do passwords use both numbers and letters (and possibly symbols)?
* Is there a blacklist of common passwords?
* Do passwords expire after X days and require a reset?
* Are invalid logins logged?
* Is there a lockout after X invalid attempts?
* Is the error message for lockout generic (does not include if user/pass is valid)?
* How are password resets handled (i.e. email, security question, etc.)?
* Do emails sent after signup/reset contain a session link? (should not)
* Do email verification codes expire after one use or 8 hours?
* Is password reuse limited/prevented?

====Session Management====
* How long are session cookies stored?
* Are session tokens 128-bit or greater?
* Is session ID token creation handled by the server (or cryptographically if locally)?
* Do authenticated sessions timeout after 15 minutes?
* Is the Secure Flag enabled for all set cookies?
* Is the HTTP-Only flag used to disable malicious script access to the session ID?
* Are new session ids created on login?
* On logout, are session ids invalidated?

====Third-Party Resources====
* Are third-party resources used (i.e. JavaScript libraries, images, CSS, etc.)?
* Can those resources be trusted / are they from reputable sources?
* Is there a chance the resource could be compromised?
* Is it possible to host the resources locally to mitigate risks?
* Is a third-party responsible for storage of user data?
* Does the application connect with services like Facebook, Twitter, etc?

====Data Handling====
* What kind of data is transferred between the user and the application?
* Is this data generated by the user or generated automatically?
* Can the data be trusted?
* How is the data sent to the application (i.e. JSON format, plain-text, GET/POST, etc.)?
* How is the data handled by the server/application?
* Can the data be manipulated in transit?
* What happens if the data is altered?
* What is done with the data once it is received (i.e. stored in a database, displayed to users)?
* Is any data storage done via cookies? If so, what kind of data is stored via this method?

====Uploaded Data====
* Can the user upload data to the application?
* Are extensions, file size, file type (not only based on extension), etc. checked?
* Are files renamed upon upload?
* Is the correct content-type used?

====Data Sensitivity====
* What kind of data is being stored and/or manipulated by the application?
* Does this data need to be encrypted in transit? In storage?
* What is the impact if this data is lost/stolen?
* Is secure/sensitive data sent over SSL?

====Application Administration====
* Is there an administration console?
* Can it be accessed publicly?
* How is it secured if so?
* Are correct methods used to prevent admin actions from being performed outside of the admin console (i.e. using CSRF tokens)?
* Are there any configuration pages that should not be made public?

====Security Coding Flaws====
* Have all user inputs been sanitized?
* Is a maximum size for data (input or uploads) defined?
* Do all URL variables pass through sanitization?
* Is data from databases escaped properly?
* Are CSRF tokens used to prevent POSTs from outside websites?
* If a database is used, are protections against SQL injection in place?
* Is validation done on the server side (not just client-side)?
* Is output encoded in addition to sanitization of input?
* Does the user ever send data to the OS level?
* Are x-frame options sent to “deny” or “sameorigin”?
* Is debug mode disabled?

===Additional Resources===
Template for the above checks: https://docs.google.com/document/d/1SAzDuMwKUNN4_gdotqcv0oeZwLngjXjNYuZ2HZZaXp4/edit

Also, please view the WebAppSec Wiki: https://wiki.mozilla.org/WebAppSec

==WordPress Plugin Review Process==
Before being installed, all WordPress plugins must be reviewed by the security team. These reviews are simpler than full site reviews and ensure that the plugin being installed does not compromise the security of the blog/site.

See the WebAppSec link for additional information about WordPress: https://wiki.mozilla.org/WebAppSec/Wordpress_Security_Review_Process

===Common Attack Vectors===
The most common WordPress security issues present in plugins are cross-site scripting vulnerabilities (both persistent and reflected). Other vulnerabilities to check for include privilege escalation, remote code execution, logic errors, and SQL injection.

===Review Process Overview===
A majority of the plugin review process involves manual inspection of the plugin and review of the plugin's code. The following steps outline a basic process followed when reviewing plugins.
* A test installation of WordPress is used (see Turnkey WordPress: http://www.turnkeylinux.org/wordpress)
** The WordPress version must match that of the blog on which the plugin will be installed.
* If the plugin is being installed on a high profile blog, a staging installation may already be available. It is best to test here to replicate the production environment as best as possible.
* The plugin to be tested is downloaded from WordPress using the most recent version available.
* Security testing is performed (see next section for detailed testing information).
* If any issues are detected, the developer is contacted and asked to release a fix.
* A blocking bug is created pertaining to the fix. If the developer does not respond within a reasonable time frame, our developers may fix the issue on a local installation.

===Detailed Testing Procedures===
* Determine the functionality of the plugin. Most plugins add a set of features to the admin page, but some are much more complex.
** Do the features allow non-admin users to add data or enter input on the site?
** Is that data treated as unsafe (i.e. not used directly in SQL statements or reflected back to other users or admins)?
** Does the plugin alter the login process, add additional users, or grant additional rights to non-admins?
* View the settings page for the plugin and test the inputs for cross-site scripting and SQL injection vulnerabilities.
** Note that some plugins enable the use of unfiltered HTML within the admin page. This behavior is allowed unless the plugin also exposes this functionality to non-admins.
** Ensure that unfiltered HTML is being used in expected places. For example, unfiltered HTML may be allowed when editing posts, but some input boxes can be XSS'ed with "/><script>alert(1);</script>. This breaks out of the settings input box and allows unfiltered code execution on the settings page.
* View the methods used to save settings. Some plugins use POST (desirable) and others use GET.
** Where GET is used, especially check all settings for potential XSS as an admin can be sent a link containing the XSS and it will be executed immediately (or following login).
** If POST is used, check for potential CSRF issues. A nonce should be used to protect the admin page from CSRF.
* View the code of the plugin itself (this can be done in WordPress by clicking Plugins > Editor and selecting the plugin).
** Check for all input accepted by the plugin ($_GET, $_REQUEST, $_POST).
** Fuzz all inputs for potential XSS and SQL injection vulnerabilities.

Do the varied nature of plugins, it is impossible to have a "one stop" checklist. Each plugin must be manually checked and the testing procedures altered depending on the functionality. The above process is a general guideline and does not apply to every plugin.

= Security Review Documentation =
== Structure of a Security Review ==

This document covers five distinct activities and the documentation they produce when a security review is performed. Note that this guidance is prescriptive in that each component of a security review document should be produced, or a statement explaining why it wasn't should be included.

The goal of this document is to ensure that the Security Assurance team has a consistent format for the documentation we produce without enforcing a strict structure on how security review and testing is performed.

=== Architecture Diagram ===

An architecture diagram illustrates how the various components of the service communicate with one another.

The goal of the architecture diagram is to give the audience a high-level visual representation of how the different components of a system will interact together.

An example of this is the diagram below, which is from the old Mozilla F1 service.

[https://wiki.mozilla.org/images/thumb/7/78/F1design.png/392px-F1design.png Mozilla F1 Architecture Diagram]

The F1 service had multiple components:
* a Firefox Add-on that hosted a pane loaded from the Mozilla F1 service that facilitated posting ('sharing') content across multiple services
* a back-end that abstracted the 'sharing' process such that a core set of common functions to facilitate easy incorporation of addition services without client updates

Rather than providing a detailed assessment of how messages are passed between the various components, this diagram illustrates how the different components interact with one another, but not details about the interactions, or what data is shared between them.

The goal of this diagram is to provide a concise overview of the system that provides a frame of reference when someone new to the system is reviewing supporting documentation or code.

==== Key Attributes ====
* Clarity; brief descriptions of which components are communicating
* Illustrates the boundaries between different services

==== Additional Examples ====
* [https://people.mozilla.com/~yboily/identity/assets/images-1/s31.b.jpeg BrowserID Protocol High Level]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg Apps MarketPlace] TODO - Replace Me With A Simple Diagram!

=== Detailed Application Diagram ===
A Detailed Application Diagram is essentially a Data-flow diagram; a data flow diagram enumerates each application or service that is a component of a system, and illustrates each of the paths data can flow through.

[https://wiki.mozilla.org/images/2/22/BrowserID-Threat-Model.png BrowserID Detailed Diagram]

Note that a data-flow diagram is only one example of how this information. The goal is to effectively communicate to the audience how data moves through the system, where different operations are performed, and if detailed enough, how different roles within the system can access different operations.

When designing the detailed application diagram it can be useful to assemble a list of each of the subjects in a system.

TODO - add references for subject/object/operations in relation to access control models.

==== Key Attributes ====
* Clarity; labels for objects are brief, and contain clear references that can be used to cross-reference other documentation
* Detailed; ensure that all roles and operations are clearly presented

==== Additional Examples====
* [https://wiki.mozilla.org/images/b/bf/MozillaF1-Diagram.png Mozilla F1 Detailed Application Diagram]
* [https://wiki.mozilla.org/images/e/ee/BrowserID-Protocol.png BrowserID Protocol]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg AppStore Threat Model]

=== Data-flow Enumeration ===

Data-flow enumeration is an important supplement to the Detailed Application Diagram; it acts as a reference for someone reading the diagram to look up the nature of what information is associated with a call or request between two components.

At a minimum, the flow enumeration should be a table indicating an identifier, subject, object, and the operation being performed.

In the example below, an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID provisioning enumeration], the subject, object, and operation are labelled origin, destination, and description, respectively.

{| border="1" class="fullwidth-table"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Origin'''
| align="center" style="background:#f0f0f0;"|'''Destination'''
| align="center" style="background:#f0f0f0;"|'''Description'''
|-
|1.A||Relying Party||Implementation Provider|| An interaction with the Relying party invokes the Implementation Provider (IP).
|-
|1.B||Implementation Provider||Identity Authority||The IP either has an expired certificate, or no certificate, and directs the client to an Identity Authority landing page for authentication. This authentication process is out of scope of the protocol, and implementation dependent.
|-
|1.C||Identity Authority||Identity Authority||Code from the IP landing page invokes genKeyPair() to generate a keypair.
|-
|1.D||Identity Authority||Implementation Provider||The IP saves the keypair in the client
|}

In addition to including the subject, object, operation columns, it can be helpful to include an explicit list of fields which are considered sensitive.

==== Additional Examples ====
* [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID Data-flow Enumeration]

=== Threat Analysis ===

When performing a security review of an application one of the most important components is a threat analysis. There is a great deal of documentation on how to perform threat analysis, and a number of different techniques that can be used:

* [https://www.owasp.org/index.php/Threat_Risk_Modeling OWASP Threat Risk Modelling]
* [http://msdn.microsoft.com/en-us/security/aa570413 Microsoft Application Threat Modelling]
* [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf NIST Risk Management Guide][pdf]

For the purposes of a Mozilla Security Review, the means by which someone identifies the threats and risks associated with an application is important, but not specified. If you have questions about how to perform this type of analysis, please contact a member of our team!

The resulting threat analysis should be formatted in a clear format, including the following details:

* ID - a identifier for the threat
* Title - a concise description of the threat
* Threat - a description of the threat
* Mitigations - a recommendation for a control that can be implemented [1]
* Threat Agent - a list of the potential actors considered that would exploit a vulnerability.
* Notes - Related comments that contribute to the analysis, but don't belong in other columns
* Rating - A qualitative scoring for a vulnerability in the context of this application [2]
* Impact - A qualitative score representing the impact should a vulnerability be exploited
* Likelihood - A qualitative score representing the likelihood of a vulnerability being exploited. [3]

See [https://wiki.mozilla.org/Security/RiskRatings Risk Ratings] for details of how to calculate the qualitative scores.

TODO - Glossary Threat, Threat Agent, Vulnerability, Exploit
[1] In the case of a threat analysis that contains multiple threats that can be resolved by one or more different controls it may be beneficial to include a separate control table, and list references to controls in that table instead.
[2] The rating is calculated by multiplying the impact by the likelihood. This is a naive method, but it's what we have!
[3] In the case where different threat agents have different likelihoods, list the likelihoods highest to lowest, in the same order as the threat agents.

Below is an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model BrowserID Threat Analysis]:

{| border="1" class="fullwidth-table sortable"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Title'''
| align="center" style="background:#f0f0f0;"|'''Threat'''
| align="center" style="background:#f0f0f0;"|'''Proposed Mitigations'''
| align="center" style="background:#f0f0f0;"|'''Threat Agent'''
| align="center" style="background:#f0f0f0;"|'''Rating'''
| align="center" style="background:#f0f0f0;"|'''Likelihood'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
| align="center" style="background:#f0f0f0;"|'''Impact'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
|-
| 1||SIA may introduce compliance issues||Operating a Secondary Identity Authority may induce compliance requirements with regards to logging user information||Part of the goal of BrowserID is to have Primary Identity Authorities take on this risk as part of their other operations. This can be somewhat mitigated by eliminating support for the webfinger verification process.||Governments, Lawyers||12||3||Governments and other legal actors have the ability to request information from us, either through subpoenas, NSLs, etc. While we hold information that can link user identities to services this information will be a source of risk.||4 – Reputation||Although we are required to comply, and Mozilla would fight such a request to the degree permitted, we would still receive negative press.
|-
| 2||Webfinger Information Leak||Use of the webfinger service for verification discloses each authentication attempt from the Relying Party to the Identity Authority||Implement verification using certificates||Malicious Identity Authority||25||5||This information disclosure is a part of the protocol.||5 – Privacy||This is probably a clear violation of our privacy policies.
|-
| 3||Chrome Code Injection||Attacker controlled parameters could permit injection of script into browser chrome.||Ensure that any data controlled by the user or relying party is emitted using output encoding.||Malicious Relying Party, Malicious User, Malicious Identity Authority||4||1||Code review and testing should prevent this occuring. The technical complexity of this attack is higher than a vanilla XSS.||4 – User||This gives an attacker the ability to execute code in the context of browser chrome.
|}

==== Additional Examples ====
* Mozilla F1 Threats [https://wiki.mozilla.org/Security/Reviews/F1#Threat_Model]
* BrowserID Threats [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model]

=== Security Testing ===

The security test plan is a brief explanation of security testing that should be performed, and should include an explanation of what tasks are to be performed, and the approximate amount of time spent performing those tasks.

Security/ReviewProcess

2012-08-20T19:25:37Z

Mfuller: /* Additional Resources */

This page contains draft documentation of our security review processes.

= Security Review Processes =
==Web Application Review Process==
Web applications vary dramatically in design and functionality making it difficult to create a single use-case checklist for security reviews. However, most applications undergo the following checks during the security review process.

===General Web Application Review Process===
Many of these questions are taken from the secure coding guidelines page: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines

====Access Information====
* How is the application accessed?
* Is the application internal or publicly available?
* If it is internal, what mechanism prevents non-members from accessing it?
* Are there links to user-only resources displayed to non-users?
* Are login pages secured with SSL over HTTPS?
* If HTTPS is used, is Strict Transport Security set?

====Infrastructure and Backends====
* What languages do the applications use?
* What database language is used if applicable?
* Are the running versions up to date?
* What server is it running on?

====Accounts and Passwords====
* If the mechanism to prevent general access is a password, how is the signup process handled?
* How is account information stored?
* Are passwords properly stored within databases if applicable?
* Is a password policy in place?
* Are accounts locked-out after a number of invalid logins?
* Are passwords 8 characters or greater?
* Do passwords use both numbers and letters (and possibly symbols)?
* Is there a blacklist of common passwords?
* Do passwords expire after X days and require a reset?
* Are invalid logins logged?
* Is there a lockout after X invalid attempts?
* Is the error message for lockout generic (does not include if user/pass is valid)?
* How are password resets handled (i.e. email, security question, etc.)?
* Do emails sent after signup/reset contain a session link? (should not)
* Do email verification codes expire after one use or 8 hours?
* Is password reuse limited/prevented?

====Session Management====
* How long are session cookies stored?
* Are session tokens 128-bit or greater?
* Is session ID token creation handled by the server (or cryptographically if locally)?
* Do authenticated sessions timeout after 15 minutes?
* Is the Secure Flag enabled for all set cookies?
* Is the HTTP-Only flag used to disable malicious script access to the session ID?
* Are new session ids created on login?
* On logout, are session ids invalidated?

====Third-Party Resources====
* Are third-party resources used (i.e. JavaScript libraries, images, CSS, etc.)?
* Can those resources be trusted / are they from reputable sources?
* Is there a chance the resource could be compromised?
* Is it possible to host the resources locally to mitigate risks?
* Is a third-party responsible for storage of user data?
* Does the application connect with services like Facebook, Twitter, etc?

====Data Handling====
* What kind of data is transferred between the user and the application?
* Is this data generated by the user or generated automatically?
* Can the data be trusted?
* How is the data sent to the application (i.e. JSON format, plain-text, GET/POST, etc.)?
* How is the data handled by the server/application?
* Can the data be manipulated in transit?
* What happens if the data is altered?
* What is done with the data once it is received (i.e. stored in a database, displayed to users)?
* Is any data storage done via cookies? If so, what kind of data is stored via this method?

====Uploaded Data====
* Can the user upload data to the application?
* Are extensions, file size, file type (not only based on extension), etc. checked?
* Are files renamed upon upload?
* Is the correct content-type used?

====Data Sensitivity====
* What kind of data is being stored and/or manipulated by the application?
* Does this data need to be encrypted in transit? In storage?
* What is the impact if this data is lost/stolen?
* Is secure/sensitive data sent over SSL?

====Application Administration====
* Is there an administration console?
* Can it be accessed publicly?
* How is it secured if so?
* Are correct methods used to prevent admin actions from being performed outside of the admin console (i.e. using CSRF tokens)?
* Are there any configuration pages that should not be made public?

====Security Coding Flaws====
* Have all user inputs been sanitized?
* Is a maximum size for data (input or uploads) defined?
* Do all URL variables pass through sanitization?
* Is data from databases escaped properly?
* Are CSRF tokens used to prevent POSTs from outside websites?
* If a database is used, are protections against SQL injection in place?
* Is validation done on the server side (not just client-side)?
* Is output encoded in addition to sanitization of input?
* Does the user ever send data to the OS level?
* Are x-frame options sent to “deny” or “sameorigin”?
* Is debug mode disabled?

===Additional Resources===
Template for the above checks: https://docs.google.com/document/d/1SAzDuMwKUNN4_gdotqcv0oeZwLngjXjNYuZ2HZZaXp4/edit

Also, please view the WebAppSec Wiki: https://wiki.mozilla.org/WebAppSec

==WordPress Plugin Review Process==
Before being installed, all WordPress plugins must be reviewed by the security team. These reviews are simpler than full site reviews and ensure that the plugin being installed does not compromise the security of the blog/site.

===Common Attack Vectors===
The most common WordPress security issues present in plugins are cross-site scripting vulnerabilities (both persistent and reflected). Other vulnerabilities to check for include privilege escalation, remote code execution, logic errors, and SQL injection.

===Review Process Overview===
A majority of the plugin review process involves manual inspection of the plugin and review of the plugin's code. The following steps outline a basic process followed when reviewing plugins.
* A test installation of WordPress is used (see Turnkey WordPress: http://www.turnkeylinux.org/wordpress)
** The WordPress version must match that of the blog on which the plugin will be installed.
* If the plugin is being installed on a high profile blog, a staging installation may already be available. It is best to test here to replicate the production environment as best as possible.
* The plugin to be tested is downloaded from WordPress using the most recent version available.
* Security testing is performed (see next section for detailed testing information).
* If any issues are detected, the developer is contacted and asked to release a fix.
* A blocking bug is created pertaining to the fix. If the developer does not respond within a reasonable time frame, our developers may fix the issue on a local installation.

===Detailed Testing Procedures===
* Determine the functionality of the plugin. Most plugins add a set of features to the admin page, but some are much more complex.
** Do the features allow non-admin users to add data or enter input on the site?
** Is that data treated as unsafe (i.e. not used directly in SQL statements or reflected back to other users or admins)?
** Does the plugin alter the login process, add additional users, or grant additional rights to non-admins?
* View the settings page for the plugin and test the inputs for cross-site scripting and SQL injection vulnerabilities.
** Note that some plugins enable the use of unfiltered HTML within the admin page. This behavior is allowed unless the plugin also exposes this functionality to non-admins.
** Ensure that unfiltered HTML is being used in expected places. For example, unfiltered HTML may be allowed when editing posts, but some input boxes can be XSS'ed with "/><script>alert(1);</script>. This breaks out of the settings input box and allows unfiltered code execution on the settings page.
* View the methods used to save settings. Some plugins use POST (desirable) and others use GET.
** Where GET is used, especially check all settings for potential XSS as an admin can be sent a link containing the XSS and it will be executed immediately (or following login).
** If POST is used, check for potential CSRF issues. A nonce should be used to protect the admin page from CSRF.
* View the code of the plugin itself (this can be done in WordPress by clicking Plugins > Editor and selecting the plugin).
** Check for all input accepted by the plugin ($_GET, $_REQUEST, $_POST).
** Fuzz all inputs for potential XSS and SQL injection vulnerabilities.

Do the varied nature of plugins, it is impossible to have a "one stop" checklist. Each plugin must be manually checked and the testing procedures altered depending on the functionality. The above process is a general guideline and does not apply to every plugin.

= Security Review Documentation =
== Structure of a Security Review ==

This document covers five distinct activities and the documentation they produce when a security review is performed. Note that this guidance is prescriptive in that each component of a security review document should be produced, or a statement explaining why it wasn't should be included.

The goal of this document is to ensure that the Security Assurance team has a consistent format for the documentation we produce without enforcing a strict structure on how security review and testing is performed.

=== Architecture Diagram ===

An architecture diagram illustrates how the various components of the service communicate with one another.

The goal of the architecture diagram is to give the audience a high-level visual representation of how the different components of a system will interact together.

An example of this is the diagram below, which is from the old Mozilla F1 service.

[https://wiki.mozilla.org/images/thumb/7/78/F1design.png/392px-F1design.png Mozilla F1 Architecture Diagram]

The F1 service had multiple components:
* a Firefox Add-on that hosted a pane loaded from the Mozilla F1 service that facilitated posting ('sharing') content across multiple services
* a back-end that abstracted the 'sharing' process such that a core set of common functions to facilitate easy incorporation of addition services without client updates

Rather than providing a detailed assessment of how messages are passed between the various components, this diagram illustrates how the different components interact with one another, but not details about the interactions, or what data is shared between them.

The goal of this diagram is to provide a concise overview of the system that provides a frame of reference when someone new to the system is reviewing supporting documentation or code.

==== Key Attributes ====
* Clarity; brief descriptions of which components are communicating
* Illustrates the boundaries between different services

==== Additional Examples ====
* [https://people.mozilla.com/~yboily/identity/assets/images-1/s31.b.jpeg BrowserID Protocol High Level]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg Apps MarketPlace] TODO - Replace Me With A Simple Diagram!

=== Detailed Application Diagram ===
A Detailed Application Diagram is essentially a Data-flow diagram; a data flow diagram enumerates each application or service that is a component of a system, and illustrates each of the paths data can flow through.

[https://wiki.mozilla.org/images/2/22/BrowserID-Threat-Model.png BrowserID Detailed Diagram]

Note that a data-flow diagram is only one example of how this information. The goal is to effectively communicate to the audience how data moves through the system, where different operations are performed, and if detailed enough, how different roles within the system can access different operations.

When designing the detailed application diagram it can be useful to assemble a list of each of the subjects in a system.

TODO - add references for subject/object/operations in relation to access control models.

==== Key Attributes ====
* Clarity; labels for objects are brief, and contain clear references that can be used to cross-reference other documentation
* Detailed; ensure that all roles and operations are clearly presented

==== Additional Examples====
* [https://wiki.mozilla.org/images/b/bf/MozillaF1-Diagram.png Mozilla F1 Detailed Application Diagram]
* [https://wiki.mozilla.org/images/e/ee/BrowserID-Protocol.png BrowserID Protocol]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg AppStore Threat Model]

=== Data-flow Enumeration ===

Data-flow enumeration is an important supplement to the Detailed Application Diagram; it acts as a reference for someone reading the diagram to look up the nature of what information is associated with a call or request between two components.

At a minimum, the flow enumeration should be a table indicating an identifier, subject, object, and the operation being performed.

In the example below, an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID provisioning enumeration], the subject, object, and operation are labelled origin, destination, and description, respectively.

{| border="1" class="fullwidth-table"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Origin'''
| align="center" style="background:#f0f0f0;"|'''Destination'''
| align="center" style="background:#f0f0f0;"|'''Description'''
|-
|1.A||Relying Party||Implementation Provider|| An interaction with the Relying party invokes the Implementation Provider (IP).
|-
|1.B||Implementation Provider||Identity Authority||The IP either has an expired certificate, or no certificate, and directs the client to an Identity Authority landing page for authentication. This authentication process is out of scope of the protocol, and implementation dependent.
|-
|1.C||Identity Authority||Identity Authority||Code from the IP landing page invokes genKeyPair() to generate a keypair.
|-
|1.D||Identity Authority||Implementation Provider||The IP saves the keypair in the client
|}

In addition to including the subject, object, operation columns, it can be helpful to include an explicit list of fields which are considered sensitive.

==== Additional Examples ====
* [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID Data-flow Enumeration]

=== Threat Analysis ===

When performing a security review of an application one of the most important components is a threat analysis. There is a great deal of documentation on how to perform threat analysis, and a number of different techniques that can be used:

* [https://www.owasp.org/index.php/Threat_Risk_Modeling OWASP Threat Risk Modelling]
* [http://msdn.microsoft.com/en-us/security/aa570413 Microsoft Application Threat Modelling]
* [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf NIST Risk Management Guide][pdf]

For the purposes of a Mozilla Security Review, the means by which someone identifies the threats and risks associated with an application is important, but not specified. If you have questions about how to perform this type of analysis, please contact a member of our team!

The resulting threat analysis should be formatted in a clear format, including the following details:

* ID - a identifier for the threat
* Title - a concise description of the threat
* Threat - a description of the threat
* Mitigations - a recommendation for a control that can be implemented [1]
* Threat Agent - a list of the potential actors considered that would exploit a vulnerability.
* Notes - Related comments that contribute to the analysis, but don't belong in other columns
* Rating - A qualitative scoring for a vulnerability in the context of this application [2]
* Impact - A qualitative score representing the impact should a vulnerability be exploited
* Likelihood - A qualitative score representing the likelihood of a vulnerability being exploited. [3]

See [https://wiki.mozilla.org/Security/RiskRatings Risk Ratings] for details of how to calculate the qualitative scores.

TODO - Glossary Threat, Threat Agent, Vulnerability, Exploit
[1] In the case of a threat analysis that contains multiple threats that can be resolved by one or more different controls it may be beneficial to include a separate control table, and list references to controls in that table instead.
[2] The rating is calculated by multiplying the impact by the likelihood. This is a naive method, but it's what we have!
[3] In the case where different threat agents have different likelihoods, list the likelihoods highest to lowest, in the same order as the threat agents.

Below is an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model BrowserID Threat Analysis]:

{| border="1" class="fullwidth-table sortable"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Title'''
| align="center" style="background:#f0f0f0;"|'''Threat'''
| align="center" style="background:#f0f0f0;"|'''Proposed Mitigations'''
| align="center" style="background:#f0f0f0;"|'''Threat Agent'''
| align="center" style="background:#f0f0f0;"|'''Rating'''
| align="center" style="background:#f0f0f0;"|'''Likelihood'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
| align="center" style="background:#f0f0f0;"|'''Impact'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
|-
| 1||SIA may introduce compliance issues||Operating a Secondary Identity Authority may induce compliance requirements with regards to logging user information||Part of the goal of BrowserID is to have Primary Identity Authorities take on this risk as part of their other operations. This can be somewhat mitigated by eliminating support for the webfinger verification process.||Governments, Lawyers||12||3||Governments and other legal actors have the ability to request information from us, either through subpoenas, NSLs, etc. While we hold information that can link user identities to services this information will be a source of risk.||4 – Reputation||Although we are required to comply, and Mozilla would fight such a request to the degree permitted, we would still receive negative press.
|-
| 2||Webfinger Information Leak||Use of the webfinger service for verification discloses each authentication attempt from the Relying Party to the Identity Authority||Implement verification using certificates||Malicious Identity Authority||25||5||This information disclosure is a part of the protocol.||5 – Privacy||This is probably a clear violation of our privacy policies.
|-
| 3||Chrome Code Injection||Attacker controlled parameters could permit injection of script into browser chrome.||Ensure that any data controlled by the user or relying party is emitted using output encoding.||Malicious Relying Party, Malicious User, Malicious Identity Authority||4||1||Code review and testing should prevent this occuring. The technical complexity of this attack is higher than a vanilla XSS.||4 – User||This gives an attacker the ability to execute code in the context of browser chrome.
|}

==== Additional Examples ====
* Mozilla F1 Threats [https://wiki.mozilla.org/Security/Reviews/F1#Threat_Model]
* BrowserID Threats [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model]

=== Security Testing ===

The security test plan is a brief explanation of security testing that should be performed, and should include an explanation of what tasks are to be performed, and the approximate amount of time spent performing those tasks.

Security

2012-08-20T18:34:22Z

Mfuller: /* Twitter Accounts of Security Mozillians */

Welcome to the Mozilla Security wiki.

=== Security-related bugs ===
* [[Security Severity Ratings]]
* [http://www.mozilla.org/security/#For_Developers How to report a security issue]
* [[Security/FixMe|Want to fix a security bug? Here is a list of old thorny bugs you can take on.]]

===Engaging with Security===
====How To Find Us====
Lot's of options, we're here to help:
* [mailto:Security@mozilla.org Security@mozilla.org] - email us any questions, concerns, etc
* Bugzilla Keyword - '''sec-review-needed''' - We triage based on this keyword and will jump in to provide assistance
* '''#security''' on [https://wiki.mozilla.org/IRC IRC]
* File a security/privacy review request via this [https://wiki.mozilla.org/Security/Reviews/Review_Request_Form link]
* Attend a [[Security/Talks | Security Talk]] given by one of the security team

====Security reviews for new features/products/applications====
''Main Article: [[Security/Reviews]]''
* Find past reviews by [https://wiki.mozilla.org/Category:SecReview Category:SecReview]
====The Mozilla Secure Development Lifecycle ====
* Understand the [[Security/Reviews/Secure Development Lifecycle | Secure Development Lifecycle]] used to secure our new features/products/applications
* Information on Bugzilla and the [[Security/Reviews/Bugzilla Components| Security Assurance Component]]
====Request a Security or Privacy Review ====
* Complete the questions at the following page to provide the basic info to kickstart a security or privacy review
* We'll create and link the corresponding wiki page within the [[Security/Radar|Security Radar]]
* [[Security/Reviews/Review Request Form | Security & Privacy Review Request Form]]
====[[Security/Radar|Security Radar]]====

{| class="wikitable collapsible collapsed" style="width: 100%"
! Unlinked Reviews
|-
|
* [[Security/Reviews/Mobile/AndroidSystemStorage| Android System Storage]]
* [[Security/Firefox/WebAPI/WebBattery| WebBattery]]
* [[Security/Reviews/BrowserIDCAPI| BrowserID C API]]
* [[Security/Reviews/crossoriginAttribute|Add crossorigin attribute]]
* [[Security/Reviews/Firefox10/SyncDialogue|Sync Dialogue]]
* [[Security/Reviews/JetPack2011-20/12 | JetPack 2011-10-12]]
* [[Security/Reviews/XHRnonpost| XHR non-post rewrite]]
* [[Security/Reviews/StubInstaller|Stub Installer]]
* [[Labs/Weave/Sync Client Security Review|Sync Client]]
* [[Firefox Sync/Weave 1.3b5 Client Security Review|Weave 1.3b5 Client]]
* [[Security/Reviews/DNSSEC-TLS|DNSSEC-TLS]]
* [[Security/Reviews/OWA-F1|Web Activities & F1]]
* [[Security/Reviews/ReviewNotes/MouseLock|MouseLock]]
* [[Security/Reviews/ReviewNotes/Joystick|Joystick]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! Unlinked Discussions
|-
|
* [[Security/Discussions/WebRTC|WebRTC]]
|}

===Security Feature Development===

''Main article: [[Security/Roadmap]]''

''Main article: [[Privacy/Roadmap]]''

=== Security Initiatives ===

*[[Security/TeamEmbedding]]
*Prioritizing and driving non-feature work: [[Security/Driving]]

=== Security Resources and Blogs ===

==== Mozilla Official Sites ====
* [http://www.mozilla.org/security Mozilla Security Center]
* [http://developer.mozilla.org/en/Security Mozilla security developer docs]
* [[CA|Mozilla CA Root Program]]
* [http://blog.mozilla.com/security Mozilla Security blog]
* [http://blog.mozilla.com/webappsec Mozilla WebApp Sec Blog]
* [https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines Secure Coding Guidelines for Webapps]

==== Personal Security Related Blogs of Mozillians ====
* [http://blog.mozilla.com/ladamski Lucas Adamski's blog]
* [http://blog.sidstamm.com Sid Stamm's blog]
* [https://spartiates.wordpress.com/ Curtis Koenig's blog]
* [http://www.squarefree.com/ Jesse Ruderman's blog] ([http://www.squarefree.com/categories/fuzzing/ fuzzing entries], [http://www.squarefree.com/categories/security/ security entries])
* [http://michael-coates.blogspot.com/ Michael Coates]
* [http://blog.mozilla.com/imelven Ian Melven's Mozilla/Security blog]
* [http://blog.mozilla.com/decoder Christian Holler's blog (decoder)]

==== Twitter Accounts of Security Mozillians ====
* [https://twitter.com/mozsec Mozilla Security]
* [https://twitter.com/mozwebsec Mozilla Web Security]
* [https://twitter.com/jruderman Jesse Ruderman]
* [https://twitter.com/curtisko Curtis Koenig] (all kinds of random stuff)
* [https://twitter.com/_mwc Michael Coates]
* [https://twitter.com/flamsmark Tom Lowenthal] (privacy)
* [https://twitter.com/securitae Lucas Adamski]
* [https://twitter.com/alexanderfowler Alex Fowler]
* [https://twitter.com/ygjb Yvan Boily]
* [https://twitter.com/dveditz Daniel Veditz]
* [https://twitter.com/gh_rooster Raymond Forbes]
* [https://twitter.com/openbuddha Al Billings] (but mostly Buddhist and Hackerspace tweets)
* [https://twitter.com/imelven Ian Melven]
* [https://twitter.com/kangsterizer Guillaume Destuynder]
* [https://twitter.com/nth10sd Gary Kwong] (all sorts of stuff)
* [https://twitter.com/mozdeco Christian Holler (decoder)]
* [https://twitter.com/neoCrimeLabs Michael Henry (tinfoil)]
* [https://twitter.com/tanvihacks Tanvi Vyas]
* [https://twitter.com/psiinon Simon Bennetts (psiinon)]
* [https://twitter.com/matthewdfuller Matt Fuller (mfuller)]

==== Non-Mozilla Resources (blogs, news sites, twitter, tools) ====
* [[Security/OtherSecurityResources| Other Security Resources]]

<h3>Stuff that needs to be merged into this page properly</h3>

=== Meeting Notes ===
{| class="wikitable collapsible collapsed" style="width: 100%"
! Meetings
|-
|
* [[Security/Meetings/SecurityAssurance|Security Assurance]]
* [[Security/AppSecBiweekly|AppSec Bi Weelky]]

{| class="wikitable collapsible collapsed" style="width: 100%"
! SecTeam Meetings 2012
|-
|
* [[Security/Meetings/2012-02-01|2012-02-01]]
* [[Security/Meetings/2012-01-25|2012-01-25]]
* [[Security/Meetings/2012-01-18|2012-01-18]]
* [[Security/Meetings/2012-01-11|2012-01-11]]
* [[Security/Meetings/2012-01-04|2012-01-04]]
|}
{| class="wikitable collapsible collapsed" style="width: 100%"
! SecTeam Meetings 2011
|-
|
* [[Security/Meetings/2011-12-28|2011-12-28]]
* [[Security/Meetings/2011-12-21|2011-12-21]]
* [[Security/Meetings/2011-12-07|2011-12-14]]
* [[Security/Meetings/2011-12-07|2011-12-07]]
* [[Security/Meetings/2011-11-30|2011-11-30]]
* [[Security/Meetings/2011-11-23|2011-11-23]]
* [[Security/Meetings/2011-11-16|2011-11-16]]
* [[Security/Meetings/2011-11-09|2011-11-09]]
* [[Security/Meetings/2011-11-02|2011-11-02]]
* [[Security/Meetings/2011-10-26|2011-10-26]]
* [[Security/Meetings/2011-10-19|2011-10-19]]
* [[Security/Meetings/2011-10-12|2011-10-12]]
* [[Security/Meetings/2011-10-05|2011-10-05]]
* [[Security/Meetings/2011-09-28|2011-09-28]]
* No meeting on 9/14 (All Hands) or 9/21 (Fuzzing Work Week)
* [[Security/Meetings/2011-09-07|2011-09-07]]
* [[Security/Meetings/2011-08-31|2011-08-31]]
* [[Security/Meetings/2011-08-24|2011-08-24]]
* [[Security/Meetings/lifecycledisc|Life Cycle discussion]]
* [[Security/Meetings/2011-08-17|2011-08-17]]
* [[Security/Meetings/2011-08-10|2011-08-10]]
* [[Security/Meetings/2011-07-27|2011-07-27]]
* [[Security/Meetings/2011-07-20|2011-07-20]]
* [[Security/Meetings/2011-07-13|2011-07-13]]
* [[Security/Meetings/2011-07-06|2011-07-06]]
* [[Security/Meetings/2011-06-29|2011-06-29]]
* [[Security/Meetings/2011-06-22|2011-06-22]]
* [[Security/Meetings/2011-06-15|2011-06-15]]
* [[Security/Meetings/2011-06-08|2011-06-08]]
* [[Security/Meetings/2011-06-01|2011-06-01]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! Joint Secteam-Infrasec Meetings 2012
|-
|
* [[Security/Meetings/2012-01-12|2012-01-12]]
|}
{| class="wikitable collapsible collapsed" style="width: 100%"
! Joint Secteam-Infrasec Meetings 2011
|-
|

* [[Security/Meetings/2011-12-15|2011-12-15]]
* [[Security/Meetings/2011-11-17|2011-11-17]]
* [[Security/Meetings/2011-10-06|2011-10-06]]
* [[Security/Meetings/2011-09-08|2011-09-08]]
* [[Security/Meetings/2011-08-25|2011-08-25]]
* [[Security/Meetings/2011-08-11|2011-08-11]]
* [[Security/Meetings/2011-07-28|2011-07-28]]
* [[Security/Meetings/2011-06-16|2011-06-16]]
|}
|}

Security/ReviewProcess

2012-08-20T18:12:04Z

Mfuller: /* Additional Resources */

This page contains draft documentation of our security review processes.

= Security Review Processes =
==Web Application Review Process==
Web applications vary dramatically in design and functionality making it difficult to create a single use-case checklist for security reviews. However, most applications undergo the following checks during the security review process.

===General Web Application Review Process===
Many of these questions are taken from the secure coding guidelines page: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines

====Access Information====
* How is the application accessed?
* Is the application internal or publicly available?
* If it is internal, what mechanism prevents non-members from accessing it?
* Are there links to user-only resources displayed to non-users?
* Are login pages secured with SSL over HTTPS?
* If HTTPS is used, is Strict Transport Security set?

====Infrastructure and Backends====
* What languages do the applications use?
* What database language is used if applicable?
* Are the running versions up to date?
* What server is it running on?

====Accounts and Passwords====
* If the mechanism to prevent general access is a password, how is the signup process handled?
* How is account information stored?
* Are passwords properly stored within databases if applicable?
* Is a password policy in place?
* Are accounts locked-out after a number of invalid logins?
* Are passwords 8 characters or greater?
* Do passwords use both numbers and letters (and possibly symbols)?
* Is there a blacklist of common passwords?
* Do passwords expire after X days and require a reset?
* Are invalid logins logged?
* Is there a lockout after X invalid attempts?
* Is the error message for lockout generic (does not include if user/pass is valid)?
* How are password resets handled (i.e. email, security question, etc.)?
* Do emails sent after signup/reset contain a session link? (should not)
* Do email verification codes expire after one use or 8 hours?
* Is password reuse limited/prevented?

====Session Management====
* How long are session cookies stored?
* Are session tokens 128-bit or greater?
* Is session ID token creation handled by the server (or cryptographically if locally)?
* Do authenticated sessions timeout after 15 minutes?
* Is the Secure Flag enabled for all set cookies?
* Is the HTTP-Only flag used to disable malicious script access to the session ID?
* Are new session ids created on login?
* On logout, are session ids invalidated?

====Third-Party Resources====
* Are third-party resources used (i.e. JavaScript libraries, images, CSS, etc.)?
* Can those resources be trusted / are they from reputable sources?
* Is there a chance the resource could be compromised?
* Is it possible to host the resources locally to mitigate risks?
* Is a third-party responsible for storage of user data?
* Does the application connect with services like Facebook, Twitter, etc?

====Data Handling====
* What kind of data is transferred between the user and the application?
* Is this data generated by the user or generated automatically?
* Can the data be trusted?
* How is the data sent to the application (i.e. JSON format, plain-text, GET/POST, etc.)?
* How is the data handled by the server/application?
* Can the data be manipulated in transit?
* What happens if the data is altered?
* What is done with the data once it is received (i.e. stored in a database, displayed to users)?
* Is any data storage done via cookies? If so, what kind of data is stored via this method?

====Uploaded Data====
* Can the user upload data to the application?
* Are extensions, file size, file type (not only based on extension), etc. checked?
* Are files renamed upon upload?
* Is the correct content-type used?

====Data Sensitivity====
* What kind of data is being stored and/or manipulated by the application?
* Does this data need to be encrypted in transit? In storage?
* What is the impact if this data is lost/stolen?
* Is secure/sensitive data sent over SSL?

====Application Administration====
* Is there an administration console?
* Can it be accessed publicly?
* How is it secured if so?
* Are correct methods used to prevent admin actions from being performed outside of the admin console (i.e. using CSRF tokens)?
* Are there any configuration pages that should not be made public?

====Security Coding Flaws====
* Have all user inputs been sanitized?
* Is a maximum size for data (input or uploads) defined?
* Do all URL variables pass through sanitization?
* Is data from databases escaped properly?
* Are CSRF tokens used to prevent POSTs from outside websites?
* If a database is used, are protections against SQL injection in place?
* Is validation done on the server side (not just client-side)?
* Is output encoded in addition to sanitization of input?
* Does the user ever send data to the OS level?
* Are x-frame options sent to “deny” or “sameorigin”?
* Is debug mode disabled?

===Additional Resources===
Template for the above checks: https://docs.google.com/document/d/1SAzDuMwKUNN4_gdotqcv0oeZwLngjXjNYuZ2HZZaXp4/edit

==WordPress Plugin Review Process==
Before being installed, all WordPress plugins must be reviewed by the security team. These reviews are simpler than full site reviews and ensure that the plugin being installed does not compromise the security of the blog/site.

===Common Attack Vectors===
The most common WordPress security issues present in plugins are cross-site scripting vulnerabilities (both persistent and reflected). Other vulnerabilities to check for include privilege escalation, remote code execution, logic errors, and SQL injection.

===Review Process Overview===
A majority of the plugin review process involves manual inspection of the plugin and review of the plugin's code. The following steps outline a basic process followed when reviewing plugins.
* A test installation of WordPress is used (see Turnkey WordPress: http://www.turnkeylinux.org/wordpress)
** The WordPress version must match that of the blog on which the plugin will be installed.
* If the plugin is being installed on a high profile blog, a staging installation may already be available. It is best to test here to replicate the production environment as best as possible.
* The plugin to be tested is downloaded from WordPress using the most recent version available.
* Security testing is performed (see next section for detailed testing information).
* If any issues are detected, the developer is contacted and asked to release a fix.
* A blocking bug is created pertaining to the fix. If the developer does not respond within a reasonable time frame, our developers may fix the issue on a local installation.

===Detailed Testing Procedures===
* Determine the functionality of the plugin. Most plugins add a set of features to the admin page, but some are much more complex.
** Do the features allow non-admin users to add data or enter input on the site?
** Is that data treated as unsafe (i.e. not used directly in SQL statements or reflected back to other users or admins)?
** Does the plugin alter the login process, add additional users, or grant additional rights to non-admins?
* View the settings page for the plugin and test the inputs for cross-site scripting and SQL injection vulnerabilities.
** Note that some plugins enable the use of unfiltered HTML within the admin page. This behavior is allowed unless the plugin also exposes this functionality to non-admins.
** Ensure that unfiltered HTML is being used in expected places. For example, unfiltered HTML may be allowed when editing posts, but some input boxes can be XSS'ed with "/><script>alert(1);</script>. This breaks out of the settings input box and allows unfiltered code execution on the settings page.
* View the methods used to save settings. Some plugins use POST (desirable) and others use GET.
** Where GET is used, especially check all settings for potential XSS as an admin can be sent a link containing the XSS and it will be executed immediately (or following login).
** If POST is used, check for potential CSRF issues. A nonce should be used to protect the admin page from CSRF.
* View the code of the plugin itself (this can be done in WordPress by clicking Plugins > Editor and selecting the plugin).
** Check for all input accepted by the plugin ($_GET, $_REQUEST, $_POST).
** Fuzz all inputs for potential XSS and SQL injection vulnerabilities.

Do the varied nature of plugins, it is impossible to have a "one stop" checklist. Each plugin must be manually checked and the testing procedures altered depending on the functionality. The above process is a general guideline and does not apply to every plugin.

= Security Review Documentation =
== Structure of a Security Review ==

This document covers five distinct activities and the documentation they produce when a security review is performed. Note that this guidance is prescriptive in that each component of a security review document should be produced, or a statement explaining why it wasn't should be included.

The goal of this document is to ensure that the Security Assurance team has a consistent format for the documentation we produce without enforcing a strict structure on how security review and testing is performed.

=== Architecture Diagram ===

An architecture diagram illustrates how the various components of the service communicate with one another.

The goal of the architecture diagram is to give the audience a high-level visual representation of how the different components of a system will interact together.

An example of this is the diagram below, which is from the old Mozilla F1 service.

[https://wiki.mozilla.org/images/thumb/7/78/F1design.png/392px-F1design.png Mozilla F1 Architecture Diagram]

The F1 service had multiple components:
* a Firefox Add-on that hosted a pane loaded from the Mozilla F1 service that facilitated posting ('sharing') content across multiple services
* a back-end that abstracted the 'sharing' process such that a core set of common functions to facilitate easy incorporation of addition services without client updates

Rather than providing a detailed assessment of how messages are passed between the various components, this diagram illustrates how the different components interact with one another, but not details about the interactions, or what data is shared between them.

The goal of this diagram is to provide a concise overview of the system that provides a frame of reference when someone new to the system is reviewing supporting documentation or code.

==== Key Attributes ====
* Clarity; brief descriptions of which components are communicating
* Illustrates the boundaries between different services

==== Additional Examples ====
* [https://people.mozilla.com/~yboily/identity/assets/images-1/s31.b.jpeg BrowserID Protocol High Level]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg Apps MarketPlace] TODO - Replace Me With A Simple Diagram!

=== Detailed Application Diagram ===
A Detailed Application Diagram is essentially a Data-flow diagram; a data flow diagram enumerates each application or service that is a component of a system, and illustrates each of the paths data can flow through.

[https://wiki.mozilla.org/images/2/22/BrowserID-Threat-Model.png BrowserID Detailed Diagram]

Note that a data-flow diagram is only one example of how this information. The goal is to effectively communicate to the audience how data moves through the system, where different operations are performed, and if detailed enough, how different roles within the system can access different operations.

When designing the detailed application diagram it can be useful to assemble a list of each of the subjects in a system.

TODO - add references for subject/object/operations in relation to access control models.

==== Key Attributes ====
* Clarity; labels for objects are brief, and contain clear references that can be used to cross-reference other documentation
* Detailed; ensure that all roles and operations are clearly presented

==== Additional Examples====
* [https://wiki.mozilla.org/images/b/bf/MozillaF1-Diagram.png Mozilla F1 Detailed Application Diagram]
* [https://wiki.mozilla.org/images/e/ee/BrowserID-Protocol.png BrowserID Protocol]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg AppStore Threat Model]

=== Data-flow Enumeration ===

Data-flow enumeration is an important supplement to the Detailed Application Diagram; it acts as a reference for someone reading the diagram to look up the nature of what information is associated with a call or request between two components.

At a minimum, the flow enumeration should be a table indicating an identifier, subject, object, and the operation being performed.

In the example below, an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID provisioning enumeration], the subject, object, and operation are labelled origin, destination, and description, respectively.

{| border="1" class="fullwidth-table"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Origin'''
| align="center" style="background:#f0f0f0;"|'''Destination'''
| align="center" style="background:#f0f0f0;"|'''Description'''
|-
|1.A||Relying Party||Implementation Provider|| An interaction with the Relying party invokes the Implementation Provider (IP).
|-
|1.B||Implementation Provider||Identity Authority||The IP either has an expired certificate, or no certificate, and directs the client to an Identity Authority landing page for authentication. This authentication process is out of scope of the protocol, and implementation dependent.
|-
|1.C||Identity Authority||Identity Authority||Code from the IP landing page invokes genKeyPair() to generate a keypair.
|-
|1.D||Identity Authority||Implementation Provider||The IP saves the keypair in the client
|}

In addition to including the subject, object, operation columns, it can be helpful to include an explicit list of fields which are considered sensitive.

==== Additional Examples ====
* [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID Data-flow Enumeration]

=== Threat Analysis ===

When performing a security review of an application one of the most important components is a threat analysis. There is a great deal of documentation on how to perform threat analysis, and a number of different techniques that can be used:

* [https://www.owasp.org/index.php/Threat_Risk_Modeling OWASP Threat Risk Modelling]
* [http://msdn.microsoft.com/en-us/security/aa570413 Microsoft Application Threat Modelling]
* [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf NIST Risk Management Guide][pdf]

For the purposes of a Mozilla Security Review, the means by which someone identifies the threats and risks associated with an application is important, but not specified. If you have questions about how to perform this type of analysis, please contact a member of our team!

The resulting threat analysis should be formatted in a clear format, including the following details:

* ID - a identifier for the threat
* Title - a concise description of the threat
* Threat - a description of the threat
* Mitigations - a recommendation for a control that can be implemented [1]
* Threat Agent - a list of the potential actors considered that would exploit a vulnerability.
* Notes - Related comments that contribute to the analysis, but don't belong in other columns
* Rating - A qualitative scoring for a vulnerability in the context of this application [2]
* Impact - A qualitative score representing the impact should a vulnerability be exploited
* Likelihood - A qualitative score representing the likelihood of a vulnerability being exploited. [3]

See [https://wiki.mozilla.org/Security/RiskRatings Risk Ratings] for details of how to calculate the qualitative scores.

TODO - Glossary Threat, Threat Agent, Vulnerability, Exploit
[1] In the case of a threat analysis that contains multiple threats that can be resolved by one or more different controls it may be beneficial to include a separate control table, and list references to controls in that table instead.
[2] The rating is calculated by multiplying the impact by the likelihood. This is a naive method, but it's what we have!
[3] In the case where different threat agents have different likelihoods, list the likelihoods highest to lowest, in the same order as the threat agents.

Below is an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model BrowserID Threat Analysis]:

{| border="1" class="fullwidth-table sortable"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Title'''
| align="center" style="background:#f0f0f0;"|'''Threat'''
| align="center" style="background:#f0f0f0;"|'''Proposed Mitigations'''
| align="center" style="background:#f0f0f0;"|'''Threat Agent'''
| align="center" style="background:#f0f0f0;"|'''Rating'''
| align="center" style="background:#f0f0f0;"|'''Likelihood'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
| align="center" style="background:#f0f0f0;"|'''Impact'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
|-
| 1||SIA may introduce compliance issues||Operating a Secondary Identity Authority may induce compliance requirements with regards to logging user information||Part of the goal of BrowserID is to have Primary Identity Authorities take on this risk as part of their other operations. This can be somewhat mitigated by eliminating support for the webfinger verification process.||Governments, Lawyers||12||3||Governments and other legal actors have the ability to request information from us, either through subpoenas, NSLs, etc. While we hold information that can link user identities to services this information will be a source of risk.||4 – Reputation||Although we are required to comply, and Mozilla would fight such a request to the degree permitted, we would still receive negative press.
|-
| 2||Webfinger Information Leak||Use of the webfinger service for verification discloses each authentication attempt from the Relying Party to the Identity Authority||Implement verification using certificates||Malicious Identity Authority||25||5||This information disclosure is a part of the protocol.||5 – Privacy||This is probably a clear violation of our privacy policies.
|-
| 3||Chrome Code Injection||Attacker controlled parameters could permit injection of script into browser chrome.||Ensure that any data controlled by the user or relying party is emitted using output encoding.||Malicious Relying Party, Malicious User, Malicious Identity Authority||4||1||Code review and testing should prevent this occuring. The technical complexity of this attack is higher than a vanilla XSS.||4 – User||This gives an attacker the ability to execute code in the context of browser chrome.
|}

==== Additional Examples ====
* Mozilla F1 Threats [https://wiki.mozilla.org/Security/Reviews/F1#Threat_Model]
* BrowserID Threats [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model]

=== Security Testing ===

The security test plan is a brief explanation of security testing that should be performed, and should include an explanation of what tasks are to be performed, and the approximate amount of time spent performing those tasks.

Security/ReviewProcess

2012-08-20T18:09:35Z

Mfuller: /* Security Review Processes */

This page contains draft documentation of our security review processes.

= Security Review Processes =
==Web Application Review Process==
Web applications vary dramatically in design and functionality making it difficult to create a single use-case checklist for security reviews. However, most applications undergo the following checks during the security review process.

===General Web Application Review Process===
Many of these questions are taken from the secure coding guidelines page: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines

====Access Information====
* How is the application accessed?
* Is the application internal or publicly available?
* If it is internal, what mechanism prevents non-members from accessing it?
* Are there links to user-only resources displayed to non-users?
* Are login pages secured with SSL over HTTPS?
* If HTTPS is used, is Strict Transport Security set?

====Infrastructure and Backends====
* What languages do the applications use?
* What database language is used if applicable?
* Are the running versions up to date?
* What server is it running on?

====Accounts and Passwords====
* If the mechanism to prevent general access is a password, how is the signup process handled?
* How is account information stored?
* Are passwords properly stored within databases if applicable?
* Is a password policy in place?
* Are accounts locked-out after a number of invalid logins?
* Are passwords 8 characters or greater?
* Do passwords use both numbers and letters (and possibly symbols)?
* Is there a blacklist of common passwords?
* Do passwords expire after X days and require a reset?
* Are invalid logins logged?
* Is there a lockout after X invalid attempts?
* Is the error message for lockout generic (does not include if user/pass is valid)?
* How are password resets handled (i.e. email, security question, etc.)?
* Do emails sent after signup/reset contain a session link? (should not)
* Do email verification codes expire after one use or 8 hours?
* Is password reuse limited/prevented?

====Session Management====
* How long are session cookies stored?
* Are session tokens 128-bit or greater?
* Is session ID token creation handled by the server (or cryptographically if locally)?
* Do authenticated sessions timeout after 15 minutes?
* Is the Secure Flag enabled for all set cookies?
* Is the HTTP-Only flag used to disable malicious script access to the session ID?
* Are new session ids created on login?
* On logout, are session ids invalidated?

====Third-Party Resources====
* Are third-party resources used (i.e. JavaScript libraries, images, CSS, etc.)?
* Can those resources be trusted / are they from reputable sources?
* Is there a chance the resource could be compromised?
* Is it possible to host the resources locally to mitigate risks?
* Is a third-party responsible for storage of user data?
* Does the application connect with services like Facebook, Twitter, etc?

====Data Handling====
* What kind of data is transferred between the user and the application?
* Is this data generated by the user or generated automatically?
* Can the data be trusted?
* How is the data sent to the application (i.e. JSON format, plain-text, GET/POST, etc.)?
* How is the data handled by the server/application?
* Can the data be manipulated in transit?
* What happens if the data is altered?
* What is done with the data once it is received (i.e. stored in a database, displayed to users)?
* Is any data storage done via cookies? If so, what kind of data is stored via this method?

====Uploaded Data====
* Can the user upload data to the application?
* Are extensions, file size, file type (not only based on extension), etc. checked?
* Are files renamed upon upload?
* Is the correct content-type used?

====Data Sensitivity====
* What kind of data is being stored and/or manipulated by the application?
* Does this data need to be encrypted in transit? In storage?
* What is the impact if this data is lost/stolen?
* Is secure/sensitive data sent over SSL?

====Application Administration====
* Is there an administration console?
* Can it be accessed publicly?
* How is it secured if so?
* Are correct methods used to prevent admin actions from being performed outside of the admin console (i.e. using CSRF tokens)?
* Are there any configuration pages that should not be made public?

====Security Coding Flaws====
* Have all user inputs been sanitized?
* Is a maximum size for data (input or uploads) defined?
* Do all URL variables pass through sanitization?
* Is data from databases escaped properly?
* Are CSRF tokens used to prevent POSTs from outside websites?
* If a database is used, are protections against SQL injection in place?
* Is validation done on the server side (not just client-side)?
* Is output encoded in addition to sanitization of input?
* Does the user ever send data to the OS level?
* Are x-frame options sent to “deny” or “sameorigin”?
* Is debug mode disabled?

===Additional Resources===
Coming soon

==WordPress Plugin Review Process==
Before being installed, all WordPress plugins must be reviewed by the security team. These reviews are simpler than full site reviews and ensure that the plugin being installed does not compromise the security of the blog/site.

===Common Attack Vectors===
The most common WordPress security issues present in plugins are cross-site scripting vulnerabilities (both persistent and reflected). Other vulnerabilities to check for include privilege escalation, remote code execution, logic errors, and SQL injection.

===Review Process Overview===
A majority of the plugin review process involves manual inspection of the plugin and review of the plugin's code. The following steps outline a basic process followed when reviewing plugins.
* A test installation of WordPress is used (see Turnkey WordPress: http://www.turnkeylinux.org/wordpress)
** The WordPress version must match that of the blog on which the plugin will be installed.
* If the plugin is being installed on a high profile blog, a staging installation may already be available. It is best to test here to replicate the production environment as best as possible.
* The plugin to be tested is downloaded from WordPress using the most recent version available.
* Security testing is performed (see next section for detailed testing information).
* If any issues are detected, the developer is contacted and asked to release a fix.
* A blocking bug is created pertaining to the fix. If the developer does not respond within a reasonable time frame, our developers may fix the issue on a local installation.

===Detailed Testing Procedures===
* Determine the functionality of the plugin. Most plugins add a set of features to the admin page, but some are much more complex.
** Do the features allow non-admin users to add data or enter input on the site?
** Is that data treated as unsafe (i.e. not used directly in SQL statements or reflected back to other users or admins)?
** Does the plugin alter the login process, add additional users, or grant additional rights to non-admins?
* View the settings page for the plugin and test the inputs for cross-site scripting and SQL injection vulnerabilities.
** Note that some plugins enable the use of unfiltered HTML within the admin page. This behavior is allowed unless the plugin also exposes this functionality to non-admins.
** Ensure that unfiltered HTML is being used in expected places. For example, unfiltered HTML may be allowed when editing posts, but some input boxes can be XSS'ed with "/><script>alert(1);</script>. This breaks out of the settings input box and allows unfiltered code execution on the settings page.
* View the methods used to save settings. Some plugins use POST (desirable) and others use GET.
** Where GET is used, especially check all settings for potential XSS as an admin can be sent a link containing the XSS and it will be executed immediately (or following login).
** If POST is used, check for potential CSRF issues. A nonce should be used to protect the admin page from CSRF.
* View the code of the plugin itself (this can be done in WordPress by clicking Plugins > Editor and selecting the plugin).
** Check for all input accepted by the plugin ($_GET, $_REQUEST, $_POST).
** Fuzz all inputs for potential XSS and SQL injection vulnerabilities.

Do the varied nature of plugins, it is impossible to have a "one stop" checklist. Each plugin must be manually checked and the testing procedures altered depending on the functionality. The above process is a general guideline and does not apply to every plugin.

= Security Review Documentation =
== Structure of a Security Review ==

This document covers five distinct activities and the documentation they produce when a security review is performed. Note that this guidance is prescriptive in that each component of a security review document should be produced, or a statement explaining why it wasn't should be included.

The goal of this document is to ensure that the Security Assurance team has a consistent format for the documentation we produce without enforcing a strict structure on how security review and testing is performed.

=== Architecture Diagram ===

An architecture diagram illustrates how the various components of the service communicate with one another.

The goal of the architecture diagram is to give the audience a high-level visual representation of how the different components of a system will interact together.

An example of this is the diagram below, which is from the old Mozilla F1 service.

[https://wiki.mozilla.org/images/thumb/7/78/F1design.png/392px-F1design.png Mozilla F1 Architecture Diagram]

The F1 service had multiple components:
* a Firefox Add-on that hosted a pane loaded from the Mozilla F1 service that facilitated posting ('sharing') content across multiple services
* a back-end that abstracted the 'sharing' process such that a core set of common functions to facilitate easy incorporation of addition services without client updates

Rather than providing a detailed assessment of how messages are passed between the various components, this diagram illustrates how the different components interact with one another, but not details about the interactions, or what data is shared between them.

The goal of this diagram is to provide a concise overview of the system that provides a frame of reference when someone new to the system is reviewing supporting documentation or code.

==== Key Attributes ====
* Clarity; brief descriptions of which components are communicating
* Illustrates the boundaries between different services

==== Additional Examples ====
* [https://people.mozilla.com/~yboily/identity/assets/images-1/s31.b.jpeg BrowserID Protocol High Level]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg Apps MarketPlace] TODO - Replace Me With A Simple Diagram!

=== Detailed Application Diagram ===
A Detailed Application Diagram is essentially a Data-flow diagram; a data flow diagram enumerates each application or service that is a component of a system, and illustrates each of the paths data can flow through.

[https://wiki.mozilla.org/images/2/22/BrowserID-Threat-Model.png BrowserID Detailed Diagram]

Note that a data-flow diagram is only one example of how this information. The goal is to effectively communicate to the audience how data moves through the system, where different operations are performed, and if detailed enough, how different roles within the system can access different operations.

When designing the detailed application diagram it can be useful to assemble a list of each of the subjects in a system.

TODO - add references for subject/object/operations in relation to access control models.

==== Key Attributes ====
* Clarity; labels for objects are brief, and contain clear references that can be used to cross-reference other documentation
* Detailed; ensure that all roles and operations are clearly presented

==== Additional Examples====
* [https://wiki.mozilla.org/images/b/bf/MozillaF1-Diagram.png Mozilla F1 Detailed Application Diagram]
* [https://wiki.mozilla.org/images/e/ee/BrowserID-Protocol.png BrowserID Protocol]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg AppStore Threat Model]

=== Data-flow Enumeration ===

Data-flow enumeration is an important supplement to the Detailed Application Diagram; it acts as a reference for someone reading the diagram to look up the nature of what information is associated with a call or request between two components.

At a minimum, the flow enumeration should be a table indicating an identifier, subject, object, and the operation being performed.

In the example below, an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID provisioning enumeration], the subject, object, and operation are labelled origin, destination, and description, respectively.

{| border="1" class="fullwidth-table"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Origin'''
| align="center" style="background:#f0f0f0;"|'''Destination'''
| align="center" style="background:#f0f0f0;"|'''Description'''
|-
|1.A||Relying Party||Implementation Provider|| An interaction with the Relying party invokes the Implementation Provider (IP).
|-
|1.B||Implementation Provider||Identity Authority||The IP either has an expired certificate, or no certificate, and directs the client to an Identity Authority landing page for authentication. This authentication process is out of scope of the protocol, and implementation dependent.
|-
|1.C||Identity Authority||Identity Authority||Code from the IP landing page invokes genKeyPair() to generate a keypair.
|-
|1.D||Identity Authority||Implementation Provider||The IP saves the keypair in the client
|}

In addition to including the subject, object, operation columns, it can be helpful to include an explicit list of fields which are considered sensitive.

==== Additional Examples ====
* [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID Data-flow Enumeration]

=== Threat Analysis ===

When performing a security review of an application one of the most important components is a threat analysis. There is a great deal of documentation on how to perform threat analysis, and a number of different techniques that can be used:

* [https://www.owasp.org/index.php/Threat_Risk_Modeling OWASP Threat Risk Modelling]
* [http://msdn.microsoft.com/en-us/security/aa570413 Microsoft Application Threat Modelling]
* [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf NIST Risk Management Guide][pdf]

For the purposes of a Mozilla Security Review, the means by which someone identifies the threats and risks associated with an application is important, but not specified. If you have questions about how to perform this type of analysis, please contact a member of our team!

The resulting threat analysis should be formatted in a clear format, including the following details:

* ID - a identifier for the threat
* Title - a concise description of the threat
* Threat - a description of the threat
* Mitigations - a recommendation for a control that can be implemented [1]
* Threat Agent - a list of the potential actors considered that would exploit a vulnerability.
* Notes - Related comments that contribute to the analysis, but don't belong in other columns
* Rating - A qualitative scoring for a vulnerability in the context of this application [2]
* Impact - A qualitative score representing the impact should a vulnerability be exploited
* Likelihood - A qualitative score representing the likelihood of a vulnerability being exploited. [3]

See [https://wiki.mozilla.org/Security/RiskRatings Risk Ratings] for details of how to calculate the qualitative scores.

TODO - Glossary Threat, Threat Agent, Vulnerability, Exploit
[1] In the case of a threat analysis that contains multiple threats that can be resolved by one or more different controls it may be beneficial to include a separate control table, and list references to controls in that table instead.
[2] The rating is calculated by multiplying the impact by the likelihood. This is a naive method, but it's what we have!
[3] In the case where different threat agents have different likelihoods, list the likelihoods highest to lowest, in the same order as the threat agents.

Below is an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model BrowserID Threat Analysis]:

{| border="1" class="fullwidth-table sortable"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Title'''
| align="center" style="background:#f0f0f0;"|'''Threat'''
| align="center" style="background:#f0f0f0;"|'''Proposed Mitigations'''
| align="center" style="background:#f0f0f0;"|'''Threat Agent'''
| align="center" style="background:#f0f0f0;"|'''Rating'''
| align="center" style="background:#f0f0f0;"|'''Likelihood'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
| align="center" style="background:#f0f0f0;"|'''Impact'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
|-
| 1||SIA may introduce compliance issues||Operating a Secondary Identity Authority may induce compliance requirements with regards to logging user information||Part of the goal of BrowserID is to have Primary Identity Authorities take on this risk as part of their other operations. This can be somewhat mitigated by eliminating support for the webfinger verification process.||Governments, Lawyers||12||3||Governments and other legal actors have the ability to request information from us, either through subpoenas, NSLs, etc. While we hold information that can link user identities to services this information will be a source of risk.||4 – Reputation||Although we are required to comply, and Mozilla would fight such a request to the degree permitted, we would still receive negative press.
|-
| 2||Webfinger Information Leak||Use of the webfinger service for verification discloses each authentication attempt from the Relying Party to the Identity Authority||Implement verification using certificates||Malicious Identity Authority||25||5||This information disclosure is a part of the protocol.||5 – Privacy||This is probably a clear violation of our privacy policies.
|-
| 3||Chrome Code Injection||Attacker controlled parameters could permit injection of script into browser chrome.||Ensure that any data controlled by the user or relying party is emitted using output encoding.||Malicious Relying Party, Malicious User, Malicious Identity Authority||4||1||Code review and testing should prevent this occuring. The technical complexity of this attack is higher than a vanilla XSS.||4 – User||This gives an attacker the ability to execute code in the context of browser chrome.
|}

==== Additional Examples ====
* Mozilla F1 Threats [https://wiki.mozilla.org/Security/Reviews/F1#Threat_Model]
* BrowserID Threats [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model]

=== Security Testing ===

The security test plan is a brief explanation of security testing that should be performed, and should include an explanation of what tasks are to be performed, and the approximate amount of time spent performing those tasks.