Documenting security exploits is a critical practice in cybersecurity, helping to inform others, facilitate fixes, and ensure proper recognition for discoveries. Here are some best practices and insights from Redditors on how to document security exploits:

General Practices

• Understand the Difference Between Exploits and Vulnerabilities: Exploits are often the result of vulnerabilities, which are bugs in applications. It's important to differentiate between the two when documenting. "We need to separate out a few concepts here that you've sort of conglomerated together... Exploits and vulnerabilities are two very different things."

• Fuzzing and Reverse Engineering: Many exploits are found through a combination of fuzzing (sending malformed input to a program) and reverse engineering. "Typically though people find bugs by auditing a program... Either by code review or binary analysis ... And fuzz testing."

Documentation Steps

1. Detail the Vulnerability: Clearly describe the vulnerability, its type (e.g., SQL injection, XSS), and the conditions under which it can be exploited. "Broken object level authorization. I find it on almost every web app/API test."

2. Provide Steps to Reproduce: Include a step-by-step guide on how to reproduce the exploit. This is crucial for developers to understand and fix the issue. "I accidentally figured out a method where I can gain access to any client account as long as I know the email address."

3. Explain the Impact: Describe the potential impact of the exploit, such as data breaches, unauthorized access, or service disruption. "The company provides house appliances devices and offers laundry services to institutions (B2B type of model). My question is simple: what do I do now?"

4. Suggest Mitigations: Offer recommendations for how to fix the vulnerability. "Do you have a policy in place: eg vulnerabilities with CVSS3 score of 8-10 must be fixed with 7 days, CVSS3 score 6-7 14 days etc?"

Ethical Considerations

• Responsible Disclosure: Contact the affected company first and give them time to fix the vulnerability before publicly disclosing it. "First thing to do is try to be in touch with the company, and report your findings to them."

• Legal Implications: Be aware of the legal repercussions of hacking without permission, even if your intentions are good. "There are legal repercussions to hacking without permission, even if you have the best intentions."

Tools and Resources

• CVE Submissions: Consider submitting the vulnerability to the Common Vulnerabilities and Exposures (CVE) database. "I only know about the CVE publications where I can submit something. But what after that?"

• OSINT Tools: Use tools like SpiderFoot and Google Dorks to gather information and potentially uncover vulnerabilities. "SpiderFoot is the swiss army knife of automated OSINT."

Additional Tips

• Document Accidental Discoveries: Sometimes vulnerabilities are found by accident. Document these thoroughly as well. "You can indeed find exploitable vulnerabilities by accident although it's rare."

• Learn About Secure Development Lifecycles: Understand the Secure Software Development Lifecycle (SSDLC) to better identify and document vulnerabilities. "Everyone should be reading up on Secure Software Development Lifecycle, OWASP, SAST, DAST, and all the various stages a which security plays a role."

Subreddits for Further Questions

• r/cybersecurity

• r/AskNetsec

• r/hacking

These practices and resources should help you effectively document security exploits and navigate the ethical and legal considerations involved.