Injection flaws occur when an application sends untrusted data to an interpreter. Legacy code is notoriously riddled with them. SQL, LDAP, XPath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments are all susceptible to malicious injections.
Preventing injection requires keeping untrusted data separate from commands and queries.
- using safe APIs which avoids the use of the interpreter entirely or provides a parameterized interface
- Escaping special characters using the specific escape syntax for that interpreter.
- White-listing input validation
#2: Broken Authentication and Syntax Management
Custom built authentication and session management schemes are riddled flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. leading to these vulnerabilities.
To prevent them-
A single set of strong authentication and session management controls:
- The custom modules should meet all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management): https://www.owasp.org/index.php/ASVS
- They should have a simple interface for developers
#3: Cross-Site Scripting XSS
It occurs when the attacker sends text-based attack scripts that exploit the interpreter in the browser.
Preventing XSS requires separation of untrusted data from active browser content.
- whitelisting input validation
#4: Insecure Direct Object References
When applications use the actual name or key of an object when generating web pages, they may not verify the user is authorized for the target object. This results in an insecure direct object reference flaw.
To prevent this-
- Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources
- Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.
#5: Security Misconfiguration
Attacker accesses default accounts, unused pages, unpatched flaws, unprotected files, and directories, etc. to gain unauthorized access to or knowledge of the system.
To prevent it-
- Automation of identical configuring of development, QA, and production environments.
- Having a process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment.
#6: Sensitive Data Exposure
Attackers steal keys, do man-in-the-middle attacks, or steal clear text data off the server, while in transit, or from the user’s browser.
To prevent it-
- Encrypt all sensitive data at rest and in transit in a manner that defends against these threats.
- Don’t store sensitive data unnecessarily.
- Ensure strong standard algorithms and strong keys are used, and proper key management is in place.
#7: Missing Function Level Access Control
Misconfigurations allow attackers to access unauthorized functionality. These flaws can be prevented by-
- Not hardcoding configurations
- The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.
#8: Cross-Site Request Forgery (CSRF)
CSRF takes advantage of the fact that most web apps allow attackers to predict all the details of a particular action. To prevent it-
- include a unique token in a hidden field in HTTP request
- require the user to re-authenticate or use a CAPTCHA
#9: Using Components with Known Vulnerabilities
Attackers identify vulnerabilities through scanning or manual analysis and customize the exploit as needed and execute the attack. To prevent this-
- Identify all components and the versions you are using, including all dependencies. (e.g., the versions plugin)
- Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date.
#10: Unvalidated Redirects and Forwards
When applications redirect users to other pages the target page is sometimes specified in an unvalidated parameter, and this lets attackers manipulate and redirect to their own destination page. To prevent this-
- Avoid using redirects and forwards.
- If used, don’t involve user parameters in calculating the destination
- If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.