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 "OWASP Cheat Sheet Series"
m (Update project information format) |
m (Remove duplicate Classifications section) |
||
Line 76: | Line 76: | ||
* [Apr 04 2014] All non-draft cheat sheets moved to new wiki template! | * [Apr 04 2014] All non-draft cheat sheets moved to new wiki template! | ||
* [Feb 04 2014] Project-wide cleanup started | * [Feb 04 2014] Project-wide cleanup started | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
= Master Cheat Sheet = | = Master Cheat Sheet = |
Revision as of 10:40, 3 March 2018
Our goalThe OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics. These cheat sheets were created by various application security professionals who have expertise in specific topics. We hope that the OWASP Cheat Sheet Series provides you with excellent security guidance in an easy to read format.
AuthorsProject Leaders: Jim Manico and Dominique Righetto @
OWASP Cheat Sheets |
ClassificationsSlack & TwitterSlack channel information:
Twitter hash tag: #owaspcheatsheetseries Email ListLicensingThe OWASP Cheat Sheet Series is free to use under the Creative Commons ShareAlike 3 License. Related ProjectsNews and Events
AuthenticationEnsure all entities go through an appropriate and adequate form of authentication. All the application non-public resource must be protected and shouldn't be bypassed. For more information, check Authentication Cheat Sheet Session ManagementUse secure session management practices that ensure that authenticated users have a robust and cryptographically secure association with their session. For more information, check Session Management Cheat Sheet Access ControlEnsure that a user has access only to the resources they are entitled to. Perform access control checks on the server side on every request. All user-controlled parameters should be validated for entitlemens checks. Check if user name or role name is passed through the URL or through hidden variables. Prepare an ACL containing the Role-to-Function mapping and validate if the users are granted access as per the ACL. For more information, check Access Control Cheat Sheet Input ValidationInput 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. For more information, check Input Validation Cheat Sheet Output EncodingOutput encoding is the primary method of preventing XSS and injection attacks. Input validation helps minimize the introduction of malformed data, but it is a secondary control. For more information, check XSS (Cross Site Scripting) Prevention Cheat Sheet. Cross DomainEnsure that adequate controls are present to prevent against Cross-site Request Forgery, Clickjacking and other 3rd Party Malicious scripts. For more information, check Cross Site Request Forgery Secure TransmissionEnsure that all the applications pages are served over cryptographically secure HTTPs protocols. Prohibit the transmission of session cookies over HTTP. For more information, check Transport Protection Cheat Sheet LoggingEnsure that all the security related events are logged. Events include: User log-in (success/fail); view; update; create, delete, file upload/download, attempt to access through URL, URL tampering. Audit logs should be immutable and write only and must be protected from unauthorized access. For more information, check Logging Cheat Sheet UploadsEnsure that the size, type, contents and name of the uploaded files are validated. Uploaded files must not be accessible to users by direct browsing. Preferably store all the uploaded files in a different file server/drive on the server. All files must be virus scanned using a regularly updated scanner. Global:
Cheat sheet contentThe key points that all cheat sheets (called CS) must provides are the following:
Cheat sheet structureA CS must have these sections:
Cheat sheet templateIf the target CS is a new one then please use the following template struture. It allow you to work:
__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
__TOC__{{TOC hidden}}
= Introduction =
<pre>
Provide high level information about the topic in order to introduce it to people that do not know it.
You can add pointer to external sources if needed but at least give an overview allowing a reader to continue on the CS.
You can also add schema or diagram in any part of the CS but be sure to respect the copyright of the source file.
</pre>
= Context =
<pre>
Describe the security issues that are bring or commonly meet when someone must work on this topic.
</pre>
= Objective =
<pre>
Describe the objective of the CS.
What the CS will bring to the reader.
</pre>
= Proposition =
<pre>
1. Describe how to address the security issues in a possible technology agnostic approach.
2. Using your POC, describe your solution proposal in the more teaching possible way. Use "syntaxhighlight" tag for code snippet.
</pre>
= Sources of the prototype =
<pre>
Add pointer to the public GitHub repository on which the source code of POC is hosted.
</pre>
= Authors and Primary Editors =
<pre>
Add your name and email.
</pre>
= Other Cheatsheets =
{{Cheatsheet_Navigation_Body}}
|}
[[Category:Cheatsheets]]
|