WebAppSec/Web Security Verification

From MozillaWiki
< WebAppSec
Revision as of 21:21, 16 April 2012 by Mcoates (talk | contribs) (Created page with "Note: This document is currently in draft We should complete this doc and, at a minimum, include all the items from the secure coding guidelines (WebAppSec/Secure Coding Guidelin...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Note: This document is currently in draft We should complete this doc and, at a minimum, include all the items from the secure coding guidelines (WebAppSec/Secure Coding Guidelines - MozillaWiki )

Purpose

This document outlines the application security verification process. These actions are the basic verification steps that will generally apply to all applications. This is a base review standard and should be expanded and customized to the unique application.

Authentication

  1. Does the application support logins?
    1. TLS - Verify the site is entirely HTTPS
    2. TLS - Verify that requests for HTTP URLs redirect to the equivalent HTTPS URL
    3. TLS - Verify that the Http Strict Transport Security flag is set
    4. Error Message - Verify that the error message displayed for an invalid username is the same message displayed for an invalid password
    5. Brute Force - Verify that a captcha is displayed after multiple (standard is 5) failed login attempts
  2. Does the application manage its own set of user credentials?
    1. Verify that the application enforces the appropriate password complexity
    2. Verify a password blacklist is implemented
    3. If possible, verify that passwords are adequately protected in storage (bcrypt+hmac)
    4. If possible, verify that old password hashes are removed from the system
  3. Does the application support administrative logins?
    1. Verify the admin login page is not publicly available
  4. Does the application require an email verification before the account is activated?
    1. Verify that no actions can be taken or stored against the account until the verification link is followed
    2. Verify that the link only verifies ownership of the email account and does not log the user into the system
    3. Verify the code within the verification link is random
    4. Verify that the code within the verification link can not be used for an alternate user id or user account
    5. Verify that the verification code is invalidated after a single use
    6. Verify that the verification code is invalided after 8 hours if it is not used
  5. Does the application provide a forgot password mechanism?
    1. Verify that no information is provided to indicate if a valid username or email address was entered
    2. Verify the code within the verification link is random
    3. Verify that the code within the verification link can not be used for an alternate user id or user account
    4. Verify that the verification code is invalidated after a single use
    5. Verify that the verification code is invalided after 24 hours if it is not used

Session Management

  1. Does the application maintain state via a session identifier?
    1. Verify this session id is the default implementation and not a custom solution
    2. Verify the session identifier is 128-bit or larger
  2. Does the application use cookies for the session identifier?
    1. Verify the SECURE flag is set for the cookies
    2. Verify the HTTPOnly flag is set for the cookies
    3. Verify the PATH and DOMAIN are appropriately set for the cookies
  3. Does the application support logins?
    1. Verify a new session identifier is created for the user upon logging into the application 
    2. Verify that upon logout the session id is expired on the client 
    3. Verify that upon logout the session id is invalidated on the server
    4. Verify that critical applications enforce an inactivity timeout feature
  4. Is session timeout appropriate for this application?
    1. Verify that authenticated sessions time out after a determined period of inactivity (15 minutes is recommended)