Abuse Case definition
An Abuse Case is defined as a way to use a feature that was not expected by the implementer, allowing an attacker to influence the feature or outcome of use of the feature based on the attacker action or input.
OWASP Cheat Sheets · all subjects
abuse_cases/definitions
29 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Technical vs Business abuse case types
Abuse cases must be marked as either Technical or Business type. Technical example: Add Cross Site Scripting injection into a comment input field. Business example: Ability to arbitrarily modify the price of an article in an online shop prior to passing an order causing the user to pay a lower amount for the wanted article.
Write down business logic invariants in plain English
For any feature that handles value, ownership, or state, write down the invariants in plain English. Examples: a user cannot approve their own request; a coupon code is valid for one redemption per user and never more than N total; a transfer cannot complete if it would leave the source account below zero; a workflow reaches approved state only after both reviewer A and reviewer B have approved. For each invariant, identify exactly what code enforces it.
OAT threat categories and endpoint risk mapping
The OWASP Automated Threats to Web Applications (OAT-001 through OAT-021) catalog abusive automation patterns. Login endpoints face OAT-008 Credential Stuffing. Signup endpoints face OAT-019 Account Creation. Search/catalog endpoints face OAT-011 Scraping. Checkout/cart endpoints face OAT-005 Scalping and OAT-001 Carding. Public APIs face OAT-011 and OAT-014. Comments/reviews face OAT-020 Account Aggregation and spam. Threat modeling should identify which OAT categories apply to each endpoint before implementing controls.
DOM based XSS is client-side injection, not server-side
DOM based XSS is injected into the application during runtime in the client directly. This differs from Reflected and Stored XSS which are server-side injection issues. All XSS attacks execute in the browser, but the injection point differs: Reflected/Stored inject during server-side processing of requests, while DOM XSS injects during client-side runtime.
Execution context and subcontexts in DOM
JavaScript is the main execution context. Within the execution context, there are subcontexts: HTML, HTML attribute, URL, and CSS. Each subcontext has distinct semantics in how they execute script code. The JavaScript parser and the HTML parser treat encoding differently in each subcontext, making it difficult to create consistent mitigation rules.
Rendering contexts: HTML, HTML attribute, URL, CSS
When a browser renders HTML and associated content like CSS or JavaScript, it identifies various rendering contexts. The HTML parser handles HTML, HTML attribute, URL, and CSS contexts. Each context has different parsing rules and security implications for XSS. These same contexts can be reached within a JavaScript execution context using equivalent DOM methods.
IDOR with non-numeric object references
IDOR is not limited to numeric identifiers. Object references can include filenames, account numbers, tokens, or other values. For example, an attacker might modify GET /documents/annual-report.pdf to GET /documents/financial-statement.pdf to access documents belonging to other users if access control checks are missing.
Three ingredients required for IDOR vulnerability
An IDOR vulnerability requires three components: (1) an object such as an account, document, support ticket, transaction or partner profile; (2) a reference to that object in the form of an ID, UUID, account number, token or slug; and (3) a missing object-level authorization check that allows a user to access or manipulate an object they should not be able to access.
LDAP injection definition
LDAP injection is an attack used to exploit web applications that construct LDAP statements based on user input. When applications fail to properly sanitize user input, malicious users can modify LDAP statements through techniques similar to SQL injection, potentially granting unauthorized permissions and modifying content in the LDAP tree.
LDAP DN Distinguished Name definition
A Distinguished Name (DN) is a unique identifier used by LDAP to store names. DNs are sometimes used to access resources, similar to a username. Example format: cn=Richard Feynman, ou=Physics Department, dc=Caltech, dc=edu.
LDAP search filter definition and notation
LDAP search filters use Polish notation (prefix notation) with standard boolean logic to search for users matching arbitrary constraints. Each DN points to exactly one entry with one or more attributes analogous to RDBMS columns.
LDAP injection root causes
LDAP injection attacks are common due to two factors: the lack of safer parameterized LDAP query interfaces, and the widespread use of LDAP to authenticate users to systems.
Mass Assignment alternative names by language/framework
Mass Assignment vulnerability has alternative names depending on the language or framework: Mass Assignment in Ruby on Rails and NodeJS, Autobinding in Spring MVC and ASP.NET MVC, and Object injection in PHP.
Mass Assignment vulnerability definition
Mass Assignment is a vulnerability where frameworks automatically bind HTTP request parameters into program code variables or objects. Attackers can create new parameters that developers never intended, which creates or overwrites variables or objects in program code that was not intended.
OS Command Injection definition
Command injection is a type of injection where software that constructs a system command using externally influenced input does not correctly neutralize the input from special elements that can modify the initially intended command.
Argument Injection as subset of Command Injection
Every OS Command Injection is also an Argument Injection. In argument injection attacks, user input can be passed as arguments while executing a specific command. For example, if user input is passed through an escape function to escape characters like & | ; etc, an attacker-controlled string can still contain additional arguments of a command like curl --help, which can lead to information disclosure or remote code execution.
OS Command Injection metacharacters list
Metacharacters that can be used in command injection attacks include: & | ; $ > < ` \ ! ' " ( )
Prototype Pollution definition and impact
Prototype Pollution is a critical vulnerability that allows attackers to manipulate an application's JavaScript objects and properties, leading to unauthorized access to data, privilege escalation, and remote code execution.
Subdomain takeover occurs when DNS CNAME points to deprovisioned cloud resource
Subdomain takeover is a vulnerability where a DNS record (typically a CNAME) points to a cloud resource or third-party service that has been deprovisioned or no longer exists. An attacker can claim the orphaned resource and serve arbitrary content on the victim's subdomain.
XS Leaks definition and attack goal
Cross-site leaks (XS Leaks) are browser side-channel attacks that exploit seemingly insignificant information exchanged in cross-site communications to infer answers about a victim's user account. Typical questions attackers seek to answer include: Is the user currently logged in? Is the user ID 1337? Is the user an administrator? Does the user have a person with a particular email address in their contact list? The attack takes place entirely on the victim's browser side, similar to XSS attacks.
Typosquatting attacks: malicious packages with names similar to popular packages
Typosquatting exploits common typing errors by publishing malicious packages with names resembling legitimate popular packages (e.g., 'crossenv' for 'cross-env', 'eslint-scope' incident). Notable attacks include eslint-scope (harvested npm tokens via process.env), crossenv, and event-stream (injected malicious code). Attackers often target credentials since packages can access environment variables.
Slopsquatting attacks: malicious packages exploiting AI assistant hallucinations
Slopsquatting is an attack targeting AI coding assistants like ChatGPT or GitHub Copilot. When developers ask AI tools for package suggestions, these models may hallucinate non-existent package names. Attackers monitor these hallucinations and publish malicious packages with those exact names, knowing developers may blindly trust and install AI-suggested packages. Unlike typosquatting which exploits human typing errors, slopsquatting exploits AI's tendency to generate plausible-looking but fake package names.
Dependency confusion attack: attacker publishes higher-version package to public registry
A dependency confusion attack occurs when an attacker publishes a malicious package on the public npm registry using the same name as your internal private package but with a higher version number. When 'npm install' runs, it may resolve the public malicious package instead of the internal one due to higher version precedence. Attackers discover internal package names through leaked package.json files on GitHub, job postings mentioning internal tools, or error messages in stack traces.
Documentation attack surface: library examples demonstrating insecure patterns
A library may implement strong security internally but its README examples demonstrate weaker configurations for brevity or backward compatibility. Developers copy these examples verbatim, unknowingly introducing vulnerabilities despite the library being designed securely. Unlike supply chain attacks, these vulnerabilities pass audit tools because the library code is safe—only the copy-pasted usage pattern is insecure.
SSRF Definition
Server-Side Request Forgery (SSRF) is an attack vector that abuses an application to interact with the internal/external network or the machine itself. Common enablers include mishandling of URLs such as external image URLs, custom webhooks, callback URLs, and internal requests to other services with poorly handled user data.
SSRF Protocol and Scheme Scope
SSRF is not limited to the HTTP protocol. While the first request is typically HTTP, the application performing the second request could use different protocols such as FTP or SMB, and different schemes such as file://, phar://, gopher://, data://, or dict://.
Two Main SSRF Cases
SSRF vulnerabilities fall into two main cases: (1) Application can send requests only to identified and trusted applications, where an allowlist approach is viable. (2) Application can send requests to ANY external IP address or domain name, where an allowlist approach is unavailable and block-list approaches must be used.
C1 Define Security Requirements controls
C1 Define Security Requirements maps to three cheat sheets: Abuse Case Cheat Sheet, Attack Surface Analysis Cheat Sheet, and Threat Modeling Cheat Sheet.