6 ms·
This should work: http://mkjon.es/xss.html http://mkjon.es/xss.html (note that your server seems to hang if I put "<script>" in the GET params, but assuming tha
by mkjones 15y ago
This should work: http://mkjon.es/xss.html http://mkjon.es/xss.html (note that your server seems to hang if I put "<script>" in the GET params, but assuming that works and thus the page is vulnerable to XSS like you intended, then this works). Just pretend the <img /> tag is a script tag.
Of course, this is kind of cheating - I exploit the fact that there's a CSRF bug on your web site. But that's kind of the point - just saying "oh well this is an XSS but it doesn't matter because this other unrelated thing prevents it" is bad security. It's entirely possible, even likely, that someone will come along at a later date and change that other seemingly-unrelated thing, having no idea that they're introducing a security hole in the process.
- brlewis 15y agoCool! 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.
- mkjones 15y agoSorry, 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. Security is hard, let's go shopping!
- brlewis 15y agoThen I think we agree: These examples might or might not be vulnerabilities, though from appearances two of them seem very likely to be.
- tripzilch 15y agoMaybe 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 :)
- mkjones 15y agoOh, 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.
- tripzilch 15y ago> 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.