abuse_cases/process

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

Building organizational dictionary of attacks and countermeasures

With time and experience across projects, gather the list of attacks and countermeasures identified during workshops in a central location (wiki, database, file) that will be used during future workshops in combination with input from penetration testers. This dictionary will speed up future workshops significantly.

Model multi-step workflows as explicit server-side state machines

Every multi-step workflow should have an explicit state representation stored on the server, keyed to the user or session. When the workflow starts, create a record with the initial state. Each step endpoint checks the current state, performs the action, and updates to the next valid state. If a request arrives for a step that does not match the current state, reject it. Terminal actions only run if the state is exactly what is required.

Do not store workflow state in hidden form fields or client-readable cookies

Do not store the current workflow step as a hidden form field, in a cookie the client can read, or in any client-side storage. State must live on the server in storage the client cannot write to. Client-side state is input, not truth.

Reject replay attempts of completed workflow steps

Once a step in a workflow has been completed, later attempts to re-run it should fail. This is especially critical for one-time operations like applying a signup bonus, redeeming a coupon, claiming a voucher, or accepting a referral reward. Mark each such operation complete in persistent storage and treat attempts to re-run it as errors.

Set expiration deadlines on partial workflow states

Workflows that pause for user input, such as email verification, bank transfer confirmation, or multi-step KYC, should have a deadline. If the user has not progressed within a bounded time, invalidate the partial state and require them to start over. Long-lived half-completed workflows accumulate and become a frequent source of exploitable inconsistencies.

Institutional expertise for legacy application maintenance

More than one staff member should be adequately trained to troubleshoot and reconfigure the legacy application to reduce the risk of complete loss of maintenance capability if one trained member of staff leaves the organization. Staff should regularly document processes including troubleshoot guides for common failure scenarios. Where necessary, teach a core group of staff to write basic programs in the language used by the legacy application.

Incident response planning for legacy applications

Ensure incident response teams are aware that incident response and investigation of unusual events should be prioritized for critical legacy systems. Processes for handling application downtime and compromise should be documented in advance as part of an incident response playbook. This playbook needs to give staff a clear rundown of emergency procedures including escalation contacts and details of incident response leaders. Incident response planning should occur within the broader context of a business continuity plan.

Kubernetes security release schedule: backports for three most recent minor releases

The Kubernetes project maintains release branches for the three most recent minor releases and backports applicable security fixes to those branches depending on severity and feasibility. Patch releases are cut from those branches at regular cadence plus additional urgent releases when required.

Scale suspicious pods to zero to contain security breach

Use Kubernetes native controls to scale suspicious pods to zero or kill and restart instances of breached applications to contain a successful breach.

Correct decommissioning order to prevent subdomain takeover

The correct order of operations when decommissioning a service is: (1) Redirect or serve a maintenance page at the subdomain to avoid broken links; (2) Update or remove the DNS record pointing to the resource; (3) Wait for DNS propagation (at least the TTL duration, typically 300 to 3600 seconds); (4) Then decommission the cloud resource. Reversing these steps creates an immediate window for takeover that persists until the dangling record is noticed.

DNS inventory should document resource ownership and business justification

Maintain a documented mapping between DNS records and cloud resources including: What resource each CNAME, A, or NS record resolves to; Which team owns the resource; What project or service it is part of; When it was created and when it is expected to be decommissioned; What is the business justification for the subdomain. This can be a spreadsheet or CMDB for larger organizations. Infrastructure-as-Code tools like Terraform, Pulumi, or AWS CDK can serve as a living inventory when DNS records and cloud resources are managed in the same codebase.

AWS CloudFront domain association prevents subdomain takeover

For AWS CloudFront, associating a distribution with a custom domain and keeping the distribution active (even if serving a redirect) prevents another account from claiming the domain name as an alternate CNAME.

Restrict wildcard DNS records to prevent subdomain takeover

Wildcard DNS records (`*.example.com`) are especially dangerous because they resolve for any subdomain, including those matching services that no longer exist. Avoid wildcard records unless absolutely necessary. If required: (1) Scope them as narrowly as possible (e.g., `*.staging.example.com` rather than `*.example.com`); (2) Combine with a reverse proxy or load balancer that maintains an allowlist of valid hostnames and returns an error for unrecognized ones; (3) Monitor Certificate Transparency logs for unexpected certificate issuance on subdomains matching the wildcard.

Decommissioning checklist for externally facing services

Create a formal checklist that teams must follow when removing any externally facing service: [ ] Identify all DNS records (CNAME, A, MX, NS, TXT) associated with the service; [ ] Point the DNS record to a maintenance page or redirect (if immediate removal causes user-facing disruption); [ ] Remove or update DNS records; [ ] Wait for DNS propagation (at least the TTL duration); [ ] Decommission the cloud resource; [ ] Revoke or let expire any SSL/TLS certificates issued for the subdomain; [ ] Update the DNS inventory documentation; [ ] Remove the subdomain from any OAuth redirect URI allowlists, CSP directives, or CORS configurations; [ ] Verify that the subdomain no longer resolves or returns expected content; [ ] Run a takeover detection scan against the subdomain to confirm it is not claimable.

Incident response steps for subdomain takeover

If a subdomain takeover is discovered: (1) Remove the DNS record immediately to break the link between your domain and the attacker's resource; if quick removal is not possible, update it to point to an IP or CNAME you control; (2) Revoke or request revocation of any certificates issued for the subdomain during the takeover period by checking Certificate Transparency logs; (3) Assess the impact to determine whether cookies scoped to the parent domain could have been stolen, whether phishing content was served and for how long, whether any OAuth or SSO flows referenced the subdomain, and whether the attacker could have received email for the subdomain; (4) Notify affected users if there is evidence that sensitive data was exposed, credentials were phished, or session cookies were intercepted; (5) Investigate the root cause to identify the process gap that allowed the dangling record to persist; (6) Scan all DNS zones owned by the organization for other dangling records; (7) Document the incident with a timeline, impact assessment, and corrective actions.

Private Disclosure model

In private disclosure, the vulnerability is reported privately to the organization. The organization decides whether to publish the details, not the researcher. This means many vulnerabilities may never be made public. Most bug bounty programs require this model. The main risk is that unresponsive vendors may never fix or publish the vulnerability.

Full Disclosure model

Full disclosure makes vulnerability details publicly available immediately upon identification, including exploit code before patches are available. It is used as a last resort when vendors ignore reports, to pressure them into developing fixes. It is controversial and considered irresponsible by many, or when exploit code is already publicly available.

Responsible or Coordinated Disclosure model

Responsible disclosure seeks a middle ground: initial reports are made privately, with full details published once a patch is available, sometimes with a delay to allow patch installation. Researchers often set deadlines for vendor response or patching. If the deadline is not met, the researcher may adopt full disclosure. Google's Project Zero uses a variant where details are published after 90 days regardless of patch status.

Researcher reporting obligations before security testing

Before conducting any security research or reporting vulnerabilities, ensure you understand the laws in your jurisdiction. This cheat sheet does not constitute legal advice. Verify you are operating legally and within scope.

Safe harbor policies for bug bounty programs

If conducting testing under a bug bounty or similar program, the organization may have established safe harbor policies that allow you to legally carry out testing as long as you stay within the program's scope and rules. Stepping outside scope and rules may be a criminal offense. Read the scope carefully.

Extortion restriction on vulnerability payment demands

Do not demand payment or other rewards as a condition of providing information on security vulnerabilities, or in exchange for not publishing details or reporting to industry regulators, as this may constitute extortion.

Bug bounty payments as taxable income

If you receive bug bounty payments, these are generally considered as income and may be taxable. Reporting this income and ensuring you pay appropriate tax is your responsibility.

Employer vulnerability reporting restrictions

If you find vulnerabilities as part of your work or on equipment owned by your employer, your employer may prevent you from reporting them or claiming a bug bounty. Read your contract carefully and consider taking legal advice before reporting.

Finding vulnerability contact details sources

When organizations lack a clear disclosure policy, contact details may be found through: bug bounty platforms (BugCrowd, HackerOne, huntr.dev, Open Bug Bounty, Standoff365), security.txt file at /.well-known/security.txt (per RFC 9116), existing issue tracking systems, generic email addresses like security@ or abuse@, Contact Us pages, social media, phone calls, or community outreach.

Initial vulnerability report requirements

Initial vulnerability reports should include: sufficient details to understand and reproduce the vulnerability, HTTP requests/responses, HTML snippets, screenshots or supporting evidence (with personal data redacted), proof of concept code if available, the impact of the vulnerability, and any references or further reading. Reports should be written in clear, simple terms, especially for smaller organizations with non-security staff.

Avoid demanding payment in initial vulnerability contact

In initial contact with an organization without an established bug bounty program, avoid asking about payments or rewards. Wait until the issue is acknowledged or ideally fixed. Do not demand payment before revealing vulnerability details, as this looks like a scam or may constitute extortion.

Publishing vulnerability details - content requirements

Vulnerability publication should include: a high level summary of the vulnerability and its impact, details of which versions are vulnerable and which are fixed, technical details or proof of concept code, mitigations or workarounds, links to the vendor's published advisory, and the timeline for discovery, vendor communication and release.

Proof of concept code publication considerations

Whether to publish working proof of concept or functional exploit code is debated. Publishing helps system administrators and penetration testers test their systems, but some argue it directly helps criminals. However, attackers can reverse engineer working exploit code from sufficiently valuable vulnerabilities once the vulnerability is disclosed, so there is limited value to withholding proof of concept code after patch release.

Bug bounty program scope requirements

When implementing a bug bounty program, clearly define: which systems and applications are in scope (live systems or staging/UAT), whether third-party managed or owned systems are excluded, which vulnerability types are eligible for bounties (SSL/TLS issues, missing HTTP headers, version disclosure), legal provisions including safe harbor policies, bounty amounts and decision criteria, and timelines for initial response, confirmation, payout and issue resolution.

Bug bounty program implementation considerations

Bug bounty programs require substantial time and resource investment. Challenges include: having sufficient staff to respond and triage reports, handling large numbers of false positives and junk reports, managing impact of unskilled attackers testing live systems, differentiating between legitimate and malicious testing traffic, researchers going out of scope, financial costs (companies may pay hundreds of thousands annually), and handling researcher disputes. Programs should only be used by organizations with mature vulnerability disclosure processes and strong internal processes to resolve vulnerabilities.

Organization vulnerability contact publishing methods

Organizations should publish vulnerability contact details through multiple channels: a dedicated security contact on the Contact Us page, dedicated instructions on a bug tracker, a common security@ email address, a security.txt file at /.well-known/security.txt (per RFC 9116), and/or third-party bug bounty programs. Ensure frontline staff monitoring main contact addresses, web chat and phone lines know how to handle security reports and who to escalate to.

Organization vulnerability reporting guidelines

Organizations should provide guidelines for researchers including: specific information to request for confirming and resolving issues, specific categories or confidential marking on bug trackers, PGP keys for encrypted communication, timelines for initial response and triage, and established safe harbor provisions.

Ideal organization-researcher communication process

The ideal communication process: respond to initial contact with a clear mechanism for researchers to provide additional information, acknowledge vulnerability details with triage timeline, request clarifications if needed, confirm the vulnerability and provide fix timeline with reward details, request retesting if required, confirm resolution. Provide regular status updates and expected timelines even when none are firm.

Organization response to payment demands from researchers

When individuals demand payment before sharing vulnerability details, consider requesting they use a mediated bug bounty platform for disclosure. This provides protection for both sides, as scammers are unlikely to use these platforms.

Security advisory minimum content requirements

Security advisories must contain: a high level summary of the vulnerability including impact, a clear list of vulnerable versions, a clear list of patch versions, any caveats on when the software is vulnerable (such as configuration-specific impacts), and any workarounds or mitigation. Should also include a CVE for the vulnerability.

Security advisory recommended content

Security advisories should ideally also include: the timeline of the vulnerability disclosure process, credit for the researcher who identified the vulnerability, technical details of the vulnerability, and IDS/IPS signatures or other indicators of compromise.

Security advisory publication locations

Security advisories should be easy for developers and system administrators to find through: a dedicated security or security advisories page on the website, a security mailing list or forum, or linking from main changelogs and release notes.

Delaying full technical disclosure publication

For more serious vulnerabilities, it may be sensible to ask researchers to delay publishing full technical details for a period of time (such as a week) after patch release to give system administrators more time to install patches before exploit code is available. However, once the patch is released, attackers can reverse engineer the vulnerability and develop their own exploit code.

Private systems vulnerability disclosure decision

For vulnerabilities in private systems, organizations must decide whether to publish details once resolved. Most bug bounty programs allow this choice. Publishing demonstrates transparent security approach but risks exposing embarrassing details, misconfigurations, technical internals, and may be used as evidence of weak security in future breaches. This decision should be carefully evaluated with legal advice.

Rewarding researchers for out-of-program vulnerability reports

Where researchers identify and report vulnerabilities outside a bug bounty program professionally and helpfully, organizations should offer rewards. If monetary rewards are not possible, consider: service or product discounts/credit, virtual rewards (special in-game items, custom avatars), branded items (t-shirts, stickers), or credit in a hall of fame or similar acknowledgement.

Publishing security issues does not harm vendor reputation

Publishing details of security issues does not make a vendor look bad. All software has security vulnerabilities. Demonstrating a clear and established process for handling and disclosing them gives far more confidence in software security than trying to hide the issues.

SameSite cookies as defense against XS Leaks

SameSite cookies provide defense-in-depth against some classes of XS Leaks and CSRF attacks, significantly reducing the attack surface. However, SameSite may not completely prevent all XS Leaks attacks, particularly window-based XS Leak attacks such as frame counting and navigation attacks.

XS Leaks quick security recommendations

1. If your application uses cookies, set the appropriate SameSite attribute. 2. Determine whether your application needs to allow embedding in frames from other origins; if not, use framing protection mechanisms (CSP frame-ancestors or X-Frame-Options). 3. Use Cross-Origin-Resource-Policy (CORP) and Cross-Origin-Opener-Policy (COOP) headers with appropriate values to strengthen isolation between origins. 4. Use headers available within Fetch Metadata (Sec-Fetch-Dest, Sec-Fetch-Site) to build your own resource isolation policy.

Give your agent this brain