500 pts
@VishnuDfx discovered that clicking the “sign in” button, when viewing a secret Gist, would navigate the user to the login page with the Gist URL in the ?return_to= query parameter. This query paramter was then sent to our analytics provider, giving them the URL to the secret Gist.
We addressed this issue by not sending the query string to our analytics provider on our login page.
500 pts
@VishnuDfx discovered that password reset tokens were being sent to GitHub’s Google Analytics account when a user clicked on a password reset link. If an attacker had access to GitHub’s Google Analytics account, they could use an unused password reset token to change the password of the associated user. We addressed the vulnerability by sanitizing the URL sent to Google Analytics on the password reset page.
200 pts
@vishnudfx reported an issue where an unclaimed subdomain on Heroku could have been claimed by an attacker and used as a convincing phishing vector.
500 pts
@SindhujaReddy and @VishnuDfx discovered that the Referer header was being sent to our third-party subresource hosts. While Gist set a referrer policy in the <head> tag to prevent referrer disclosure, it was failing to do so for our subresource includes. Browser enforcement of referrer policies is dependent on the position of the policy in the <head> tag. Because all of our subresource includes were positioned before our referrer policy, the policy was not applied to them. We remediated the issue by moving the referrer policy higher in the <head> tag.
Note: While remediating this issue we found that Chrome was failing to enforce the referrer policy for subresource includes, regardless of the position of the policy in the <head> tag. We opened an issue and it was promptly fixed.
200 pts
The Referrer specification from the W3C Web Application Security Working Group gives site authors greater control of the Referer[sic] request header that browsers automatically send in many cases. For example, we set <meta name="referrer" content="origin"> for pages with sensitive information which instructs the browser to send the origin instead of the full URL. We recently rolled out origin-when-crossorigin nearly site-wide… or so we thought. @VishnuDfx reported that we forgot to add the tag to our static error pages. While there was no known chained attack leading to the exfiltration of secrets, these error pages may contain sensitive information so we set origin-when-crossorigin for our static error pages just in case.
Note: origin-when-crossorigin has been reclassified as origin-when-cross-origin and may stop working in newer browsers soon.
