Confirmed users
9,511
edits
WebAppSec/Secure Coding QA Checklist: Difference between revisions
WebAppSec/Secure Coding QA Checklist (view source)
Revision as of 20:34, 11 February 2016
, 11 February 2016no edit summary
No edit summary |
|||
| (13 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
=Author= | |||
Michael Coates - mcoates [at] mozilla.com - no longer with Mozilla | |||
= Status = | = 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 = | = Purpose = | ||
| Line 12: | Line 16: | ||
= Secure Coding QA Checklist = | = Secure Coding QA Checklist = | ||
== Test: Input Validation For User Controlled Data == | == Test: Input Validation For User Controlled Data == | ||
| Line 112: | Line 115: | ||
==='''Test'''=== | ==='''Test'''=== | ||
Are CSRF tokens or crumbs required whenever a user performs an action in the system. | 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=== | ===Testing Scope=== | ||
| Line 118: | Line 128: | ||
===Desired System Behavior=== | ===Desired System Behavior=== | ||
A random CSRF token | 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=== | ===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 | '''Whiteboard Code:''' infrasec-qa:auth | ||
| Line 135: | Line 153: | ||
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. | 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. | 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= | =Other Resources= | ||