Cool! I'll look into the CSRF bug. EDIT: Using a vulnerability in another demo page definitely is cheating. But I do like the hack.
To be clear, "oh well this is an XSS but it doesn't matter" is not something I ever said. I only ever said that most of the screenshots in the article don't by themselves demonstrate a vulnerability on Apple's web sites.
EDIT 2: There was another demo on my server that let you set arbitrary cookies. This exploit relied on setting the JSESSIONID cookie. If a similar exploit existed on Apple's web site, presumably this would defeat the purpose of the exploit, since the target user would no longer be authenticated as him/herself. I changed the cookie demo not to allow arbitrary cookie names, just to prevent it interfering with other demos.
> To be clear, "oh well this is an XSS but it doesn't matter" is not something I ever said. I only ever said that most of the screenshots in the article don't by themselves demonstrate a vulnerability on Apple's web sites.
True, they may require some clever hacking to really exploit.
But experience has shown me that (way) more often than not, even though an XSS might not be directly exploitable, there will be further (perhaps not so critical) security problems that will lead to an exploit, given an at-first-sight-not-so-exploitable XSS.
So it's always a better idea to make sure the XSS is not there in the first place, because if someone figures out a way to leverage it, they'll have full control over a visitor's browser on that domain.
Maybe the innocent flaw that allows the exploit isn't even there yet at first, but gets added accidentally with later development. It's still the XSS that is the most critical problem.
Sorry, didn't mean to put words in your mouth. I just wanted to point out that even when it seems like an XSS doesn't demonstrate a vulnerability, some of your assumptions may be wrong and it actually does.
Maybe next time you can leave the bug in there and just copy the demos to a new set with the fixes? Because I'd like to have seen how this worked, except it no longer works :)
Oh, sorry. Basically he had another endpoint that let you set an arbitrary cookie to an arbitrary value (with no csrf protection).
So first I had it hit that endpoint, setting the JSESSIONID cookie to my value (off of which the csrf token is keyed). Then I had it redirect to an xss'd page with my csrf token, which it would see as valid because it matched the (forced) JSESSIONID.
To be clear, "oh well this is an XSS but it doesn't matter" is not something I ever said. I only ever said that most of the screenshots in the article don't by themselves demonstrate a vulnerability on Apple's web sites.
EDIT 2: There was another demo on my server that let you set arbitrary cookies. This exploit relied on setting the JSESSIONID cookie. If a similar exploit existed on Apple's web site, presumably this would defeat the purpose of the exploit, since the target user would no longer be authenticated as him/herself. I changed the cookie demo not to allow arbitrary cookie names, just to prevent it interfering with other demos.