WebAppSec/Secure Coding Guidelines

Introduction

The purpose of this page is to establish a concise and consistent approach to secure application development of Mozilla web applications and web services. The information provided here will be focused towards web based applications; however, the concepts can be universally applied to applications to implement sound security controls and design.

This page will largely focus on secure guidelines and may provide example code at a later time.

Status

The secure coding guidelines page is a living document and constantly updated to reflect new recommendations and techniques. Information that is listed is accurate and can be immediately used to bolster security in your application. If you have comments, suggestions or concerns please email mcoates <at> mozilla.com

Layout

The guidelines are discussed within logical security areas. Instead of discussing how to prevent each and every type of attack, we focus on a secure approach to designing an application. Within each section there is a listing of the types of the attacks these controls are geared to protect against. However, this document is not intended to serve as an in-depth analysis of the attack types, rather a guide to creating a secure application.

Easy Quick Wins

Here are a few items that are often missed and are relevant for most every website.

• For all cookies set the HTTPOnly and Secure flag
• Make sure login pages are only served on HTTPS and all authenticated pages are only served on HTTPS
• Don't trust any user data (input, headers, cookies etc). Make sure to validate it before using it

Secure Coding Guidelines

Authentication

Attacks of Concern

• brute force password guessing
• user enumeration
• mass account lockout
• time trade-off hash cracking
• lost passwords

Password Complexity

All sites should have the following base password policy:

• Passwords must be 8 characters or greater
• Passwords must require letters and numbers

Critical Sites

Examples: addons.mozilla.org, bugzilla.mozilla.org, or other critical sites.

Critical sites should add the following requirements to the password policy:

• Besides the base policy, passwords should also require at least one or more special characters.

Global Disallowed Passwords

We should have lists where people pull from where user users can't use these passwords. Right off the bat, we should disallow "password" and anything like it such as "p@$$w0rd".

• http://www.whatsmypass.com/the-top-500-worst-passwords-of-all-time

Password Rotation

Password rotations have proven to be a little tricky and this should only be used if there is lack of monitoring with-in the applications and there is a mitigating reason to use rotations. Reasons being short password, or lack of password controls.

• Privileged accounts - Password for privileged accounts should be rotated every: 90 days.
• General User Account - It is also recommended to implement password rotations for general users if possible.
• Log Entry - an application log entry for this event should be generated.

Account Lockout and Failed Login

Account Lockouts vs login failures should be evaluated based on the application. In both cases, the application should be able to determine if the password being used is the same one over and over, or a different password being used which would indicate an attack.

The error message for both cases should be generic such as:

Invalid login attempts (for any reason) should return the generic error message

 The username or password you entered is not valid

Logging will be critical for these events as they will feed up into our security event system and we can then take action based on these events. The application should also take action. Example would be in the case that the user is being attacked, the application should stop and/or slow down that user progress by either presenting a captcha or by doing a time delay for that IP address.

Password Reset Functions

The password reset page will accept the username and then send an email with a password reset link to the stored email address for that account.

The following message should be returned to the user regardless if the username or email address is valid:

 An email has been sent to the requested account with further information. If
 you do not receive an email then please confirm you have entered the same   
 email address used during account registration.

We do not want to provide any information that would allow an attacker to determine if an entered username/email address is valid or invalid. Otherwise an attacker could enumerate valid accounts for phishing attacks or brute force attack.

Password Storage

CURRENT STANDARD

• Passwords stored in a database should use the following format that leverages secure hashing and a per user salt.

 * Every new password stored in a form like {algo}${salt}${hash}
   * {algo} is {sha512},
   * {salt} is a salt unique per-user,
   * {hash} is algo(salt + password)

PROPOSED STANDARD

Separate from the password policy, we should have the following standards when it comes to storing passwords

• Passwords stored in a database should use the following format.
• Private salt of 20 chars in addition to the per user salt
• Private salt would be system only and not stored with user hash or in the databases.
• Need the ability to change/rotate hashes

It would look something like this:

 * Authentication:
   * hash = sha512(userSalt + userPassword + privateSystemSalt[saltVersion])

 * Storage
   * {algo}${userSalt}${hash}${index}
   * sha512$1234asbfe$1f40fc92da241694750979ee6cf582f2d5d7d28e18335de05abc54d0560e0f5302860c652bf08d560252aa5e74210546f369fbbbce8c12cfc7957b2652fe9a75$2011-01-11

 * privateSystemSalt examples
   * privateSystemSalt["2010-10-13"] = "01234567890123456789"; // legacy 
   * privateSystemSalt
   * privateSystemSalt["2011-01-01"] = "214bg423df214bg423df"; // legacy
   * privateSystemSalt 2
   * privateSystemSalt["2011-01-11"] = "^&*FDF3fc_^&*FDF3fc_"; // current 
 

Background

I have data on why we are not using bcrypt or something like it. This will be published shortly.

Migration

The following process can be used to migrate an application that is using a different hashing algorithm than the standard hash listed above. The benefits of this approach is that it instantly upgrades all hashes to the strong, recommended hashing algorithm and it does not require user's to reset their passwords.

Migration Process
Migrate all password hashes entries in the database as follows. This is a one time, offline migration.

Stored in databases in form: {algo}${salt}${migration_hash}

   * {algo} is {sha512+MD5},
   * {salt} is a salt unique per-user,
   * {migration_hash} is SHA512(salt + existingPasswordHash)

New hash process for new accounts or password changes
Use standard hashing process [above]

New Login Process
1. Attempt to login user with migration hash. This involves performing the old password hash procedure then adding the salt and finally performing the sha512.

Example: Old password hash process is md5
Migration Hash = sha512(perUserSalt + md5(user supplied password))

2. If authentication via migration hash is successful:

- Use the user's provided password and calculate the New Hash per the algorithm defined above.

- Overwrite the Migration Hash with the New Hash

3. If authentication via migration hash is NOT successful:

- The user may already be on the New Hash. Attempt to directly authenticate using the new hash. If this fails, then the password provided by the user is wrong.

---

<old process below - to be removed>

• If upgrading from an existing scheme such as md5 hashing with no-salt, then a conversion process can be established. This conversion will occur whenever a user logs into the system. First attempt to authenticate the user via the above scheme (e.g. unique salt and sha-512). If that fails then authenticate via the old scheme (e.g. md5) and create a new hash in the above scheme(e.g. unique salt and sha-512). Remember to also clear out the old hash value after the conversion is complete for the user.
• After a six month period of changing from md5 to sha-512, all md5 hash entries should be cleared from the system.
• As part of the password storage and user table, the last password change and last login should be included in the table for tracking.

Session Management

Attacks of Concern: Session Hijacking, Session Fixation, Brute Forcing Valid Session IDs

Session ID Length

Session tokens should be 128-bit or greater

Session ID Creation

The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.

Inactivity Time Out

Authenticated sessions should timeout after determined period of inactivity - 15 minutes is recommended

Secure Flag

The "Secure" flag should be set during every set-cookie. This will instruct the browser to never send the cookie over HTTP. The purpose of this flag is to prevent the accidental exposure of a cookie value if a user follows an HTTP link.

Code Examples

HTTP-Only Flag

The "HTTP-Only" flag should be set to disable malicious script access to the session ID (e.g. XSS)

Logout

Upon logout the session ID should be invalidated on the server side and deleted on the client via expiration/overwriting the value.

Access Control

Attacks of Concern Enumeration of site features for targeted attacks, Execution of unauthorized functionality, View or modify unauthorized data

Presentation Layer

Display Features and Functions Granted to User

It is recommended to not display links or functionality that is not accessible to a user. The purpose is to minimize unnecessary access controls messages and minimize privileged information from being unnecessarily provided to users.

Business Layer

Check Access Control Before Performing Action

Ensure that an access control check is performed before an action is executed within the system. A user could craft a custom GET or POST message to attempt to execute unauthorized functionality.

Data Layer

Check Access Control with Consideration of Targeted Data

Ensure that an access control check also verifies that the user is authorized to act upon the target data. Do not assume that a user authorized to perform action X is able to necessarily perform this action on all data sets.

Input Validation

Attacks of Concern: Introduction of Dirty/Malformed Data

Goal of Input Validation

Input validation is performed to minimize malformed data from entering the system. Input Validation is NOT the primary method of preventing XSS, SQL Injection. These are covered in output encoding below.

Input Validation Must Be:

• Applied to all user controlled data
• Define the types of characters that can be accepted (often U+0020 to U+007E, though most special characters could be removed and control characters are almost never needed)
• Defines a minimum and maximum length for the data (e.g. {1,25} )

Examples of Good Input Validation Approaches For each field define the types of acceptable characters and an acceptable number of characters for the input

• Username: Letters, numbers, 3 to 10 characters
• Firstname: Letters, single apostrophe, 1 to 30 characters
• Simple Zipcode: Numbers, 5 characters

JavaScript vs Server Side Validation

Be aware that any JavaScript input validation can be bypassed by an attacker that disables JavaScript or uses a Web Proxy. Ensure that any input validation performed by JavaScript is also performed server side as well.

Positive Approach

The variations of attacks are enormous. Use regular expressions to define what is good and then deny the input if anything else is received. In other words, we want to use the approach "Accept Known Good" instead of "Reject Known Bad"

 Example A field accepts a username. A good regex would be to verify 
 that the data consists of the following [0-9a-zA-Z]{3,10}. The data 
 is rejected if it doesn't match.  

 A bad approach would be to build a list of malicious strings and then 
 just verify that the username does not contain the bad string. This 
 approach begs the question, did you think of all possible bad strings?

Robust Use of Input Validation

All data received from the user should be treated as malicious and verified before using within the application. This includes the following

• Form data
• URL parameters
• Hidden fields
• Cookie data
• HTTP Headers
• Essentially anything in the HTTP request

Validating Rich User Content

It is very difficult to validate rich content submitted by a user. Consider more formal approaches such as HTML Purifier (PHP) or AntiSamy or bleach (Python)

Output Encoding

Output encoding is the primary method of preventing XSS and injection attacks. Input validation helps minimize the introduction of malformed data, but it is a secondary control.

Attacks of Concern: Cross Site Scripting, SQL/OS/LDAP/XML Injection

Preventing XSS

• All user data controlled must be encoded when returned in the html page to prevent the execution of malicious data (e.g. XSS). For example <script> would be returned as &lt;script&gt;
• The type of encoding is specific to the context of the page where the user controlled data is inserted. For example, HTML entity encoding is appropriate for data placed into the HTML body. However, user data placed into a script would need JavaScript specific output encoding

Detailed information on XSS prevention here: OWASP XSS Prevention Cheat Sheet

Preventing SQL Injection

• String concatenation to build any part of a SQL statement with user controlled data creates a SQL injection vulnerability.
• Parameterized queries are a guaranteed approach to prevent SQL injection.
• It's not realistic to always know if a piece of data is user controlled, therefore parameterized queries should be used whenever a method/function accepts data and uses this data as part of the SQL statement.

Further Reading: SQL Injection Prevention Cheat Sheet

Preventing OS Injection

• Avoid sending user controlled data to the OS as much as possible
• Ensure that a robust escaping routine is in place to prevent the user from adding additional characters that can be executed by the OS ( e.g. user appends | to the malicious data and then executes another OS command). Remember to use a positive approach when constructing escaping routinges. Example

Further Reading: Reviewing Code for OS Injection

Preventing XML Injection

• Same approach as OS injection. In addition to the existing input validation, define a positive approach which escapes/encodes characters that can be interpreted as xml. At a minimum this includes the following: < > " ' &

• If accepting raw XML then more robust validation is necessary. This can be complex. Please contact the infrastructure security team for additional discussion

Cross Domain / Unintended User Actions

Attacks of Concern: Cross Site Request Forgery (CSRF), Malicious Framing (Clickjacking), 3rd Party Scripts

Preventing CSRF

An attacker creates a self posting form or image tag which executes an action on behalf of the authenticated user. Read more about this attack type here

• Any state changing operation requires a secure random token (e.g CSRF token) to prevent against CSRF attacks
• Characteristics of a CSRF Token
  • Unique per user & per user session
  • Large random value
  • Generated by a cryptographically secure random number generator
• The CSRF token is added as a hidden field for forms or within the URL if the state changing operation occurs via a GET
• The server rejects the requested action if the CSRF token fails validation

Note: Some frameworks (such as django) provide this capability. Use the established CSRF protection from the framework instead of creating your own.

Preventing Malicious Site Framing (ClickJacking)

A newer attack that uses page layering and framing to convince the user to click or enter data on particular parts of the screen. These actions are actually sent to the framed site to perform actions unbeknown to the victim user. Read more about this attack type here

Set the x-frame-options header for all responses containing HTML content. The possible values are "DENY" or "SAMEORIGIN".

• DENY will block any site (regardless of domain) from framing the content.
• SAMEORIGIN will block all sites from framing the content, except sites within

the same domain.

The "DENY" setting is recommended unless a specific need has been identified for framing.

Code Examples

3rd Party Scripts

• Careful consideration should be used when using third party scripts. While I am sure everybody would do an initial review, updates to scripts should be reviewed with the same due diligence.
• Ensure any scripts that are used are hosted locally and not dynamically referenced from a third party site.

Secure Transmission

Attacks of Concern: Man in the middle, password theft, session id theft

When To Use SSL/TLS

• All points from the login page to the logout page must be served over HTTPS.
• Ensure that the page where a user completes the login form is accessed over HTTPS. This is in addition to POST'ing the form over HTTPS.
• All authenticated pages must be served over HTTPS. This includes css, scripts, images. Failure to do so creates a vector for man in the middle attack and also causes the browser to display a mixed SSL warning message.

Don't Allow HTTP Access to Secure Pages

• Never provide an authenticated page or a login page over HTTP. HTTPS should be used for the login landing page and all subsequent authenticated pages.
• The most secure approach is to display a warning when a user requests the HTTP page to instruct the user to bookmark or type the HTTPS page for future use. However, the more common approach is to just redirect from the HTTP request to the HTTPS equivalent page.

More info on SSL/TLS design can be found here

Implement STS

Where possible, we should utilize STS headers.

Logging

See Security/Users_and_Logs

Admin Login Pages

The following are generally blockers for any website using an admin page:

1. Controls are in place to prevent brute force attacks
Options (any of these are fine):

• Account Lockout
• CAPTCHA's after 5 failed logins
• IP restrictions for access to the admin page

2. The login page and all admin pages are exclusively accessed over HTTPS. Any attempts to access a HTTP page redirect to HTTPS

3. The session id uses the SECURE flag

4. The session id uses the HTTPOnly flag

Configuring Worpress Admin Pages Securely

Uploads

Attacks of Concern: Malformed user uploads containing JavaScript, HTML or other executable code, Arbitrary file overwrite

General Uploads

Upload Verification

• Use input validation to ensure the uploaded filename uses an expected extension type
• Ensure the uploaded file is not larger than a defined maximum file size

Upload Storage

• Use a new filename to store the file on the OS. Do not use any user controlled text for this filename or for the temporary filename.
• Store all user uploaded files on a separate domain (e.g. mozillafiles.net vs mozilla.org). Archives should be analyzed for malicious content (anti-malware, static analysis, etc)

Public Serving of Uploaded Content

• Ensure the image is served with the correct content-type (e.g. image/jpeg, application/x-xpinstall)

Beware of "special" files

• The upload feature should be using a whitelist approach to only allow specific file types and extensions. However, it is important to be aware of the following file types that, if allowed, could result in security vulnerabilities.

• "crossdomain.xml" allows cross-domain data loading in Flash, Java and Silverlight. If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks. Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named "crossdomain.xml" or "clientaccesspolicy.xml".

• ".htaccess" and ".htpasswd" provides server configuration options on a per-directory basis, and should not be permitted. See http://en.wikipedia.org/wiki/Htaccess

Image Upload

Upload Verification

• Use image rewriting libraries to verify the image is valid and to strip away extraneous content.
• Set the extension of the stored image to be a valid image extension based on the detected content type of the image from image processing (e.g. do not just trust the header from the upload).
• Ensure the detected content type of the image is within a list of defined image types (jpg, png, etc)

Archive Uploads

Upload Verification

• Ensure that the decompressed size of each file within the archive is not larger than a defined maximum size
• Ensure that an uploaded archive matches the type expected (e.g. zip, rar, gzip, etc)
• For structured uploads such as an add-on, ensure that the hierarchy within the archive contains the required files

Further Reading

OWASP Top 10

Php Sec Library

Django Security

Contributors

Michael Coates - mcoates [at] mozilla.com
Chris Lyon - clyon [at] mozilla.com