1

I was wondering if below GET requests from a HTML file and a javascript file, are vulnerable to AJAX Hijacking/JavaScript Hijacking?

AJAX Hijacking: http://haacked.com/archive/2009/06/25/json-hijacking.aspx/ JavaScript Hijacking: http://www.net-security.org/dl/articles/JavaScript_Hijacking.pdf

1)

                    var req = new XMLHttpRequest();
                    req.open("GET", queryUrl, false);
                    req.setRequestHeader("Accept", "application/json");
                    req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
                    req.onreadystatechange = function () {
                        if (this.readyState == 4) {
                            if (this.status == 200) {
                                //do something }
                                                  }
                                             }
                   req.send();

2)

                var req = new XMLHttpRequest();
    req.open("GET", encodeURI(ODataPath() + type + "Var1"+ Value1+"), true);
    req.setRequestHeader("Accept", "application/json");
    req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
    req.onreadystatechange = function () {
        if (this.readyState == 4 /* complete */) {
            req.onreadystatechange = null;
             // Do Something
    };
    req.send();
};
  • 1
    Please can you explain a bit more about the type of attack that you are trying to defend against? – SilverlightFox Sep 22 '15 at 16:13
  • More about this attack is given at haacked.com/archive/2009/06/25/json-hijacking.aspx – p_upadhyay Sep 22 '15 at 16:28
  • 2
    This is only a problem in extremely old browsers - e.g. Firefox 3. It's impossible to say from your client-side code - if it doesn't remove the "unparsable cruft" then it is likely vulnerable when a user is on Firefox 3. – SilverlightFox Sep 22 '15 at 16:35
  • Thanks! I think you're partially right. If I had access to server side code, I would have tried to find out if deny get is enabled which is one of the mitigation or something like while(1) or for(;;) is prepended with the response. That part I understand. stackoverflow.com/questions/2669690/… Challenge here is I don't have access to server side code and from the client side code, it is clear that HTTP GET is supported. With aforesaid limitations, I wanted to get someone else's view on this, hence posted this question in the forum. – p_upadhyay Sep 22 '15 at 16:44
  • If it hasn't got the while(1) or for(;;) or similar at the start, then, yes, that is what I'm saying - it is vulnerable, as we can see the requests are GET requests. You're welcome to post to the site, however there's not enough information in your question to answer in this case. – SilverlightFox Sep 22 '15 at 16:50
1

This is only a problem in extremely old browsers - e.g. Firefox 3. If your client-side code isn't removing any "unparsable cruft" then the server side is likely vulnerable. The other requirement for a vulnerability is that the JSON is retrievable via GET. From your question we can already see that these are GET requests, so you should either add an unparsable cruft or do some checking to make sure that they're on a modern browser.

The other option is to do nothing - this might not be a risk to you if such old browser usage is uncommon.

1

Your calls are fine as long as they don't send JSON arrays with sensitive information as referred to in your sources. Perhaps you could use normal HTTPS requests for that info instead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.