Injection flaws are very prevalent, particularly in legacy code. Injection vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries.
An application is vulnerable to attack when:
• User-supplied data is not validated, filtered, or sanitized by the application.
• Dynamic queries or non-parameterized calls without contextaware escaping are used directly in the interpreter.
• Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
• Hostile data is directly used or concatenated, such that the SQL or command contains both structure and hostile data in dynamic queries, commands, or stored procedures.
2. Broken authentication
There may be authentication weaknesses if the application:
• Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
• Permits brute force or other automated attacks.
• Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin“.
• Uses weak or ineffective credential recovery and forgot password processes, such as "knowledge-based answers", which cannot be made safe.
• Uses plain text, encrypted, or weakly hashed passwords.
• Has missing or ineffective multi-factor authentication.
• Exposes Session IDs in the URL (e.g., URL rewriting).
• Does not rotate Session IDs after successful login.
• Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout or a period of inactivity.
3. Sensitive data exposure
The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws, e.g. EU's General Data Protection Regulation
(GDPR), or regulations, e.g. financial data protection such as PCI Data Security Standard (PCI DSS). For all such data:
• Is any data transmitted in clear text? This concerns protocols such as HTTP, SMTP, and FTP. External internet traffic is especially dangerous. Verify all internal traffic e.g. between load balancers, web servers, or back-end systems.
• Is sensitive data stored in clear text, including backups?
• Are any old or weak cryptographic algorithms used either by default or in older code?
• Are default crypto keys in use, weak crypto keys generated or re-used, or is proper key management or rotation missing?
• Is encryption not enforced, e.g. are any user agent (browser) security directives or headers missing?
• Does the user agent (e.g. app, mail client) not verify if the received server certificate is valid?
4. XML External Entities (XEE)
Applications and in particular XML-based web services or downstream integrations might be vulnerable to attack if:
• The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.
• Any of the XML processors in the application or SOAP based web services has document type definitions (DTDs) enabled. As the exact mechanism for disabling DTD processing varies by processor, it is good practice to consult a reference such as the OWASP Cheat Sheet 'XXE Prevention’.
• If your application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable.
• If the application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework.
• Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack.
5. Broken access control
Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user. Common access control vulnerabilities include:
• Bypassing access control checks by modifying the URL, internal application state, or the HTML page, or simply using a custom API attack tool.
• Allowing the primary key to be changed to another users record, permitting viewing or editing someone else's account.
• Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user.
• Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation
• CORS misconfiguration allows unauthorized API access.
• Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE.
6. Security misconfiguration
The application might be vulnerable if the application is:
• Missing appropriate security hardening across any part of the application stack, or improperly configured permissions on cloud services.
• Unnecessary features are enabled or installed (e.g. unnecessary ports, services, pages, accounts, or privileges).
• Default accounts and their passwords still enabled and unchanged.
• Error handling reveals stack traces or other overly informative error messages to users.
• For upgraded systems, latest security features are disabled or not configured securely.
• The security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values.
• The server does not send security headers or directives or they are not set to secure values.
• The software is out of date or vulnerable
7. Cross-Site Scripting (XSS)
There are three forms of XSS, usually targeting users' browsers:
Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk.
Typical XSS attacks include session stealing, account takeover,
MFA bypass, DOM node replacement or defacement (such as
trojan login panels), attacks against the user's browser such as
malicious software downloads, key logging, and other client-side
8. Insecure deserialization
Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker. This can result in two primary types of attacks:
• Object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization.
• Typical data tampering attacks, such as access-control-related attacks, where existing data structures are used but the content is changed.
Serialization may be used in applications for:
• Remote- and inter-process communication (RPC/IPC)
• Wire protocols, web services, message brokers
• Databases, cache servers, file systems
• HTTP cookies, HTML form parameters, API authentication tokens
9. Using components with known vulnerabilities
You are likely vulnerable:
• If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.
• If software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.
• If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.
• If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.
• If software developers do not test the compatibility of updated, upgraded, or patched libraries.
• If you do not secure the components' configurations
10. Insufficient logging & monitoring
Insufficient logging, detection, monitoring and active response occurs any time:
• Auditable events, such as logins, failed logins, and high-value transactions are not logged.
• Warnings and errors generate no, inadequate, or unclear log messages.
• Logs of applications and APIs are not monitored for suspicious activity.
• Logs are only stored locally.
• Appropriate alerting thresholds and response escalation processes are not in place or effective.
• Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts.
• The application is unable to detect, escalate, or alert for active attacks in real time or near real time.
You are vulnerable to information leakage if you make logging and alerting events visible to a user or an attacker