OWASP Top 10

Use the OWASP Application Security Verification Standard. Do not limit your focus to the OWASP Top 10 Vulnerabilities.

SQL Injection (SQLi)

Problem: Malicious user input is interpreted as a database query.

Cause: The malicious user input has had inadequate data validation by the web tier.

Detection: If you have the application tier source code, review it. If you don’t, mechanically test through the web tier (e.g., sqlmap).

Mitigation: Parametrize queries in the application; that is, use variables in prepared SQL statements. Never construct queries by concatenating user input. If you don’t have access to the application source code, use an already available known and proven HTML sanitizer. SQL Injection can be mitigated with a Web Application Firewall.

See Secure Web Application Development

• Use Parameterized APIs for Data Access
• Use Positive Input Validation
• Avoid Using Command Interpreters
• Escape Special Characters, If Parameterized APIs Are Not Available

https://www.owasp.org/index.php/Top_10_2010-A1
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet

Cross-site Scripting (XSS)

Problem: Malicious user input is displayed on a web page. The user’s web browser processes the malicious input, attacking themselves. The user shot themselves, but didn’t know they were holding a gun.

Cause: The malicious user input has had inadequate data validation by the web tier.

Detection: If you have the application tier source code, see the OWASP Code Review Guide article on Reviewing code for Cross-site scripting Vulnerabilities.  If you don’t, then the Browser Exploitation Framework (BeEF), XSS Cheat Sheet, burp and manual tests would be a start.

Mitigation: Use safe re-encoding of the user input before it is displayed on a web page. Use an already available known and proven encoder such as OWASP ESAPI. Input validation is often used, but displaying content in a safe manner is to be preferred. Cross-site scripting can be mitigated with a Web Application Firewall.

• Escape All Untrusted Data in HTML Contexts
• Use Positive Input Validation

https://www.owasp.org/index.php/Top_10_2010-A2
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Session Hijacking

Problem: In order to maintain a conversation, a web application needs to keep track of where it left off. The web application needs to preserve a session’s state. A person can impersonate a web application’s state, the web application can take incorrect actions.

Cause: Session tokens (how you maintain state in web applications) are passed in clear text.

Detection: Review packet captures for tokens passed in clear text.

Mitigation: Encrypt communication using HTTPS. Additionally, use session inactivity timeouts.

• Centralize Authentication and Session Management Controls
• Protect Session IDs from XSS

https://www.owasp.org/index.php/Top_10_2010-A3
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

Parameter Manipulation (Insecure Direct Object References)

Cause: User supplies a value in the URL and the application accepts it.

Detection: Review packet captures for URL parameters.

Mitigation: If you have access to the application, server-side validation should be used. Is the returned value acceptable? Are there errors in business logic? Additionally, use session parameters (where the data elements are stored on the server side and accessed through the session identifier) instead of URL parameters (which are exposed on the client side). If you don’t have access to the application … a web application firewall can help sanitize input, but cannot prevent that input from being modified and cannot fix errors in business logic.

• Use Per-User or Per-Session Indirect Object References
• [OR] Check Access Control Permissions Whenever Performing Direct Object References
• Disable Directory Browsing

https://www.owasp.org/index.php/Top_10_2010-A4

Cross-site Request Forgery (CSRF)

Problem: The user establishes an authenticated session. The user then connects to an unrelated site. The unrelated site takes advantage of the user’s authenticated session to perform actions.

Cause: The user’s intended web application supports URLs which can specify complete session information using parameters. The unrelated site performs the unauthorized action through a crafted URL. The URL requires no user interaction, or minimal interaction.

Detection: Review web application for URL parameters. Review packet captures for URL parameters.

Mitigation: If you have access to the application, implement CSRF session tokens (for each page a new token is created and hidden on the user’s web page; the server checks the next transaction for the predetermined token). Session timeouts would limit the availability of authenticated sessions. Re-authentication before the transaction is completed would require user interaction.

• Include Unique Tokens in HTTP Requests

https://www.owasp.org/index.php/Top_10_2010-A5
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

CSRF Proof of Concept with OWASP ZAP

ASP.NET: The anti-forgery token can be used to help protect your application against cross-site request forgery. To use this feature, call the AntiForgeryToken method from a form and add the ValidateAntiForgeryTokenAttribute attribute to the action method that you want to protect.

Security Misconfiguration (Insecure Configuration)

Cause: Insufficient hardening. Lack of configuration management process. Lack of account management process. Lack of patch management process. Security patches not installed, unnecessary services enabled, default passwords, excessive permissions

Detection:

Mitigation: Repeatable hardening process. Recurring inventory and audits.

• Establish A Repeatable Hardening Process
• Keep Up with Security Updates
• Design a Strong Application Architecture
• Run Scans and Perform Audits

https://www.owasp.org/index.php/Top_10_2010-A6
https://www.owasp.org/index.php/Security_Architecture_Cheat_Sheet

Insecure Cryptographic Storage

Cause: Sensitive information is stored or transmitted in an insecure manner. The cryptographic method may be obsolete or the implementation may be weak.

Detection:

Mitigation: There may be specific regulatory requirements to consider. Review information to determine if it is sensitive and if it should be stored. (Classify assets, model realistic weaknesses, determine threats which may exploit those weaknesses, implement defenses.) Use known, strong encryption methods, long keys and a key management system.

• Consider the Threats You Plan to Protect Data from
• Encrypt Off-site Backups
• Ensure Strong Algorithms Are Used
• Hash and Salt Passwords
• Protect Keys and Passwords

https://www.owasp.org/index.php/Top_10_2010-A7
https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

Failure to Restrict URL Access (Forced Browsing)

Cause: Incorrect web server configuration. Insufficient restrictions in application logic. User can guess a URL that  provides access to information or processes that should be restricted.

Detection: Crawl the application for page access. Should these pages be exposed? Test exposed pages for insufficient authorization enforcement.

Mitigation: Authorization checks within the application. Page level authorization at the web server. Can be mitigated with a Web Application Firewall.

• Require Authentication and Authorization for Each Sensitive Page
• Use Role-based Authentication and Authorization
• Make Authentication and Authorization Policies Configurable
• Deny All Access by Default

https://www.owasp.org/index.php/Top_10_2010-A8

Insufficient Transport Layer Protection (Clear-text Communication, Cookie Poisoning)

Cause: Sensitive information is sent unencrypted. This could include unencrypted session cookies which, if exposed, can be used to impersonate the authenticated user (capture their session).

Detection: Review packet captures for sensitive information passed in clear text.

Mitigation: Implement “always on” SSL (HTTPS) with strong keys (greater then 128 bit ciphers) and disable weaker protocols (SSLv1, SSLv2, SSLv3). Implement a key management policy. Alternately, encrypt the sensitive information (such as cookies) and sign it (so it cannot be modified). Consider disabling HTTP if the site is sensitive. Can be mitigated with a Web Application Firewall.

• Enable SSL
• Use SSL for All Sensitive Pages
• Set the Secure Flag on All Sensitive Cookies
• Use Only Strong SSL Algorithms
• Use Valid SSL Certificates
• Secure Backend Connections

https://www.owasp.org/index.php/Top_10_2010-A9
https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

Unvalidated Redirects and Forwards (Unchecked Redirects)

Cause: Lack of validation when using forms or parameters to forward or redirect users. This enables hackers to use your site as a trusted name or domain when redirecting to their malicious site.

Detection:

Mitigation: Don’t use parameters to forward or redirect users. Use session information stored on the server. Alternately, whitelist the URLs that the user can be forwarded to and verify that the user has authority to access the web page.

• Don’t Use Redirects or Forwards, If Possible
• Don’t Use User Input for Calculating Destinations of Redirects or Forwards
• Use Mapping Values When Calculating Destinations of Redirects or Forwards

https://www.owasp.org/index.php/Top_10_2010-A10

A-1. Authentication Requirements

• Require Authentication for All Private Pages
• All Password Fields Are Masked
• Lock Accounts After Multiple Failed Authentication Attempts
• Use Server-side Authentication
• Centralize All Authentication Controls
• Make Sure Authentication Controls Fail Securely
• Require Strong Authentication Credentials
• Secure the Account Management Functions
• Secure the Credential (Password) Changing Functions
• Require Re-authentication for Sensitive Operations
• Force Authentication Credentials to Expire
• Log Authentication Events
• Hash and Salt Passwords
• Protect Authentication Credentials for External Resources

http://code.google.com/p/owasp-asvs/wiki/Verification_V2

A-2. Session Management Requirements

• Use Session Management Offered by the Framework
• Invalidate Sessions when Users Log Out
• Make Inactive Sessions Time-out
• Make Sessions Time-out
• Place Logout Links on All Pages that Require Authentication
• Protect Session IDs
• Change Session IDs on Login
• Change Session IDs on Reauthentication
• Change Session IDs on Logout
• Reject Invalid Session IDs
• Use Strong Session IDs
• Set the Domain and Path Values of Session Cookies

http://code.google.com/p/owasp-asvs/wiki/Verification_V3

Nogotofail is a network security testing tool designed to help developers and security researchers spot and fix weak TLS/SSL connections and sensitive cleartext traffic on devices and applications in a flexible, scalable, powerful way. It includes testing for common SSL certificate verification issues, HTTPS and TLS/SSL library bugs, SSL and STARTTLS stripping issues, cleartext issues, and more.

Common Weakness Enumeration (CWE) 25

Static Application Security Testing (SAST) or “white box” testing

Dynamic Application Security Testing (DAST) or “black box” testing

Fuzz testing tools