Content Injection Attack on GitHub(github.com) |
Content Injection Attack on GitHub(github.com) |
The thing I find interesting is that this wasn't a random discovered; like, you look at the first commit in the sequence and you'll see.
> \ce{$\unicode[goombafont; color:red; pointer-events: none; ...
ie. This isn't some random chance discovery.
This is someone looking to use a specific exploit with the ```math tag, already certain that there's some way of doing it.
How strange.
- the history can be rewritten, with push --force. The author might have iterated by force pushing one commit
- The author could have discovered it by change in a private repository, or another repository that they deleted
So in general, yes, but in this case, I doubt it. I’m pretty sure this git history is a real and true log of them dicking about trying to get the exploit they saw on twitter working.
…but, I guess, you could be right. /shrug
it was found by a bunch of anime-pfps on twitter and went "viral"
I think you mean “infosec professional”
(Injection in LaTeX math tags)
But the rescue murloc is cute.
https://news.ycombinator.com/item?id=40614571
but that one of course stopped working too
working snapshot (mildly nsfw):
https://web.archive.org/web/20240607215223/https://github.co...
there's another one from 2 hours earlier but that misses the cool rotating cube.
I get this in what looks like an error box
> Extra open brace or missing close brace
$600 for a low seems pretty good to me.
But telling user to do something would still be on the table.
And if I had to tweak / study a GitHub exploit, I would definitely force push to try stuff without leaving a trail for meaningless commits.
It actually didn't occur to me that the author would do this for messing around, but it could be indeed. :-)
What most companies realize early on is that you can't guarantee you'll prevent an XSS from slipping through. But, having a good template engine that sanitizes all strings automatically is good enough preventative measure, and putting all user-submitted content on a different subdomain or domain (like usercontent[dot]company[dot]com) with browser same-origin policy and perhaps CORS rules, will be enough to keep the impact contained. From there, just about everything else can be categorized as user error.
That is what happens if you are the WP admin and think that you don't need to update your plugins because "it's just XSS, nothing major".