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.

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

• BrowserID Protocol High Level
• 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.

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

• Mozilla F1 Detailed Application Diagram
• BrowserID Protocol
• 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 BrowserID provisioning enumeration, the subject, object, and operation are labelled origin, destination, and description, respectively.

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

• 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:

• OWASP Threat Risk Modelling
• Microsoft Application Threat Modelling
• 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 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 BrowserID Threat Analysis:

Additional Examples

• Mozilla F1 Threats [1]
• BrowserID Threats [2]

Security Testing