When PullRequest was acquired, these concerns became HackerOne’s challenges. When we finalized the acquisition, we immediately added PullRequest’s assets to the scope of HackerOne’s own bug bounty program to allow ethical hackers to test these new attack surfaces.
The results exceeded our expectations. Within 48 hours, we received almost two dozen submissions.
In this post, we will focus on a report Chris mentioned in his post—a high severity, blind Cross-Site Scripting (XSS) vulnerability that existed in the PullRequest codebase for five years.
An XSS Bug Hiding for 5 Years
A vulnerability was present in a rating feature where customers provided feedback on their experience with PullRequest. After code review completion, a unique rating link is created and sent to the customer.
The hacker found an old rating link archived by the Internet Archive’s Wayback Machine and submitted a JavaScript payload through the rating form. This allowed a blind XSS attack to be executed if a PullRequest employee viewed the rating through our backend admin console.
A blind XSS vulnerability occurs when a malicious actor can submit a payload through a form or other field and is triggered by another user viewing the submitted data. These are called ‘blind’ vulnerabilities because the attacker typically has little or no visibility into what happens after the payload is submitted, making it difficult to determine if the attack will be successful. When testing for blind XSS, it's common to use a payload that pings back to a server controlled by the hacker to confirm their injection worked and determine how it is stored.
It can be hard to estimate the exact harm a blind XSS vulnerability can cause. This vulnerability could have exposed data or admin functionality reserved for employees if exploited. Payloads can make additional injections or calls to other web pages to chain together with other known vulnerabilities. Because of these risks, this report scored an 8.8 out of 10—a high severity.
Remediating and Retesting
To resolve this vulnerability, we made four changes:
- Remove the affected code. After investigation, we found the vulnerable code in the rating submission form belonged to functionality on the page that was no longer in use. Our primary mitigation was to remove this unneeded code altogether.
- Improve our overall Content Security Policy (CSP) to reduce XSS risk. A restrictive CSP protects against unsafe-inline scripts like the one used in this vulnerability. This adds another layer of defense against many XSS vulnerabilities.
- Migrate legacy code to newer frameworks. The remaining legacy portions of the PullRequest application are being migrated from JQuery to React. Many newer frameworks, including React, better protect against XSS HTML injection issues by default.
- Expire rating links. Bad actors could have exploited the vulnerability with any rating link, but it was easier for the hacker to discover because the unique links we generated were valid indefinitely. Expiring unique links like these is generally considered a best practice, so we added an expiration after 30 days.
The PullRequest team implemented our fixes and then requested a retest—a feature of the HackerOne platform that allows the original hacker to confirm correct vulnerability remediation. We received a response from the hacker in a few hours that our fix worked, and they were no longer receiving a pingback to their server. While our team had performed its own testing, receiving confirmation from the reporter provided additional reassurance.
We also looked for evidence of past exploitation to confirm our system or customer data had never been affected, which was especially important given how long this vulnerability existed. PullRequest maintains logs of all previous ratings. We reviewed the logs for code injection attempts and confirmed no prior exploitation of this vulnerability.
The Value of Hackers
This high severity XSS vulnerability was part of our application written in legacy code using an older framework from which we were migrating away. It was introduced five years earlier and never discovered by anyone, including a peer review when it was initially committed, or in a commercial pentest performed a few years later.
Yet, fewer than 48 hours after adding PullRequest’s assets to HackerOne’s bug bounty program, we received nearly two dozen submissions, including this blind XSS.
This experience was PullRequest’s first with an incentivized bug bounty program. Before the acquisition, PullRequest had a security policy and contact email but had only received a handful of reports over a few years. As a startup, PullRequest was too small to attract significant attention without any incentives.
As HackerOne's experience with PullRequest shows, inviting the hacker community to test your organization’s assets gets visibility into every part of your codebase. Hackers are not only looking at new functionality or the code you want them to see. They are improving coverage of all your code and assets, including what your organization may have forgotten or doesn’t know about.
HackerOne has always promoted the benefits of transparency. Transparency is the key to building trust in all our relationships—with customers, the hacker community, our employees, and partners.
Transparency is also critical in cybersecurity. A lot of the industry was built on a model of security through obscurity—the idea that you could build secure software and systems by hiding how they work. This model does not work and, in its worst form, leads to cases where known weaknesses and breaches are hidden.
For transparency, we have always run a public program and highlighted the importance of public disclosure as a means of building trust with your customers by being transparent about your mistakes.
Public disclosure can also have a meaningful impact on the success of your bug bounty program. We publicly disclosed this report to the global Hacktivity page on May 25th. We immediately saw an influx of hacker participation. This increase continued for over a week after public disclosure and the release of the report. We hope to see similar results from this blog post.
HackerOne Response is one component of HackerOne’s Attack Resistance Management Platform that helps your organization find and close gaps in its attack surface. For more information on improving your attack resistance, contact us.
