Personal tools

WebAppSec/Web Security Verification

From MozillaWiki

Jump to: navigation, search

Please also see the Secure Coding Guidelines document

Contents

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)


Access Control

  1. Does the application support multiple users?
    1. Verify that two users within the same role cannot execute functionality on behalf of the other account
    2. Verify that two users within the same role cannot access or edit data on behalf of the other account
  2. Does the application support multiple roles?
    1. Verify that a user within one role cannot view features or functionality not available to the user
    2. Verify that a user within one role cannot execute functionality reserved for a different role
    3. Verify that a user within one role cannot access or edit data reserved for a different role

Input Validation

  1. Does the application accept user input?
    1. Verify a sampling of input locations to ensure that reasonable maximums are in place when accepting user data
    2. Verify a sampling of input locations to ensure that the application allows only a defined set of acceptable characters
    3. Verify a sampling of input locations to ensure that the application is not relying solely on JavaScript validation
  2. Does the application accept user input that is later viewable or returned to the user within a HTTP response?
    1. Verify a sampling of input and output locations to ensure user supplied content is properly encoded in the response
  3. Does the application accept rich user content?
    1. Is HTML Purifier / AntiSamy / Bleach / Equivalent being used?
  4. Input Encoding
    1. Verify that the application rejects invalid encoding (e.g. UTF-7 encoded content submitted in a UTF-8 request)
    2. Verify that the application rejects double encoded data, or properly decodes user input before applying validation or sanitization code

Output Encoding

  1. Does the application send any untrusted data to the user's browser?
    1. Verify that robust input validation is in place
    2. Verify that all user controlled data is appropriately encoded; this is context dependent:
      1. HTML element content - the data must be HTML encoded
      2. HTML attributes - the data must be HTML attribute encoded
      3. HTML style attributes:
        • data must only be placed into property values
        • the value must not contain 'expression'
        • the value must be CSS escaped
      4. URLs - the scheme must be whitelisted, the URL must be URL escaped
      5. Script - data must only be placed in quoted values and must be script encoded
    3. Verify that all escaping and encoding routines escape / encode by default and have a whitelist for 'allowed' characters
  2. Does the application send any untrusted data to a SQL database?
    1. Verify robust input validation is in place
    2. Verify that, if available on the target platform, only parameterized SQL queries are used:
      1. Should parameterized queries not be available, ensure that database platform specific escaping is performed on all untrusted data.
  3. Does the application invoke any OS commands?
    1. Verify that, where possible, user input is not sent to the OS at all
    2. If user data is sent to the OS:
      1. Verify that robust input validation is in place
      2. Verify that a robust escaping routine is in place to ensure special characters don't get to the command interpreter. Any escaping routine will need to be OS specific.

Cross-Domain

  1. Does every state change require a CSRF Token?
    1. Verify that the same request without token will not succeed
    2. Verify that changing the HTTP method verb will be rejected
    3. Verify that CSRF tokens are
      • unique per user
      • random
      • contain enough entropy to be unpredictable
      • in a hidden field for form-elements
  2. Cross-Framing / Clickjacking
    1. Verify that X-Frame-Options is set to DENY or SAMEDOMAIN
  3. Third-Pary Scripts
    1. Verify that JavaScript from third party is locally hosted
    2. Verify that this script is reviewed
  4. Third-Party Code Snippets (Tweet this, Like This etc.)
    1. Verify that the whole communication is using HTTPS
    2. Verify that authenticated content is only presented using HTTPS
    3. Verify that simply loading said snippets does not perform requests to the third party (Privacy)
    4. OAUTH
      • Verify that the initial form and further traffic is sent only via HTTPS
  5. For Cross Origin Resource Sharing (CORS) see Cross Origin Resource Sharing & Access-Control headers


Secure Transmission

  1. Does the web application support authenticated sessions?
    1. Verify all points from the login page to logout are served over HTTPS
    2. If the application handles its own logins:
      • Verify that any login pages are served over HTTPS
      • Verify that any login pages POST login data HTTPS
    3. Verify that all resources for HTTPS pages are also served over HTTPS
    4. Verify for all pages served over HTTPS (detailed above) that the resource is not also accessible over HTTP
    5. Verify the application uses STS headers
  2. Does the application use a thick client for access instead of a client browser?
    1. Verify that invalid certificates are appropriately rejected
    2. Verify that user supplied credentials are not insecurely stored on the client device.
  3. Is SSL deployed correctly?
    1. Verify the following, see https://www.owasp.org/index.php/Testing_for_SSL-TLS_(OWASP-CM-001)
      • SSLv3 or TLS only - no SSLv2
      • Check for SSL renegotiation bug
      • Verify that no connections <128 bit are allowed
      • Verify that no Export-strength algorithms are enabled on the server

Content-Security Policy

  1. If the website is already using CSP
    1. Verify that the policy is appropriately scoped and restrictive
      • Verify that the policy is present and working
      • Verify that not everything is whitelisted
      • Verify that CSP violations will lead to a report in staging/development mode and that these reports will be reviewed
      • Verfiy that CSP violations will lead to a block in production mode
      • Verfiy that the whitelisted sites for static content (like JavaScript, CSS, Images, Fonts) do not generate dynamic content, which might be subject to misuse
  2. If the website is not, but plans to do so
    1. Verify that contents like CSS and JavaScript are not inline
    2. Verify that CSS, JavaScript, Images, Fonts are hosted on a specific domain which gives out static content only

Logging

  1. General Logging
    1. Verify that a standard logging format or library is used
    2. Verify that logging levels are configurable
    3. Verify that log entries have a reasonable constraint on size
    4. Verify that log storage paths are not accessible to the public
  2. Log Injection
    1. Verify that no string formatting functions are invoked after integration of user controlled data
    2. Verify that user controlled data is sanitized or passed through an explicit whitelist
    3. Verify that binary data is encoded in a text format such as Base64
  3. Verify that these events are logged
    1. Access Denied
    2. Admin Account Password Reset Request
    3. Admin Account Password change
    4. New admin account created

Admin login pages

  1. Bruteforcing the authentication parameters is blocked by one of the following methods
    1. Admin login only accessible via SSL-VPN
    2. Account lockout
    3. acccess to admin login restricted to a whitelisted IP
    4. verify that 5 failed logins requires the user to solve a captcha
  2. Verify that web pages for login and admin are accessible only via HTTPS
  3. Verify that the Session cookie set to httponly and secure

Uploads

  1. General uploads
    1. Verify that filenames are generated randomly via a process that will not result in path control characters, and do not contain any user input
    2. Make sure all OS calls are made in a command-safe way, such as the following:
    3. Verify maximum file size is limited
    4. Verify that only the expected file types are working
      • Verify that only a white list of known extensions are accepted
      • Verify that a library such as libmagic is used to analyze the contents of files to match binary file formats with approved file formats
    5. Verify that the files are served from a different domain
    6. Verify that platform sensitive formats (such as Python pickle) are not processed using unsafe API that could result in the file being processed
    7. Verify that files uploaded cannot be invoked as scripts on the server (e.g. python, php, javascript, etc)
  2. Verify that images are
    1. Read
    2. Validated
      • Test with oversized images, overly large dimensions, or bogus files
      • Filename/minetype should be tested to verify matching file content
    3. Stripped of metadata (i.e. EXIF, XMP, IIM, etc - see http://en.wikipedia.org/wiki/Metadata#Photographs)
    4. Written back to disk, as described in "general uploads"
  3. Archives
    1. Verify that decompressed maximum size is limited
    2. Verify that file extension and detected filetype match
    3. For structural requirements (e.g. AddOns): Verify file hierarchy
    4. Verify that password protected or encrypted archives are rejected
    5. Verify that nested archives are rejected

Error handling

  1. Verify that error pages (e.g. 404 and 500) do not contain sensitive information (path, system status or setup information, debug messages)
  2. Verify that global debug mode is disabled
  3. Verify that user input in error messages is correctly encoded (XSS) and newlines are not written to text files as is.

Encryption

  1. Add checklists for
    1. Encrypted tokens
    2. symmetric
      • algorithm
      • implementation
    3. asymmetric
      • algorithm
      • implementation
    4. hashing/hmac
    5. key storage

Existing OWASP checkist: https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet