Comments on: Web 2.0 is vulnerable to attack http://www.jeremyprivett.com/blog/archives/web-20-is-vulnerable-to-attack/ Programming and Life Tue, 29 Sep 2009 22:01:20 -0400 http://wordpress.org/?v=2.8.4 hourly 1 By: Lewis http://www.jeremyprivett.com/blog/archives/web-20-is-vulnerable-to-attack/comment-page-1/#comment-4896 Lewis Wed, 04 Apr 2007 21:22:04 +0000 http://www.jeremyprivett.com/archives/web-20-is-vulnerable-to-attack/#comment-4896 Also, I just thought I'd post the best solution to the CRSF hack (which will effectively fix the JSON array hack since the request will never be accepted). <blockquote>The CSRF attack works by subverting what the browser will do with the cookie. Ideally, your cookies would be totally unavailable to anyone outside of your domain. This attack works because XMLHttpRequest in some page can use the cookies of some foreign domain when posting to that foreign domain. However the script can not read the cookie directly due to the cross-domain rules, so a slight modification of the hidden field solution is to read the session cookie using JavaScript and then adding to URLs, forms or the body of a POST request, and then checking in the server that the session cookie value that the browser sends in the header (which is subvertable) is the same as the session cookie in the request (this is not subvertable in the same way). If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.</blockquote> Basically, a piece of Javascript grabs the cookie information and sends it as a post/url to the submitting page. Because the hacker can't actually get the cookie information, they can't send the cookie information as the url/post. You then check the submitted data with the actual cookies, and if they don't match you unset() the cookie or whatever. At least that's how I think it works. Also, I just thought I’d post the best solution to the CRSF hack (which will effectively fix the JSON array hack since the request will never be accepted).

The CSRF attack works by subverting what the browser will do with the cookie. Ideally, your cookies would be totally unavailable to anyone outside of your domain. This attack works because XMLHttpRequest in some page can use the cookies of some foreign domain when posting to that foreign domain. However the script can not read the cookie directly due to the cross-domain rules, so a slight modification of the hidden field solution is to read the session cookie using JavaScript and then adding to URLs, forms or the body of a POST request, and then checking in the server that the session cookie value that the browser sends in the header (which is subvertable) is the same as the session cookie in the request (this is not subvertable in the same way).

If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.

Basically, a piece of Javascript grabs the cookie information and sends it as a post/url to the submitting page. Because the hacker can’t actually get the cookie information, they can’t send the cookie information as the url/post. You then check the submitted data with the actual cookies, and if they don’t match you unset() the cookie or whatever. At least that’s how I think it works.

]]> By: Lewis http://www.jeremyprivett.com/blog/archives/web-20-is-vulnerable-to-attack/comment-page-1/#comment-4891 Lewis Wed, 04 Apr 2007 21:10:47 +0000 http://www.jeremyprivett.com/archives/web-20-is-vulnerable-to-attack/#comment-4891 Ok I did a bit of research, and here's what it is: 1. The <a href="http://getahead.org/blog/joe/2007/01/01/csrf_attacks_or_how_to_avoid_exposing_your_gmail_contacts.html" rel="nofollow">CRSF hack</a> allows you to make an iframe that will allow you to perform requests on sites (and so it sends the cookies and authenticates you). By the cookie spec, this shouldn't be allowed but to most modern browsers do this anyway. 2. Although the browser lets you send the request, cross domain rules prevent you from reading the response (the contents of the iFrame). 3. However, because JSON is Javascript that is eval()ed, it is eval()ed and then the response is thrown away. So far, no harm (apart from sending the request in the first place :P). But the problem is, Javascript's core functionality can be changed. Most importantly, the array/object constructor can be changed. This means that when the JSON is eval()ed, you can manipulate the array constructor to still pass the response before it's thrown away. Thus allowing sensitive data to be taken. Ok I did a bit of research, and here’s what it is:

1. The CRSF hack allows you to make an iframe that will allow you to perform requests on sites (and so it sends the cookies and authenticates you). By the cookie spec, this shouldn’t be allowed but to most modern browsers do this anyway.
2. Although the browser lets you send the request, cross domain rules prevent you from reading the response (the contents of the iFrame).
3. However, because JSON is Javascript that is eval()ed, it is eval()ed and then the response is thrown away.

So far, no harm (apart from sending the request in the first place :P ). But the problem is, Javascript’s core functionality can be changed. Most importantly, the array/object constructor can be changed. This means that when the JSON is eval()ed, you can manipulate the array constructor to still pass the response before it’s thrown away. Thus allowing sensitive data to be taken.

]]> By: Lewis http://www.jeremyprivett.com/blog/archives/web-20-is-vulnerable-to-attack/comment-page-1/#comment-4649 Lewis Wed, 04 Apr 2007 09:13:10 +0000 http://www.jeremyprivett.com/archives/web-20-is-vulnerable-to-attack/#comment-4649 Okey poke. Would be interesting to know. Okey poke. Would be interesting to know.

]]> By: Jeremy http://www.jeremyprivett.com/blog/archives/web-20-is-vulnerable-to-attack/comment-page-1/#comment-4083 Jeremy Mon, 02 Apr 2007 20:15:14 +0000 http://www.jeremyprivett.com/archives/web-20-is-vulnerable-to-attack/#comment-4083 I'm going to keep a lookout for the whitepaper mentioned in the article. I'll put a link up to it when I find it, or if someone else could pass it along, that would be great. I was confused at first, myself, and I would say how I think it works... But, I'm going to read the whitepaper first to make sure I'm not completely off-base. I'll put up more details as I see them. I’m going to keep a lookout for the whitepaper mentioned in the article. I’ll put a link up to it when I find it, or if someone else could pass it along, that would be great. I was confused at first, myself, and I would say how I think it works… But, I’m going to read the whitepaper first to make sure I’m not completely off-base.

I’ll put up more details as I see them.

]]> By: Lewis http://www.jeremyprivett.com/blog/archives/web-20-is-vulnerable-to-attack/comment-page-1/#comment-4082 Lewis Mon, 02 Apr 2007 20:07:50 +0000 http://www.jeremyprivett.com/archives/web-20-is-vulnerable-to-attack/#comment-4082 I don't understand, it's impossible to send an AJAX request to a domain other than the current domain. The only exception to this is using iFrames but that's an old vulnerability and is how the sausage attack works. I don't see how JSON has any difference? JSON is used to communicate from the server to the browser, and only the server has control over that. It doesn't make sense. I don’t understand, it’s impossible to send an AJAX request to a domain other than the current domain. The only exception to this is using iFrames but that’s an old vulnerability and is how the sausage attack works. I don’t see how JSON has any difference? JSON is used to communicate from the server to the browser, and only the server has control over that.

It doesn’t make sense.

]]>