Ubuntu - OWASP - OWASP Top Ten Cheat Sheet

Issue	Presentation	Solution	Comments
Injection	Render	Set a correct content type.	All SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries.
		Set safe character set (UTF-8).	Canonicalize using correct character set.
		Set correct locale.
	On Submit:	Enforce input field type and lengths.	Positive input validation using correct character set.
		Validate fields and provide feedback.	Use Parameterized queries and Stored Procedures.
		Ensure option selects and radio contain only sent values.	Use Parameterized queries and Stored Procedures.
Weak authentication and session management	Render	Validate user is authenticated.
		Validate role is sufficient for this view.	Validate role is sufficient to create, read, update, or delete data.
		Validate role is sufficient for this view.	Consider the use of a “governor” to regulate the maximum number of requests per second / minute / hour that this user may perform.
		Set “secure” and “HttpOnly” flags for session cookies.
		Send CSRF token with forms.
XSS	Render	Set correct content type.
		Set safe character set (UTF-8).	Canonicalize using correct character set.
		Set correct locale.
		Output encode all user data as per output context.
		Set input constraints.	Positive input validation using correct character set.
			Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.
			Do not store data HTML-encoded in the database. This prevents new uses for the data.
Insecure Direct Object References	If data is from internal trusted sources, no data is sent.	Obtain data from internal, trusted sources.
	Render	Send indirect random access reference map value.	Obtain direct value from random access reference access map.
	Render	Send indirect random access reference map value.	Validate role is sufficient to create, read, update, or delete data.
Security Misconfiguration	Web servers and application servers.	Ensure web servers and application servers are hardened.
	Database Servers	Ensure database servers are hardened.
	PHP	Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension.
	XML	Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer.
Sensitive Data Exposure	Design	Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).
		Use strong hashes (SHA 256 or better) with salts for passwords.
		Protect keys more than any other asset.	Mandate strong encrypted communications between web and database servers and any other servers or administrative users.
		Protect keys more than any other asset.	Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being “encrypted” on disk.
		Use TLS 1.2 or later for all web communications.	Use TLS 1.2 always – even internally.
		Buy extended validation (EV) certificates for public web servers.
	Render	Do not send keys or hashes to the browser.	It is best to encrypt data on the application server, rather than the database server.
Missing Function Level Access Control	Design	Ensure all non-web data is outside the web root (logs, configuration, etc).
		Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.	It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming.
		Ensure every page requires a role, even if it is “guest”.	Assume attackers will learn where “hidden” directories and “random” filenames are, so do not store these files in the web root, even if they are not directly linked.
	Pre-render	Validate user is authenticated.
	Pre-render	Validate role is sufficient to view secured URL.	Validate role is sufficient to create, read, update, or delete data.
	Render	Send CSRF token.	Validate CSRF token.
Cross Site Request Forgery	Pre-render	Validate user is authenticated.
	Pre-render	Validate role is sufficient for this view.	Validate role is sufficient to create, read, update, or delete data.
	Render	Send CSRF token.	Validate CSRF token.
		Send CSRF token.	CSRF is always possible if there is XSS, so make sure XSS is eliminated within your application.
		Set “secure” and “HttpOnly” flags for session cookies.
Using Components with Known Vulnerabilities
Unvalidated Redirects and Forwards	Design the app without URL redirection parameters.	Design the app without URL redirection parameters.	Validate role is sufficient to create, read, update, or delete data.
	Render	Use random indirect object references for redirection parameters.	Obtain direct redirection parameter from random indirect reference access map.
			(LR) Positive validation of redirection parameter.
			(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.

References

https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet