We endorse “responsible disclosure” of security issues: If security professionals identify potential security issues, they should contact the affected party before reporting anything publicly. The affected party should investigate the potential problem and share essential information with the reporter. If a security vulnerability exists, both parties should agree on what they report publicly, including public acknowledgment of the security professional.
While this process sounds excellent in theory, we don’t experience it in the role of the receiving party. Every month, “security researchers” report “critical security vulnerabilities” on infosec-handbook.eu. Some examples:
- Exposed index.xml file: Several people reported our RSS feed in index.xml as an exposed XML file that contains sensitive information. — Of course, we expose our RSS feed. An RSS feed isn’t sensitive, though.
- Outdated Joomla version in use: Another “researcher” found Joomla 1.5 in the same index.xml file and claimed we use an outdated version of Joomla. — We don’t use any CMS but mention Joomla 1.5 in one of our articles.
- Missing DMARC record: Many people notified us about a missing DMARC record for our website. One “researcher” attached a screenshot as proof that the record is missing while it clearly showed the DMARC record. — These people use an e-mail server, misconfigured on purpose, to show issues that don’t exist.
- Vulnerable for BREACH: Yes, we are vulnerable like thousands of websites—in theory. BREACH exploits the ubiquitous HTTP compression. — Disabling HTTP compression doesn’t result in more security. BREACH perfectly demonstrates why you need to assess risks.
- Missing HTTP response headers: Some people also report missing HTTP response headers like “X-Frame-Options,” “X-Xss-Protection,” or the “Permissions-Policy.” — We cover HTTP response headers in multiple articles on our website. Such headers are either deprecated or unsupported.
Apart from such reports, some people beg for money: They claim a critical security vulnerability exists on your website, but they won’t tell you about it until you agree on paying for their report. When you justifiably disagree, specific individuals even go further, threaten to publish a blog post on your irresponsible behavior and the critical vulnerability. In such cases, we recommend just sitting it out.
To be clear: We know the frustrating stories of security professionals who identified real security issues, but organizations seem to ignore them. We privately reported potential security issues to more than 200 parties ourselves. While many parties reacted responsibly, some don’t care.
However, as a reporter, you need to realize that you don’t know the big picture in most cases. For instance, web servers exposed on the internet are black boxes. You don’t know the architecture of their back end, the configuration of their services, or how underlying databases store secrets. Black-box testing is the most inaccurate approach to security assessments. Potential security issues may evolve into wrong assumptions.
Looking at the majority of reports we get, it seems like most individuals scan dozens of distinct websites for the same issues each day. Then, they let loose a barrage of—yes, we need to say this—low-quality reports, claiming they are “security researchers” who identified “critical security vulnerabilities” and now demand payment.
While one won’t become a professional doctor by using a scalpel, one also won’t become a “security researcher” by running Burp Suite Professional.
In our opinion, such behavior casts a poor light on the security industry, especially on bug bounty programs. “Bug bounty programs” should be the cherry on the security cake for both parties. They shouldn’t become the primary source of income for people who send loads of e-mails each day without understanding the output of their tools or the scope of their scans.