abuse_cases/prevention

8 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Protect against slopsquatting: verify AI-suggested packages before installing

To protect against slopsquatting: run 'npm view <package-name>' before installing any AI-suggested package to confirm it exists; check the package download count (legitimate packages have thousands or millions while newly published malicious ones have very few); verify the package has a real GitHub repository with genuine code, commits and contributors; be suspicious of packages created recently with no release history; never blindly run 'npm install' on packages suggested by AI tools; in team environments, add 'npm view <package-name>' as a CI check before new AI-suggested dependencies reach production.

Prevent dependency confusion: use scoped packages and configure .npmrc registry

Prevent dependency confusion attacks by using scoped package names for internal packages (e.g., '@yourorg/package-name' instead of 'package-name'). Configure .npmrc to explicitly route scoped packages to your private registry: '@yourorg:registry=https://your-private-registry.example.com'. Optionally reserve internal package names on the public npm registry by publishing empty placeholders to prevent attackers from claiming them.

Protect against documentation vulnerabilities: never copy production code from README

Never copy README examples directly into production without security review—treat documentation code the same as Stack Overflow code. Check for secure defaults in the library's source code; if the library internally uses crypto.randomBytes() but the README uses Math.random(), prefer the library's approach. Validate security-sensitive parameters like patterns, keys, and credentials to ensure they match security best practices. Report insecure documentation to maintainers as it affects every developer copying the example.

SSRF and XXE Connection

If an application is vulnerable to XML External Entity (XXE) injection, it can be exploited to perform an SSRF attack. Refer to the XXE cheat sheet for prevention details.

Disable Redirects in SSRF Prevention

Disable support for HTTP redirections in the web client used for SSRF prevention to prevent bypass of input validation restrictions.

Network Layer Defense for SSRF Case 1

At the network layer for Case 1, use a Firewall component (as a dedicated device or OS-level) to define legitimate flows and prevent the vulnerable application from calling arbitrary applications. Network segregation is also highly recommended to block illegitimate calls directly at the network level.

Token-Based Proof of Legitimacy for SSRF Case 2

For SSRF Case 2, the targeted application must generate a random token (e.g., alphanumeric, 20 characters minimum) that the caller must pass via a POST parameter (parameter name limited to characters [a-z]{1,10}) to perform a valid request. The receiving endpoint must only accept HTTP POST requests.

IMDSv2 AWS SSRF Mitigation

IMDSv2 is an additional defense-in-depth mechanism for AWS that mitigates instances of SSRF attacks against the AWS Instance Metadata Service. Migrate to IMDSv2 and disable the old IMDSv1 for better protection.

Give your agent this brain