1,000 pts
@avlidienbrunn discovered that forms submitted using XHR are not subject to the form-action Content Security Policy (CSP) directive and might be used to exfiltrate information to any host found in our connect-src source list. While most forms on GitHub.com are submitted traditionally, and restricted by our form-action source list, we do register a number of onsubmit event handlers that result in forms being submitted using XHR. As a result, an attacker can target any form we submit using XHR and potentially exfiltrate some of the form’s contents, such as its CSRF token, to any host found on our connect-src source list.
The overall risk presented by this CSP bypass is low given that:
connect-src source list, the providers on that list may ignore the unexpected form values, making it potentially impossible for an attacker to recover them.We have not addressed this issue given the low severity and our current reliance on several third-party hosts in our connect-src source list. We will continue to investigate what new browser protections may become available in the future to help mitigate this issue.
2,500 pts
@avlidienbrunn discovered a flaw in our validation of URLs used for redirection when processing an OAuth authorization request. Unlike other browsers, Internet Explorer and Edge URL decode certain characters found in the host component of a HTTP 302 response Location header. An attacker could have exploited this flaw against Internet Explorer and Edge users to redirect users from GitHub.com to another site and gain access to an OAuth application as another user. We addressed this by restricting the characters that can exist within the host component of the redirect_uri request parameter.
500 pts
@avlidienbrunn reported a potential CSP bypass in one of our JavaScript libraries. We had already found this vulnerability and written a fix for it, but hadn’t applied the fix to GitHub.com. We addressed this issue by updating the version of the library.
1,000 pts
@avlidienbrunn reported an issue where certain GitHub.com endpoints could serve a response that would be interpreted by Adobe Reader as a PDF file when embedded on an attacker’s domain. Because Adobe products do not respect the same-origin policy or the X-Content-Type-Options header, the PDF calculator APIs implemented by Adobe Reader could be used to make authenticated HTTP requests to GitHub.com. This could be exploited to disclose the authenticated user’s data to the attacker’s domain.
This vulnerability is mitigated by the fact that a user needs to make significant configuration changes to use Adobe Reader in modern browsers for inline rendering of PDFs. Other PDF renderers are not affected by this vulnerability.
While the underlying vulnerability lies with Adobe Reader, we mitigated the issue by stripping bytes matching PDF file headers from affected endpoints. We are also continuing our effort to move user-provided content to the sessionless githubusercontent.com domain.
We strongly discourage using Adobe Reader. Google Chrome, FireFox, and Safari have built-in PDF renderers that are not vulnerable to this style of attack.
The ability to use PDF for this style of attack was originally identified by Alex Inführ in this blogpost.
750 pts
@avlidienbrunn discovered a flaw in our parsing of URLs used for redirection when processing an OAuth authorization request. An attacker could have exploited this flaw on a limited number of OAuth applications to redirect users from GitHub.com to another site and gain access to an OAuth application as another user.
An OAuth application was only vulnerable to this flaw if it is hosted on a third-party provider that allows customers to map arbitrary domains names to their hosting service. For example, let us say that an OAuth application is configured on https://YourOauthApp.com and it has a CNAME record that maps this domain to a hosting provider. If the hosting provider supports it, an attacker could register https://YourOauthApp.com.. on the same provider and it would have been considered a valid OAuth redirection URL by GitHub. We have addressed this issue by improving our redirect URL checking.
200 pts
@avlidienbrunn reported an issue where user-supplied HTML elements with name attributes matching DOM variables would prevent JavaScript from accessing those variables. For example, an element like <img src='something.png' name='querySelector'> would cause JavaScript references to document.querySelector to return the image element rather than the querySelector function. Overwriting certain variables would break GitHub’s JavaScript and in some cases cause the browser to become unresponsive.
We addressed this issue by prefixing all user-supplied name attributes in markup with user-content-. To ensure that links to user-supplied named elements on the page still functioned properly, we used JavaScript to find and scroll to the element referenced by the fragment portion of the URL.