attack surface & risk assessment

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.

Monitor Node.js event loop with toobusy-js

Use the `toobusy-js` module to monitor the event loop and detect when the server is under heavy load. When response time exceeds a threshold and `toobusy()` returns true, respond with HTTP 503 "Server Too Busy" to prevent the application from becoming unresponsive. This helps mitigate Denial of Service attacks.

X-Powered-By header removal to prevent information leakage

Remove the X-Powered-By header as it reveals server technology and causes information leakage. Use `app.use(helmet.hidePoweredBy());`. Optionally, set a false value to mislead attackers: `app.use(helmet.hidePoweredBy({ setTo: 'PHP 4.2.0' }));`

Remove unnecessary routes to reduce attack surface

Disable or remove all unused API routes as they increase the application's attack surface. Frameworks like Sails and Feathers automatically generate REST API endpoints. If a URL does not match a custom route, it may match an automatically generated route, potentially causing information leakage or arbitrary command execution. Know which routes frameworks auto-generate and disable those that are not needed.

Researcher responsibilities for vulnerability disclosure

Security researchers should: ensure any testing is legal and authorized; respect the privacy of others; make reasonable efforts to contact the security team of the organization; provide sufficient details to allow vulnerabilities to be verified and reproduced; not demand payment or rewards for reporting vulnerabilities outside of an established bug bounty program.

Organization responsibilities for vulnerability disclosure

Organizations should: provide a clear method for researchers to securely report vulnerabilities; clearly establish the scope and terms of any bug bounty programs; respond to reports in a reasonable timeline; communicate openly with researchers; not threaten legal action against researchers; request CVEs where appropriate; publish clear security advisories and changelogs; offer rewards and credit.

Private disclosure model definition

Private disclosure means the vulnerability is reported privately to the organization. The organization may choose to publish the details at its discretion, not the researcher's discretion, meaning many vulnerabilities may never be made public. The majority of bug bounty programs require this model.

Full disclosure model definition

Full disclosure means the complete details of the vulnerability are made public as soon as identified, including sometimes exploit code, often before a patch is available. It is primarily used when organizations ignore reported vulnerabilities to pressure them to develop fixes. It is considered controversial and irresponsible by many, and should only be a last resort when other methods have failed or exploit code is already public.

Responsible or coordinated disclosure model definition

Responsible disclosure finds a middle ground: initial report is made privately with full details published once a patch is available (sometimes with a delay). The researcher typically provides a deadline for response or patch provision. If not met, the researcher may adopt full disclosure. Google Project Zero follows this approach, publishing full details after 90 days regardless of patch availability.

Legal considerations for security researchers

Security researchers must understand the laws in their jurisdiction before conducting security research. If testing under a bug bounty program, safe harbor policies may permit legal testing as long as the researcher stays within scope and rules of the program. Some countries restrict reverse engineering, testing against locally installed software may not be permitted. Demanding payment as a condition for security information may constitute extortion. Bug bounty payments are generally taxable income. Vulnerabilities found at work or on employer equipment may be prohibited from reporting due to employment contracts.

Methods to find security contact details

When no clear disclosure policy exists, contact details may be found through: bug bounty platforms (BugCrowd, HackerOne, huntr.dev, Open Bug Bounty, Standoff); security.txt file at /.well-known/security.txt per RFC 9116 with required Contact and Expires fields and optional Preferred-Languages, Canonical, Policy, Hiring fields; existing issue tracking system; generic email addresses (security@, abuse@); generic Contact Us page; social media; phoning the organization; reaching out to the community. If direct contact is impossible, a national or sector-based CERT may assist.

Initial vulnerability report content requirements

An initial vulnerability report should include: sufficient details to allow the vulnerability to be understood and reproduced; HTTP requests and responses, HTML snippets, screenshots or other supporting evidence with personal data redacted; proof of concept code if available; the impact of the vulnerability; relevant references or further reading. Reports should be written in clear, simple terms. A recommendation on mitigation or resolution may be beneficial. If planning to publish after a period, this should be clearly communicated without sounding threatening. Do not demand payment before revealing details.

Ongoing communication during vulnerability disclosure

Researchers should remain professional and positive during communication with organizations. If the organization becomes unresponsive or a disclosure deadline approaches, follow up is necessary. Researchers may be asked for additional information, retest fixes, or provide recommendations. Retesting is not obligatory but providing feedback is beneficial. Organizations may be under significant internal pressure and fixing vulnerabilities in enterprise environments takes substantially longer than researchers typically expect. Constant requests for updates add pressure and should be avoided.

Options when organization is unresponsive or hostile

If an organization is unresponsive, impossible to contact, or hostile to vulnerability disclosure, researchers may: publicly disclose the vulnerability while accepting negative reaction and potential lawsuit; anonymously disclose (ensuring sufficient operational security if prior contact was made); report to a third party such as an industry regulator or data protection authority; move on. Unless the vulnerability is extremely serious, it is not worth burning out or risking career and livelihood over an organization that doesn't care.

Publishing vulnerability details - content requirements

When publishing vulnerability details, the disclosure should typically 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 vendor's published advisory; timeline for discovery, vendor communication, and release.

Publishing proof of concept code - considerations

Whether to publish working proof of concept or functional exploit code is debated. Some argue it directly helps criminals compromise users. Others note code can be used by system administrators and penetration testers to test systems, and attackers will develop their own exploit code if the vulnerability is valuable enough. Publishing in hostile circumstances (unresponsive organization or after stated period) may result in threats and legal action depending on jurisdiction and non-disclosure agreements.

Bug bounty program publication restrictions

Many bug bounty programs forbid researchers from publishing details without organizational agreement. Doing so may forfeit the bounty or result in platform ban. Researchers should read program rules before publishing.

Bug bounty program elements requiring clear definition

When implementing a bug bounty program, the following must be clearly defined: which systems and applications are in scope (live systems or staging/UAT environment, excluding third-party managed systems); which vulnerability types are eligible for bounties (SSL/TLS issues, missing HTTP security headers, version disclosure, etc.); legal provisions such as safe harbor policies with input from lawyers not this cheat sheet; bounty amounts and decision methodology to avoid excessive program cost; timeline for initial response, confirmation, payout, and issue resolution.

Challenges of implementing bug bounty programs for smaller organizations

Smaller organizations face significant challenges with bug bounty programs: insufficient time and resources to respond to reports; insufficient staff with security skills to triage reports; large numbers of false positives and junk reports; impact of unskilled attackers testing live systems with automated tools; difficulty differentiating legitimate testing from malicious attacks; researchers going out of scope; substantial financial costs (some companies pay hundreds of thousands annually); dealing with unhappy researchers disputing bounty amounts or duplicate/out-of-scope reports. Bug bounty programs should only be used by organizations with mature vulnerability disclosure processes and strong internal vulnerability resolution processes.

Organization contact methods for security researchers

Organizations should implement multiple mechanisms for researchers to contact them: dedicated security contact on Contact Us page; dedicated instructions for reporting on bug tracker; common security@ email address; security.txt file at /.well-known/security.txt per RFC 9116 with required Contact and Expires fields and optional Preferred-Languages, Canonical, Policy, Hiring fields; third-party bug bounty programs. The more mechanisms implemented, the more likely security reports will be received. Frontline staff must be aware 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 that helps confirm and resolve issues; specific categories or marking issues confidential on bug trackers; PGP keys for encrypted communication; timeline for initial response and triage; safe harbor provisions.

Ideal organization-researcher communication process

The ideal communication process: respond to initial request with clear mechanism for providing additional information; acknowledge vulnerability details with triage timeline; request clarification if needed; confirm vulnerability with fix implementation timeline and confirm reward/bounty details; request retest if required; confirm resolution. Throughout, provide regular status updates and expected timelines for triage and fixes, even if not firm, to show the vulnerability hasn't been forgotten.

Handling researchers demanding payment for vulnerabilities

Some individuals claim to have found vulnerabilities and demand payment before sharing details. While these may be legitimate, many are scams. Organizations can request disclosure through mediated bug bounty platforms which provide protection for both sides, as scammers are unlikely to use them.

Security advisory minimum requirements

A security advisory must contain: high-level summary of the vulnerability including impact; clear list of vulnerable versions; clear list of patch versions; any caveats on when software is vulnerable (e.g., specific configurations); any workarounds or mitigations available as temporary fix; a CVE for the vulnerability.

Security advisory optional contents

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

Publishing security advisory locations

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

Disclosure delays for serious vulnerabilities

For more serious vulnerabilities, it may be sensible to ask researchers to delay publishing full details for a period (such as a week) to give system administrators more time to install patches before exploit code becomes available. However, once patches are released, attackers can reverse engineer the vulnerability and develop exploit code, so there is limited value to delaying full release.

Private systems vulnerability disclosure decision

For vulnerabilities in private systems, organizations must decide whether to publish details once resolved. Most bug bounty programs give organizations the option to disclose or not. Publishing demonstrates a proactive and transparent security approach but can expose embarrassing omissions and misconfigurations. Details could be used as evidence of weak security culture in future breaches and may expose technical details helping attackers identify similar issues. This decision should be carefully evaluated with legal advice.

Non-monetary rewards for researchers

When researchers identify and report vulnerabilities professionally and helpfully outside of bug bounty programs, non-monetary reward options include: discounts or credit for services or products; virtual rewards such as special in-game items or custom avatars; T-shirts, stickers, and branded items (swag); credit in a hall of fame or similar acknowledgement.

Publishing demonstrates security maturity

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 vulnerabilities gives far more confidence in software security than trying to hide issues.

Give your agent this brain