abuse_cases/testing

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

Test workflow ordering: skip, repeat, reorder steps

For multi-step workflows, test attempts to skip steps, repeat steps, and reorder steps. The expected outcome for each deviation is a rejection, not progress. These tests document and verify the workflow state machine enforcement.

Use adversarial testing approach for business logic

Complement standard unit testing with adversarial testing: take the feature specification and write tests for ways a motivated user would try to misuse it. Imagine a user whose goal is to extract maximum value while staying within the letter of the system's rules, then test exactly what they would do. This often reproduces bugs that developer-written tests miss because the feature was not designed with that misuse in mind.

Test concurrent requests for atomicity violations

If two requests can race, write a test that races them. Most test frameworks have ways to fire concurrent requests and assert the end state is consistent (e.g., balance is never negative, coupon is redeemed exactly once, bonus is granted exactly once across all winners). Concurrency tests verify that race conditions are actually prevented.

Testing IDOR with multiple user accounts

To verify IDOR protections, create multiple user accounts with different authorization scopes. Create objects owned by each user such as documents, support tickets, or invoices. Authenticate as one user and attempt to access another user's objects by modifying object references in requests. Verify that the application denies unauthorized access regardless of whether the object identifier is predictable or unguessable. This verification should cover all operations: read, create, update, delete, export, and administrative actions.

NoSQL injection testing guidance

For testing guidance on NoSQL injection vulnerabilities, refer to the OWASP Web Security Testing Guide: Testing_for_NoSQL_Injection.html

Patch management prioritization for legacy applications

Patching efforts for legacy applications should be prioritized on the basis of the severity of the vulnerability and whether the vulnerability has a published CVE (Common Vulnerabilities and Exposures) and/or a publicly listed exploit. In circumstances where patching is not practically possible for the legacy application, consider applying additional restrictions to the application or affected components.

Vulnerability scanning tools for legacy applications

Legacy applications should be subject to regular vulnerability scanning with industry standard vulnerability assessment tools such as Nessus and Qualys. This should occur on a regular basis, ideally with scans scheduled to occur automatically at set time intervals. Where appropriate, vulnerabilities might also be identified using SAST (Static Application Security Testing) tools or SCA (Software Composition Analysis) tools. In cases where none of these options are viable, direct human assessment of host configuration and manual code reviews might be the only suitable option.

Tools to scan container filesystems for exposed secrets

Open-source tools such as Trivy and Gitleaks can scan container filesystems for sensitive resources including API tokens, passwords, and keys. These resources would be accessible to any user with access to unencrypted container filesystems whether during build, at rest in registry or backup, or running. Review secret material on containers against least privilege principle and assess compromise risk.

Container runtime security via system call interception and anomaly detection

Container runtime security detects and responds to threats and anomalies in running containers by intercepting low-level system calls and looking for events indicating compromise. Events triggering alerts include: shell executed inside container; container mounting sensitive host paths like /proc; unexpected sensitive file reads like /etc/shadow; outbound network connections established. Open source tools like Falco from Sysdig provide container runtime security with out-of-the-box detections and custom rule creation.

nuclei tool for subdomain takeover detection

nuclei is a general-purpose vulnerability scanner with a dedicated set of subdomain takeover detection templates. Templates are available at https://github.com/projectdiscovery/nuclei-templates/tree/main/dns.

can-i-take-over-xyz reference for vulnerable services

can-i-take-over-xyz is a community-maintained reference documenting which services are and are not vulnerable to subdomain takeover, with proof-of-concept details. It is available at https://github.com/EdOverflow/can-i-take-over-xyz.

Netlify service fingerprint for detection

Netlify error response is `Not Found - Request ID:`. This indicates the backend resource no longer exists.

AWS S3 service fingerprint for detection

AWS S3 error response patterns include `NoSuchBucket` and `The specified bucket does not exist`. These indicate the backend resource no longer exists.

GitHub Pages service fingerprint for detection

GitHub Pages error response is `There isn't a GitHub Pages site here.`. This indicates the backend resource no longer exists.

Heroku service fingerprint for detection

Heroku error response patterns include `No such app` and `herokucdn.com/error-pages/no-such-app.html`. These indicate the backend resource no longer exists.

Azure App Service service fingerprint for detection

Azure App Service error response is `404 Web Site not found` on `*.azurewebsites.net`. This indicates the backend resource no longer exists.

Shopify service fingerprint for detection

Shopify error response is `Sorry, this shop is currently unavailable.`. This indicates the backend resource no longer exists.

Fastly service fingerprint for detection

Fastly error response is `Fastly error: unknown domain:`. This indicates the backend resource no longer exists.

Zendesk service fingerprint for detection

Zendesk error response is `Help Center Closed`. This indicates the backend resource no longer exists.

dnsReaper tool for subdomain takeover detection

dnsReaper is an actively maintained subdomain takeover scanner supporting 40+ service fingerprints with signature-based detection. It is available at https://github.com/punk-security/dnsReaper.

WebSocket testing origin validation unauthorized domains

Test WebSocket origin validation by attempting to connect from unauthorized domains.

WebSocket testing authentication bypass without credentials

Test authentication bypass by attempting WebSocket connections without proper credentials.

WebSocket testing message injection XSS SQL injection command injection

Test WebSocket message injection by sending XSS, SQL injection, and command injection payloads.

WebSocket testing DoS resistance connection limits message flooding

Test DoS resistance by testing connection limits, message flooding, and oversized messages.

WebSocket testing session management expiration logout

Test session management by testing session expiration and logout handling.

gRPC security testing categories

Include these test categories in gRPC security testing: authentication bypass attempts, authorization boundary testing, input validation and injection testing, rate limiting effectiveness, message size limit enforcement.

gRPC security testing with grpcurl

Use grpcurl for gRPC security testing. Test authentication requirement with: grpcurl -plaintext localhost:50051 list and grpcurl -plaintext localhost:50051 myservice.MyService/GetUser. Test with invalid tokens: grpcurl -plaintext -H "authorization: Bearer invalid_token" localhost:50051 myservice.MyService/GetUser

gRPC security assessment guidelines

Test all gRPC methods for proper authentication and authorization. Verify input validation on all message fields. Test rate limiting and resource exhaustion protections. Validate TLS configuration and certificate handling. Check for information disclosure in error messages.

Give your agent this brain