3 ms·

an easy fix, I think, would be to always wrap the returned code in a function that would check if the domain matches a predefined whitelist and just return out

• TylerE 13y ago
  Not a fix at all. The client can examine the returned code.
  • joshstrange 13y ago
    I was pretty sure that if its comming from a different domain that this is not the case. For example: If we have legitsite.com/json-only-with-sensitive-data.js and we load that by adding a script tag to attackersite.com then attackersite.com cannot get the contents of what the legit site returned. The problem is when you either have JSONP (for which the attacker site could add a callback in the request to execute) or if you return js code that is supposed to run like in this blog post where RoR returns code like this: $('#someid').html('sensitive data'); ... In this case it's just as bad as having JSONP because the attacker site can create a <div id='someid'></div> then add the script tag then onLoad of the script tag inspect the contents of the div.
    • ivanhoe 13y ago
      actually what I had in mind was doing something like: (function () { if (location.hostname !== 'mydomain.com') return; // the real content here, e.g: $('#someid').html('sensitive data'); })(); Makes any sense?
      • homakov 13y ago
        proved above, can be bypassed
  • ivanhoe 13y ago
    Can you show an example how? Not 100% sure, but I believe all major browsers will block the direct access to the content of an external JS file from a different domain? You get just an empty string if accessing it from the DOM (at least in chrome)
• homakov 13y ago
  It's not an option. Attacker can set getter on location.domain to bypass thath "JS protection".
  • homakov 13y ago
    location.__defineGetter__('host',function(){return 'google.com'}) undefined location.host "google.com"
    • ivanhoe 13y ago
      That's a good point, haven't thought of that. So the idea sucks...
• philfreo 13y ago
  If you don't NEED to support GET requests with JSONP / JS to be evaled, then don't. If you do need to, then the trick is to prefix what the script returns with something that will always throw a syntax error or discontinue evaluation, the idea being that your script (same domain) can cut off the prefix and then evaluate the JS, but the attacker relying on a <script> tag cannot. for(;;); http://blackbe.lt/safely-handling-json-hijacking-prevention-methods-with-jquery/ http://blackbe.lt/safely-handling-json-hijacking-prevention-...