Secure Coding Cheat Sheet

= DRAFT CHEAT SHEET - WORK IN PROGRESS = = Introduction = The goal of this document is to create a high level guideline for secure coding practices within an application. The material is concise and the goal is to keep the overall size of the document condensed and easy to digest. = How To Use This Document = The information listed below are generally acceptable secure coding practices; however, it is recommend that organizations consider this a base template and update individual sections with secure coding recommendations specific to the organization's policies and risk tolerance. = Authentication=

Password Complexity
Applications should have a password complexity requirement of:
 * Passwords must be 8 characters or greater
 * Passwords must require 3 of the following 4 character types [upper case letters, lower case letters, numbers, special characters]

Password Rotation
Password rotation should be required for privileged accounts within applications at a frequency of every 90 days

Online Attack Guessing
Applications must defend against online password guessing attempts by one of the following methods:
 * Account Lockout - Lock account after 5 failed password attempts
 * Temporary Account Lockout- Temporarily lock account after 5 failed password attempts
 * Anti-automation Captcha - Require a captcha to be successfully completed after 5 failed password attempts

Email Verification Functions
If the application requires verification of ownership of an email address then observe the following
 * Email verification links should only satisfy the requirement of verify email address ownership and should not provide the user with an authenticated session (e.g. the user must still authenticate as normal to access the application).
 * Email verification codes must expire after the first use or expire after 8 hours if not used.

Password Storage

 * Passwords should be stored in a format, such as Bcrypt, that is resistant to high speed offline brute force attacks
 * Password storage using hashing algorithms plus a per user salt are good, but not sufficient.

= Session Management =

Session ID Length

 * Session tokens should be 128-bit or greater

Session ID Creation

 * The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.

Inactivity Time Out

 * Authenticated sessions should timeout after determined period of inactivity - 15 minutes is recommended.

Secure Flag

 * The "Secure" flag should be set during every set-cookie. This will instruct the browser to never send the cookie over HTTP. The purpose of this flag is to prevent the accidental exposure of a cookie value if a user follows an HTTP link.

HTTP-Only Flag

 * The "HTTP-Only" flag should be set to disable malicious script access to the cookie values, such as the session ID

Logout
= Access Control =
 * Upon logout the session ID should be invalidated on the server side and deleted on the client via expiring and overwriting the value.

Presentation Layer

 * It is recommended to not display links or functionality that is not accessible to a user. The purpose is to minimize unnecessary access controls messages and minimize privileged information from being unnecessarily provided to users.

Business Layer

 * Ensure that an access control verification is performed before an action is executed within the system. A user could craft a custom GET or POST message to attempt to execute unauthorized functionality.

Data Layer

 * Ensure that an access control verification is performed to check that the user is authorized to act upon the target data. Do not assume that a user authorized to perform action X is able to necessarily perform this action on all data sets.

= Input Validation =

Goal of Input Validation
Input validation is performed to minimize malformed data from entering the system. Input Validation is NOT the primary method of preventing XSS, SQL Injection. These are covered in output encoding below.

Input Validation Must Be:
 * Applied to all user controlled data
 * Define the types of characters that can be accepted (often U+0020 to U+007E, though most special characters could be removed and control characters are almost never needed)
 * Defines a minimum and maximum length for the data (e.g. {1,25} )

File Upload
= Output Encoding =

Preventing XML Injection
= Cross Domain Request Forgery =

Connecting with Twitter, Facebook, etc
= Secure Transmission =