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 Top Ten Cheat Sheet"
Dan Wallis (talk | contribs) m |
Dan Wallis (talk | contribs) |
||
Line 9: | Line 9: | ||
= OWASP Top Ten Cheat Sheet = | = OWASP Top Ten Cheat Sheet = | ||
− | + | == A1 Injection == | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | === Presentation === | ||
''Render:'' | ''Render:'' | ||
*Set a correct content type | *Set a correct content type | ||
Line 29: | Line 21: | ||
*Validate fields and provide feedback. | *Validate fields and provide feedback. | ||
*Ensure option selects and radio contain only sent values. | *Ensure option selects and radio contain only sent values. | ||
− | + | ||
+ | === Controller === | ||
+ | '''Canonicalize using correct character set''' | ||
'''Positive input validation using correct character set''' | '''Positive input validation using correct character set''' | ||
Line 36: | Line 30: | ||
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. '' | ''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. '' | ||
− | + | ||
+ | === Model === | ||
+ | *'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]''' | ||
*Object relational model (Hibernate). | *Object relational model (Hibernate). | ||
Line 48: | Line 44: | ||
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization '' | ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization '' | ||
− | + | === Testing === | |
* [[Testing for SQL Injection (OTG-INPVAL-005)]] | * [[Testing for SQL Injection (OTG-INPVAL-005)]] | ||
* [[Testing for LDAP Injection (OTG-INPVAL-006)]] | * [[Testing for LDAP Injection (OTG-INPVAL-006)]] | ||
Line 60: | Line 56: | ||
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]] | * [[Testing for Buffer Overflow (OTG-INPVAL-014)]] | ||
− | + | == A2 Weak authentication and session management == | |
− | + | === Presentation === | |
− | + | ''Render:'' | |
*Validate user is authenticated. | *Validate user is authenticated. | ||
*Validate role is sufficient for this view. | *Validate role is sufficient for this view. | ||
Line 68: | Line 64: | ||
*Send CSRF token with forms. | *Send CSRF token with forms. | ||
− | + | === Controller === | |
+ | ''Design:'' | ||
*Only use inbuilt session management. | *Only use inbuilt session management. | ||
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies. | *Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies. | ||
Line 75: | Line 72: | ||
*Validate role is sufficient to perform this action. | *Validate role is sufficient to perform this action. | ||
*Validate CSRF token. | *Validate CSRF token. | ||
− | + | ||
+ | === Model === | ||
+ | Validate role is sufficient to create, read, update, or delete data | ||
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.'' | ''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.'' | ||
− | + | === Testing === | |
* [[Test Role Definitions (OTG-IDENT-001)]] | * [[Test Role Definitions (OTG-IDENT-001)]] | ||
* [[Test User Registration Process (OTG-IDENT-002)]] | * [[Test User Registration Process (OTG-IDENT-002)]] | ||
Line 106: | Line 105: | ||
* [[Testing for Session puzzling (OTG-SESS-008)]] | * [[Testing for Session puzzling (OTG-SESS-008)]] | ||
− | + | == A3 XSS == | |
− | |||
− | |||
+ | === Presentation === | ||
''Render:'' | ''Render:'' | ||
*Set correct content type | *Set correct content type | ||
Line 121: | Line 119: | ||
*Validate fields and provide feedback. | *Validate fields and provide feedback. | ||
*Ensure option selects and radio contain only sent values. | *Ensure option selects and radio contain only sent values. | ||
− | + | ||
+ | === Controller === | ||
+ | '''Canonicalize using correct character set''' | ||
'''Positive input validation using correct character set''' | '''Positive input validation using correct character set''' | ||
Line 128: | Line 128: | ||
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.'' | ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.'' | ||
− | + | ||
+ | === Model === | ||
+ | ''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.'' | ||
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data'' | ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data'' | ||
− | + | === Testing === | |
* [[Testing for Reflected Cross site scripting (OTG-INPVAL-001)]] | * [[Testing for Reflected Cross site scripting (OTG-INPVAL-001)]] | ||
* [[Testing for Stored Cross site scripting (OTG-INPVAL-002)]] | * [[Testing for Stored Cross site scripting (OTG-INPVAL-002)]] | ||
Line 140: | Line 142: | ||
* [[Testing for Cross site flashing (OTG-CLIENT-008)]] | * [[Testing for Cross site flashing (OTG-CLIENT-008)]] | ||
− | + | ||
− | + | == A4 Insecure Direct Object References == | |
− | + | ||
+ | === Presentation === | ||
+ | If data is from internal trusted sources, no data is sent. | ||
Or | Or | ||
Line 148: | Line 152: | ||
''Render:'' | ''Render:'' | ||
*Send indirect random access reference map value. | *Send indirect random access reference map value. | ||
− | + | === Controller === | |
+ | Obtain data from internal, trusted sources. | ||
Or | Or | ||
Obtain direct value from random access reference access map. | Obtain direct value from random access reference access map. | ||
− | |||
− | + | === Model === | |
+ | Validate role is sufficient to create, read, update, or delete data. | ||
+ | |||
+ | === Testing === | ||
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]] | * [[Testing Directory traversal/file include (OTG-AUTHZ-001)]] | ||
* [[Testing for Insecure Direct Object References (OTG-AUTHZ-004)]] | * [[Testing for Insecure Direct Object References (OTG-AUTHZ-004)]] | ||
Line 161: | Line 168: | ||
* [[Testing for Remote File Inclusion]] | * [[Testing for Remote File Inclusion]] | ||
− | + | ||
− | + | == A5 Security Misconfiguration == | |
− | + | ||
+ | === Presentation === | ||
+ | Ensure web servers and application servers are hardened. | ||
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension | PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension | ||
− | + | ||
+ | === Controller === | ||
+ | Ensure web servers and application servers are hardened | ||
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. | 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. | ||
− | |||
− | + | === Model === | |
+ | Ensure database servers are hardened | ||
+ | |||
+ | === Testing === | ||
* [[Fingerprint Web Server (OTG-INFO-002)]] | * [[Fingerprint Web Server (OTG-INFO-002)]] | ||
* [[Fingerprint Web Application Framework (OTG-INFO-008)]] | * [[Fingerprint Web Application Framework (OTG-INFO-008)]] | ||
Line 185: | Line 198: | ||
* [[Testing for Stack Traces (OTG-ERR-002)]] | * [[Testing for Stack Traces (OTG-ERR-002)]] | ||
− | + | == A6 Sensitive Data Exposure == | |
− | + | ||
− | + | === Presentation === | |
+ | ''Design:'' | ||
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB). | *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. | *Use strong hashes (SHA 256 or better) with salts for passwords. | ||
Line 199: | Line 213: | ||
*Do not send keys or hashes to the browser. | *Do not send keys or hashes to the browser. | ||
− | + | === Controller === | |
+ | ''Design:'' | ||
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB). | *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. | *Use strong hashes (SHA 256 or better) with salts for passwords. | ||
Line 209: | Line 224: | ||
''Tip: It is best to encrypt data on the application server, rather than the database server.'' | ''Tip: It is best to encrypt data on the application server, rather than the database server.'' | ||
− | + | === Model === | |
+ | ''Design:'' | ||
*Mandate strong encrypted communications with application servers and any other servers or administrative users. | *Mandate strong encrypted communications with application servers and any other servers or administrative users. | ||
Line 215: | Line 231: | ||
''Tip: 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. '' | ''Tip: 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. '' | ||
− | + | === Testing === | |
* [[Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]] | * [[Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]] | ||
* [[Testing for Padding Oracle (OTG-CRYPST-002)]] | * [[Testing for Padding Oracle (OTG-CRYPST-002)]] | ||
Line 222: | Line 238: | ||
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] | * [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] | ||
− | + | == A7 Missing Function Level Access Control == | |
− | + | === Presentation === | |
− | + | ''Design:'' | |
*Ensure all non-web data is outside the web root (logs, configuration, etc). | *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. | *Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar. | ||
Line 235: | Line 251: | ||
''Render:'' | ''Render:'' | ||
*Send CSRF token. | *Send CSRF token. | ||
− | + | ||
+ | === Controller === | ||
*Validate user is authenticated. | *Validate user is authenticated. | ||
*Validate role is sufficient to perform secured action. | *Validate role is sufficient to perform secured action. | ||
Line 243: | Line 260: | ||
''Tip: 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.'' | ''Tip: 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.'' | ||
− | |||
− | + | === Model === | |
+ | Validate role is sufficient to create, read, update, or delete data | ||
+ | |||
+ | === Testing === | ||
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]] | * [[Testing Directory traversal/file include (OTG-AUTHZ-001)]] | ||
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]] | * [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]] | ||
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]] | * [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]] | ||
− | + | == A8 Cross Site Request Forgery == | |
− | + | === Presentation === | |
− | + | ''Pre-render:'' | |
*Validate user is authenticated | *Validate user is authenticated | ||
*Validate role is sufficient for this view | *Validate role is sufficient for this view | ||
Line 259: | Line 278: | ||
*Send CSRF token. | *Send CSRF token. | ||
*Set "secure" and "HttpOnly" flags for session cookies. | *Set "secure" and "HttpOnly" flags for session cookies. | ||
− | + | ||
+ | === Controller === | ||
*Validate CSRF token. | *Validate CSRF token. | ||
*Validate role is sufficient to perform this action. | *Validate role is sufficient to perform this action. | ||
Line 265: | Line 285: | ||
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.'' | ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.'' | ||
− | |||
− | + | === Model === | |
+ | Validate role is sufficient to create, read, update, or delete data | ||
+ | |||
+ | === Testing === | ||
* [[Testing for CSRF (OTG-SESS-005)]] | * [[Testing for CSRF (OTG-SESS-005)]] | ||
− | + | == A9 Using Components with Known Vulnerabilities == | |
− | + | === Presentation === | |
− | + | === Controller === | |
− | + | === Model === | |
+ | === Testing === | ||
+ | * [[Enumerate Applications on Webserver (OTG-INFO-004)]] | ||
− | + | == A10 Unvalidated Redirects and Forwards == | |
− | + | === Presentation === | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
*Design the app without URL redirection parameters. | *Design the app without URL redirection parameters. | ||
Line 295: | Line 309: | ||
*Use random indirect object references for redirection parameters. | *Use random indirect object references for redirection parameters. | ||
− | + | === Controller === | |
*Design the app without URL redirection parameters. | *Design the app without URL redirection parameters. | ||
Line 304: | Line 318: | ||
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms. | *(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms. | ||
− | + | === Model === | |
*Validate role is sufficient to create, read, update, or delete data. | *Validate role is sufficient to create, read, update, or delete data. | ||
− | + | === Testing === | |
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]] | * [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]] | ||
− | |||
− | |||
− | |||
= Authors and Primary Editors = | = Authors and Primary Editors = | ||
− | Andrew van der Stock vanderaj[at]owasp.org | + | * Andrew van der Stock vanderaj[at]owasp.org |
− | + | * Ismael Rocha Gonçalves ismaelrg[at]gmail.com | |
− | Ismael Rocha Gonçalves ismaelrg[at]gmail.com | + | * Jorge Correa [email protected] |
− | |||
− | Jorge Correa [email protected] | ||
= Other Cheatsheets = | = Other Cheatsheets = |
Revision as of 03:38, 3 August 2017
Introduction
- 1 Introduction
- 2 OWASP Top Ten Cheat Sheet
- 2.1 A1 Injection
- 2.2 A2 Weak authentication and session management
- 2.3 A3 XSS
- 2.4 A4 Insecure Direct Object References
- 2.5 A5 Security Misconfiguration
- 2.6 A6 Sensitive Data Exposure
- 2.7 A7 Missing Function Level Access Control
- 2.8 A8 Cross Site Request Forgery
- 2.9 A9 Using Components with Known Vulnerabilities
- 2.10 A10 Unvalidated Redirects and Forwards
- 3 Authors and Primary Editors
- 4 Other Cheatsheets
The following is a developer-centric defensive cheat sheet for the 2013 release of the OWASP Top Ten Project. It also presents a quick reference based on OWASP Testing Project to help how to identify the risks.
OWASP Top Ten Cheat Sheet
A1 Injection
Presentation
Render:
- Set a correct content type
- Set safe character set (UTF-8)
- Set correct locale
On Submit:
- Enforce input field type and lengths.
- Validate fields and provide feedback.
- Ensure option selects and radio contain only sent values.
Controller
Canonicalize using correct character set Positive input validation using correct character set
(NR) Negative input validation. (LR) Sanitize input.
Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will always fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism.
Model
- Object relational model (Hibernate).
- Active Record design pattern.
- Stored procedures.
- Escape mechanisms such as ESAPI's Encoder:
- EncodeForLDAP()
- Encoder.EncodeforOS()
Tip: All SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization
Testing
- Testing for SQL Injection (OTG-INPVAL-005)
- Testing for LDAP Injection (OTG-INPVAL-006)
- Testing for ORM Injection (OTG-INPVAL-007)
- Testing for XML Injection (OTG-INPVAL-008)
- Testing for SSI Injection (OTG-INPVAL-009)
- Testing for XPath Injection (OTG-INPVAL-010)
- Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
- Testing for Code Injection (OTG-INPVAL-012)
- Testing for Command Injection (OTG-INPVAL-013)
- Testing for Buffer Overflow (OTG-INPVAL-014)
A2 Weak authentication and session management
Presentation
Render:
- Validate user is authenticated.
- Validate role is sufficient for this view.
- Set "secure" and "HttpOnly" flags for session cookies.
- Send CSRF token with forms.
Controller
Design:
- Only use inbuilt session management.
- Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.
- Validate user is authenticated.
- Validate role is sufficient to perform this action.
- Validate CSRF token.
Model
Validate role is sufficient to create, read, update, or delete data
Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.
Testing
- Test Role Definitions (OTG-IDENT-001)
- Test User Registration Process (OTG-IDENT-002)
- Test Account Provisioning Process (OTG-IDENT-003)
- Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)
- Testing for Weak or unenforced username policy (OTG-IDENT-005)
- Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)
- Testing for default credentials (OTG-AUTHN-002)
- Testing for Weak lock out mechanism (OTG-AUTHN-003)
- Testing for Bypassing Authentication Schema (OTG-AUTHN-004)
- Testing for Vulnerable Remember Password (OTG-AUTHN-005)
- Testing for Browser cache weakness (OTG-AUTHN-006)
- Testing for Weak password policy (OTG-AUTHN-007)
- Testing for Weak security question/answer (OTG-AUTHN-008)
- Testing for weak password change or reset functionalities (OTG-AUTHN-009)
- Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)
- Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)
- Testing for Privilege escalation (OTG-AUTHZ-003)
- Testing for Session Management Schema (OTG-SESS-001)
- Testing for cookies attributes (OTG-SESS-002)
- Testing for Session Fixation (OTG-SESS-003)
- Testing for Exposed Session Variables (OTG-SESS-004)
- Testing for CSRF (OTG-SESS-005)
- Testing for logout functionality (OTG-SESS-006)
- Test Session Timeout (OTG-SESS-007)
- Testing for Session puzzling (OTG-SESS-008)
A3 XSS
Presentation
Render:
- Set correct content type
- Set safe character set (UTF-8)
- Set correct locale
- Output encode all user data as per output context
- Set input constraints
On Submit:
- Enforce input field type and lengths.
- Validate fields and provide feedback.
- Ensure option selects and radio contain only sent values.
Controller
Canonicalize using correct character set Positive input validation using correct character set
(NR) Negative input validation (LR) Sanitize input
Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.
Model
Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.
Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data
Testing
- Testing for Reflected Cross site scripting (OTG-INPVAL-001)
- Testing for Stored Cross site scripting (OTG-INPVAL-002)
- Testing for DOM-based Cross site scripting (OTG-CLIENT-001)
- Testing for JavaScript Execution (OTG-CLIENT-002)
- Testing for HTML Injection (OTG-CLIENT-003)
- Testing for Cross site flashing (OTG-CLIENT-008)
A4 Insecure Direct Object References
Presentation
If data is from internal trusted sources, no data is sent.
Or
Render:
- Send indirect random access reference map value.
Controller
Obtain data from internal, trusted sources.
Or
Obtain direct value from random access reference access map.
Model
Validate role is sufficient to create, read, update, or delete data.
Testing
- Testing Directory traversal/file include (OTG-AUTHZ-001)
- Testing for Insecure Direct Object References (OTG-AUTHZ-004)
- Testing for Local File Inclusion
- Testing for Remote File Inclusion
A5 Security Misconfiguration
Presentation
Ensure web servers and application servers are hardened.
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension
Controller
Ensure web servers and application servers are hardened
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.
Model
Ensure database servers are hardened
Testing
- Fingerprint Web Server (OTG-INFO-002)
- Fingerprint Web Application Framework (OTG-INFO-008)
- Fingerprint Web Application (OTG-INFO-009)
- Test Network/Infrastructure Configuration (OTG-CONFIG-001)
- Test Application Platform Configuration (OTG-CONFIG-002)
- Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)
- Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)
- Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)
- Test HTTP Methods (OTG-CONFIG-006)
- Test RIA cross domain policy (OTG-CONFIG-008)
- Testing for Error Code (OTG-ERR-001)
- Testing for Stack Traces (OTG-ERR-002)
A6 Sensitive Data Exposure
Presentation
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.
- Use TLS 1.2 or later for all web communications.
- Buy extended validation (EV) certificates for public web servers.
Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.
Render:
- Do not send keys or hashes to the browser.
Controller
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.
Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen.
Tip: It is best to encrypt data on the application server, rather than the database server.
Model
Design:
- Mandate strong encrypted communications with application servers and any other servers or administrative users.
Tip: 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.
Testing
- Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)
- Testing for Padding Oracle (OTG-CRYPST-002)
- Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)
- Test HTTP Strict Transport Security (OTG-CONFIG-007)
- Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)
A7 Missing Function Level Access Control
Presentation
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.
- Ensure every page requires a role, even if it is "guest".
Pre-render:
- Validate user is authenticated.
- Validate role is sufficient to view secured URL.
Render:
- Send CSRF token.
Controller
- Validate user is authenticated.
- Validate role is sufficient to perform secured action.
- Validate CSRF token.
Tip: 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.
Tip: 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.
Model
Validate role is sufficient to create, read, update, or delete data
Testing
- Testing Directory traversal/file include (OTG-AUTHZ-001)
- Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)
- Testing for Bypassing Authentication Schema (OTG-AUTHN-004)
A8 Cross Site Request Forgery
Presentation
Pre-render:
- Validate user is authenticated
- Validate role is sufficient for this view
Render:
- Send CSRF token.
- Set "secure" and "HttpOnly" flags for session cookies.
Controller
- Validate CSRF token.
- Validate role is sufficient to perform this action.
- Validate role is sufficient.
Tip: CSRF is always possible if there is XSS, so make sure XSS is eliminated within your application.
Model
Validate role is sufficient to create, read, update, or delete data
Testing
A9 Using Components with Known Vulnerabilities
Presentation
Controller
Model
Testing
A10 Unvalidated Redirects and Forwards
Presentation
- Design the app without URL redirection parameters.
or
Render:
- Use random indirect object references for redirection parameters.
Controller
- Design the app without URL redirection parameters.
or
- 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.
Model
- Validate role is sufficient to create, read, update, or delete data.
Testing
Authors and Primary Editors
- Andrew van der Stock vanderaj[at]owasp.org
- Ismael Rocha Gonçalves ismaelrg[at]gmail.com
- Jorge Correa [email protected]