This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Secure Coding Cheat Sheet"
From OWASP
m (Created page with "= DRAFT CHEAT SHEET - WORK IN PROGRESS = = Authentication= == Password Complexity == == Password Rotation == == Account Lockout and Failed Login == == Password Reset Functions =...") |
|||
| Line 1: | Line 1: | ||
= DRAFT CHEAT SHEET - WORK IN PROGRESS = | = 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= | = Authentication= | ||
== Password Complexity == | == 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 == | ||
| − | + | Password rotation should be required for privileged accounts within applications at a frequency of every 90 days | |
| − | == Account Lockout | + | == 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 | ||
== Password Reset Functions == | == Password Reset Functions == | ||
| − | == Email | + | == 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 == | == 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 Management = | ||
== Session ID Length == | == Session ID Length == | ||
| + | * Session tokens should be 128-bit or greater | ||
== Session ID Creation == | == 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 == | == Inactivity Time Out == | ||
| + | * Authenticated sessions should timeout after determined period of inactivity - 15 minutes is recommended. | ||
== Secure Flag == | == 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 == | == 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 == | == Logout == | ||
| − | + | * Upon logout the session ID should be invalidated on the server side and deleted on the client via expiring and overwriting the value. | |
= Access Control = | = Access Control = | ||
== Presentation Layer == | == 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 == | == 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 == | == 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 = | = Input Validation = | ||
== Goal of 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} ) | ||
== JavaScript vs Server Side Validation == | == JavaScript vs Server Side Validation == | ||
== Positive Approach == | == Positive Approach == | ||
Revision as of 05:05, 17 November 2011
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
Password Reset Functions
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
- Upon logout the session ID should be invalidated on the server side and deleted on the client via expiring and overwriting the value.
Access Control
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} )
JavaScript vs Server Side Validation
Positive Approach
Robust Use of Input Validation
Validating Rich User Content
File Upload
Output Encoding
Preventing XSS and Content Security Policy
Preventing SQL Injection
Preventing OS Injection
Preventing XML Injection
Cross Domain Request Forgery
Preventing CSRF
Preventing Malicious Site Framing (ClickJacking)
3rd Party Scripts
Connecting with Twitter, Facebook, etc
Secure Transmission
When To Use SSL/TLS
Don't Allow HTTP Access to Secure Pages
Implement STS
References
OWASP Cheat Sheets Project Homepage
