WebAppSec/Secure Coding QA Checklist

From MozillaWiki
Jump to: navigation, search

Author

Michael Coates - mcoates [at] mozilla.com - no longer with Mozilla


Status

The Secure Coding QA Checklist 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 enhance security QA testing of your application. If you have comments, suggestions or concerns please email mcoates <at> mozilla.com

Purpose

Security is an important element of every step of the development life cycle. This document identifies 5 security tests which are now incorporated into the QA phase of development.

Note: this is not the only phase where security is verified in the application. Security is integrated throughout the development life-cycle and this document references the particular security tests performed during QA.

Layout

The questions are designed such that "YES" is good (e.g. the desired outcome) and "NO" is bad (e.g. further discussion or code changes needed).

Secure Coding QA Checklist

Test: Input Validation For User Controlled Data

Whiteboard Code: infrasec-qa:input

Test

Do all areas that accept user data properly handle unexpected data such as:

  • special characters (examples: < > $ % ^ ; & ' " )
  • values other than the default items (e.g. letters if the URL argument is normally a number)

Testing Scope

  • Input Form Fields
  • Hidden Variables
  • URL Parameters

Desired System Behavior

Whenever unexpected data is received by the application the application will gracefully handle the situation and not return a stack trace or display detailed system information to the user.

Invalid form data should result in a message to the user explaining how to complete the form correctly. Unexpected data in hidden fields or the URL should result in more generic messages such as 

 The requested operation could not be performed

Further information

Applications frequently implement good input validation controls on user forms but forgot to apply the same rigor to URL parameters or hidden fields - especially locations that are not normally modified by the user.

Examples

  1. A form field accepts a first and last name. A user enters the following special characters !@#$%^&* into the fields and the application accepts the data. This is not the desired result. There is no need for these types of characters in a name.
  2. The following URL is used by the application
    https://test.site.com/list.cgi?format=advanced&desc=test&desc_type=4
    This URL could be tested by entering special characters and numbers in place of the values 'advanced', 'test' and '4'. In each case the application should gracefully handle the unexpected data
  3. An HTML form posts uses a hidden field to submit data. Tamper with the hidden field as indicated in example 2. The application should gracefully handle the unexpected data.

Test: SQL Injection

Whiteboard Code: infrasec-qa:sql

Test

Is user supplied data that is used for SQL statements safely handled by the application to prevent SQL injection?

Testing Scope

Fields used for SQL searches or updates such as search boxes or profile data

Desired System Behavior

The system safely handles the data and does not generate any type of error.

Further information

Try inserting the following data. The system should not generate any errors except for an input validation error indicating the data type is incorrect for the field. Any type of database error message or stack trace indicates an SQL Injection problem 

For forms, hidden fields, cookies:
'
' OR '1'='1
' OR '1'='1'--

For URL arguments:
%27
%27+OR+%271%27%3D%271
%27+OR+%271%27%3D%271%27--

Test: Output Encoding For User Controlled Data

Whiteboard Code: infrasec-qa:xss

Test

Is user supplied data output encoded within the HTML response to prevent XSS attacks?

Testing Scope

  • Areas where a user can enter data that is immediately returned in the html response (e.g. search box)
  • Areas where a user can enter data that is returned on a future page (e.g. profile or status message)

Desired System Behavior

The system will safely convert characters so they can be displayed without concerns for XSS.

Further information

Use these following basic tests to identify lack of proper output encoding. More rigorous tests will be performed by infrasec during our testing to further validate the output encoding controls.

Enter the following into input fields or URL arguments. If any of the html renders (e.g. popup box appears, you see the horizontal lines or iframes) then there is a problem. 

For Fields:
"'><script>alert('problem')</script>
"'><hr><hr><hr>
"'><iframe src="http://google.com"></iframe>

For URL Arguments (same tests, just URL encoded):
%22%27%3E%3Cscript%3Ealert%28%27problem%27%29%3C%2Fscript%3E
%22%27%3E%3Chr%3E%3Chr%3E%3Chr%3E
%22%27%3E%3Ciframe+src%3D%22http%3A%2F%2Fgoogle.com%22%3E%3C%2Fiframe%3E

Default Recommendation

Recommended Remediation

Utilize output encoding, such as HTML entity output encoding, to safely display the user supplied data as text. This approach will ensure that any data entered by the user will be interpreted as benign text and not HTML that should be rendered by the browser. In addition, enhance the input validation where the user supplied data enters the system to only accept the minimal types of characters required (i.e. should the user be allowed to enter special characters in this field to begin with).

Test: CSRF

Whiteboard Code: infrasec-qa:csrf

Test

Are CSRF tokens or crumbs required whenever a user performs an action in the system? A CSRF token/crumb is typically included as a hidden field and will contain a seemingly random number. There is not standard naming convention for this value. It may appear as "CSRFToken", "Crumb", "formToken" or something similar.

Example: 

 <form action="site.com/update" method="post">
 <input id="crumb" name="crumb" type="hidden" value="AirJvJaQ0RlLkFbx-1279485485.7191-2dc12b55eed8e310fae2f9ae3cd625cdc8fd83a681c8ea6eacfb3fb059bae" />
 ...
 </form>

Testing Scope

  • All state changing operations such as updating data, saving information or initiating actions

Desired System Behavior

A random CSRF token/crumb is required when submitting an update action to the server. Further, if a user modifies the token/crumb then the application will reject the action requested by the user.

Further information

There are two tests for CSRF tokens/crumbs. Is a CSRF token/crumb used at all for the POST? If so, does the server validate that the token/crumb is correct?

These tests would need to be performed on each form within the application.

The first issue can be verified by viewing the page source and looking at the form element or by intercepting the POST request an inspecting the submitted values. In either case you should see a hidden field called "CSRFToken" or "crumb" (or something similar) and the value will be a large random series of characters and numbers. If you do not see this random value, then we have a finding.

The second issue can be verified by modifying the token/crumb to any other value. Try replacing the value with "123". The application should either return an error message or just not perform the action that you requested with that form. If the application does perform the requested action with the "123" token value then we have a finding.

Test: Account Lockout -- INACTIVE

Note: We are altering the process for handling account lockout.

Whiteboard Code: infrasec-qa:auth

Test

Is an account locked out for at least one hour after 5 incorrect password attempts? If not locked out, is some method in place to prevent an automated password guessing attack (for example CAPTCHA).

Testing Scope

  • Login Page

Desired System Behavior

The system locks the account for at least 1 hr after 5 failed login attempts. This can be easily tested by providing 5 incorrect passwords and then providing the correct password for the 6th try. The account should be locked and the 6th attempt should be denied access.

Alternatively a site could require a user to complete a CAPTCHA before continuing to authenticate. The CAPTCHA should be presented to the user after 5 incorrect password attempts.

Test: X-Frame-Options

Whiteboard Code: infrasec-qa:crossdomain

Test

Is the X-Frame-Options header used to prevent malicious framing of the website?

Testing Scope

  • All HTML pages on the site. Supporting content, such as css, js, or images do not need to have the X-Frame-Options header.

Desired System Behavior

The X-Frame-Options header is present for all HTML pages on the website. The specified value of "DENY" or "SAMEORIGIN" is a decision made by the application owners. Either value is acceptable for this test.

Further information

This item can be tested by requesting several pages within the application and inspecting the HTTP response. Look for the header value "X-Frame-Options". Below is an example of an HTTP response for a site using this header: 

 HTTP/1.1 200 OK
 Server: Apache
 X-Frame-Options: SameOrigin
 Vary: Accept-Encoding
 Cache-Control: no-cache
 Content-Type: text/html; charset=utf-8

Other Resources

No need to do anything with these documents. Just provided for additional reading if desired.

Security Verification Checklist

Secure Coding Guidelines

Retrieved from "https://wiki.mozilla.org/index.php?title=WebAppSec/Secure_Coding_QA_Checklist&oldid=1116878"