上QQ阅读APP看书，第一时间看更新

Writing the description of a report

The second part of the report is the description. A description must be precise, clear, and to the point. Program owners want to have direct engagement with any text so they do not have to read much and can pick out the salient points easily. The description should not be something generic; it should be environmental and scenario-specific. This allows report readers to relate to the reports closely rather than thinking of them as generic.

Describing a vulnerability is not an easy task for a reporter. However, a method to describe a flaw in a to-the-point and a clear way is to provide links for issues that can help program owners understand, identify, and resolve the issues in a report. The reference links can be taken from technical resources, such as stack overflow, the Open Web Application Security Project (OWASP), and so on. It is not advised to copy and paste links and descriptions from automated tools and online sites. This gives a very bad impression about the reporter and shows that they did not have time even to write their own general report.

An example of a good description would be similar to the following one:

"Your web authentication endpoint, https://hackerone.com/sessions (POST), currently protects against credentials brute-force attacks only by requests rate-limiting based on IP. It was found that if an attacker sends login requests faster than every 4 seconds from the same IP address, it would get blocked. This still allows an attacker to make the following number of guesses from one single system: 15/minute, 900/hour, 21.600/day or 648.000/month. No additional protection mechanisms such as Captcha (pre-auth) or account lockout requiring additional email/phone verification (pre- or post-auth) were identified at any time. This allows for brute-forcing of credentials, for example based on breached clear-text password databases of which there are many publicly available https://wiki.skullsecurity.org/Passwords."

An example of a bad description would be something like the following:

"As you know hackerone allows us to add payout method. On selecting paypal we are asked to add paypal email id. On saving new email id. A hackerone account holder (i.e account from which payout method was changed) gets a notification email saying that "The payout method was changed from current_user@testmail.com" to New_user@testmail.com."

本周热推：

Web代码安全漏洞深度剖析计算机网络安全技术研究 Web应用安全威胁与防治捍卫隐私网络安全管理