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"
(→Logging and Auditing) |
(→SQL Injection) |
||
Line 84: | Line 84: | ||
== SQL Injection == | == SQL Injection == | ||
− | https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet | + | Please see https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet |
== Cross Site Scripting == | == Cross Site Scripting == |
Revision as of 15:35, 8 January 2016
- 1 DRAFT CHEAT SHEET - WORK IN PROGRESS
- 2 Introduction
- 3 How To Use This Document
- 4 Secure Coding Policy
- 5 Authentication
- 6 Session Management
- 7 Access Control
- 8 Input Data Validation
- 9 Output Encoding
- 10 Secure Transmission / Network Layer security
- 11 File Uploads
- 12 Error Handling
- 13 Logging and Auditing
- 14 Cryptography
- 15 Cookie Management
- 16 Secure Deployment
- 17 Unvalidated Redirects and Forwards Cheat Sheet
- 18 Common Vulnerabilities
DRAFT CHEAT SHEET - WORK IN PROGRESS
Introduction
The goal of this document is to create high level guideline for secure coding practices. The goal is to keep the overall size of the document condensed and easy to digest. Individuals seeking addition information on the specific areas should refer to the included links to learn more.
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.
Secure Coding Policy
Always maintain a secure coding policy. List down the activities that are related to maintenance of secure coding standards (would these standards be technology specific or technology agnostic), feedback of code review output to training, input data validation, output data validation etc
Why should you be having a secure coding policy? It helps in maintaining consistency across organisation and helps in vertical and horizontal scaling of usage of standards for web development projects.
Authentication
User Authentication
Please see https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Utilize_Multi-Factor_Authentication
Password Complexity
For more information on password complexity, please see https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Proper_Password_Strength_Controls.
Session Management
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
Access Control
https://www.owasp.org/index.php/Access_Control_Cheat_Sheet
Input Data Validation
https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet
Output Encoding
Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#Output_Encoding
Secure Transmission / Network Layer security
Please see https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Benefits
File Uploads
Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#File_Uploads
Error Handling
Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#Error_Handling
Logging and Auditing
Please see https://www.owasp.org/index.php/Logging_Cheat_Sheet
Cryptography
Please see https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
Cookie Management
Please see https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Cookies
Secure Deployment
- Secure access to with authentication and authorisation to configuration files, directories, and resources on the host so that direct access to such artifacts is disallowed
- Use a “deny all” rule to deny access to resources on the hosts and then grant access on need basis
- In Apache HTTP server, ensure directories like WEB-INF and META-INF are protected. If permissions for a directory and subdirectories are specified in .htaccess file, ensure that it is protected using the “deny all” rule
- While using Struts framework, ensure that JSP files are not accessible directly by denying access to *.jsp files in web.xml
- Maintain a clean environment. remove files that contain source code but are not used by the application.
- Ensure production environment does not contain any source code / development tools and that the production
- Ensure environment contains only compiled code / executables.
- Remove test code / debug code (that might contain backdoors).
- Remove commented code and meta tags as they might contain sensitive data.
- If applicable, obfuscate your code to ensure that reverse engineering is avoided
Unvalidated Redirects and Forwards Cheat Sheet
https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet
Common Vulnerabilities
SQL Injection
Please see https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
Cross Site Scripting
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
Cross Site Request Forgery
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
Preventing Malicious Site Framing (ClickJacking)
Security Misconfigurations
- Diable all the services, ports, protocols and daemons that are not required.
- Change all the default and vendor supplied passwords
- Protect servers by grouping all similar functions into a VLAN
- White wash error messages such that no internal workings are revealed
- Prevent stack traces from leaving the container.
- Authorising access to the least amount of data/ least number of pages that is possible
Insecure Direct Object references
https://www.owasp.org/index.php/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet
Directory Listing
- Do not enable Directory Listing on your server
Concurrancy and Race Conditions
- Use a locking mechanism to lock shared resources
- Obtain a lock on shared resources before it is read
References
OWASP Cheat Sheets Project Homepage