A nice POC would have been to write some XSS code which adds your SSH key to a users account if they're logged in when viewing the XSS. I wonder how many HN'ers that would have affected, and git repositories that would have exploited.
I don't think it is an exageration to say that an XSS flaw on something like github has the potential to be disasterous.
XSS trivially compromises your cookie. If I have your cookie, I am you. Demonstrating cute ways to do things that I could just do by logging in as you is superfluous.
Even doing that as a prank would cause a Big Red Button security audit at some companies. As in, drop what you're doing, we need to go over every line of every commit in the git repo and verify nothing like a server password was committed. Recommendation #1 from that audit will be to stop using github.
> Even doing that as a prank would cause a Big Red Button security audit at some companies. As in, drop what you're doing, we need to go over every line of every commit in the git repo and verify nothing like a server password was committed. Recommendation #1 from that audit will be to stop using github.
We know that the two scenarios (ssh key injection as a prank and what happened here as a prank) are equivalent.
If a company reacts like that in your scenario but doesn't do the same after what really happened, they're doing something very wrong.
I wouldn't trust that, since there are many paths to the cheese besides document.cookie. For example, Firefox (IIRC) will let Javascript inspect all headers from an Ajax request. The cookie is just another string there...
Is that actually possible, or are you just pondering that it might be? If Firefox lets you access the raw HTTP Cookie header of a http-only cookie via AJAX, I would consider that a security bug, and report it...
I may take out 10 minutes to have a play with that later if nobody else checks first...
I have personal knowledge that it was possible in 2007. I don't keep abreast of developments in browser security that make them more secure: unlike, say, Thomas and the geniuses at Matasano, all I need to know is the worst possible consequence of whatever our wonderful outsourcing partners dreamed up this time. XSS was one step below server-side code execution on our severity scale.
The big security hole, as alluded to above, is that Firefox (and presumably Opera) allow access to the headers through XMLHttpObject. So you could make a trivial JavaScript call back to the local server, get the headers out of the string, and then post that back to an external domain. Not as easy as document.cookie, but hardly a feat of software engineering.
Totally academic debate. HttpOnly is a band-aid; being able to inject Javascript still lets me do almost anything that I'd ever want to do with that cookie in the future.
That actually sounds like an awful way to report an XSS. Honestly, as someone that maintains a web service I have to say I'd prefer private disclosure than even the rickroll approach. All it takes is one "genius" doing some copy-paste action and then you're in a world of hurt and damage control.
Regarding this and the other response to me. I would never do what I described. I was just trying to demonstrate to those that don't understand XSS properly, that these issues are serious. I don't think a Rick Rolling really gets that issue across.
If I do an XSS attack against you on github whilst you are logged in, I can compromise all of your source repositories, your code, and in turn, potentially compromise the systems of your users.
Yes, soon after posting I realised it wasn't the best idea I've ever had. I regret posting this before the Github guys got a chance to fix the hole. Not something I'm going to repeat.
