MozillaWiki

WebAppSec/Secure Coding QA Checklist

< WebAppSec
Revision as of 18:46, 12 July 2010 by Mcoates (talk | contribs) (Created page with ' = Status = This document is a '''Release''' version and is actively being referenced. = Purpose = Security is an important element of every step of the development life cycle…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Status

This document is a Release version and is actively being referenced.

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.

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.

Testing Scope

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

Desired System Behavior

A random CSRF token or crumb is required. If the request is submitted without the token or with a modified token then the application does not process the requested event.

Further information

This can be tested by using tamperdata or webscarab and modifying the crumb before the request is sent to the application.

Test: 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.

Other Resources

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

Security/Security_Verification_Checklist

Security/Secure_Coding_Guidelines

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