0

I am having a java service ,which is getting called in javascript using xmlHttpRequest and it is returning XML Data. It's working fine upto IE 8.Now we are trying it in IE 11,chrome and mozilla it is giving 500 (Internal Server Error) .Code is as follows.

request = new XMLHttpRequest();
request.open('POST', SERVERHOSTNAME+"/XXXXXX/XXXXXX/XXXXX/XXXXXInsert");
request.send(req,300000);

After googling I found it is related to cross domain requests and used the following code.

request.setRequestHeader("Access-Control-Allow-Origin", SERVERHOSTNAME);

added the line to above code..Now I didn't get any error and also no output my reponseText is null.. Later I tried with $.ajax code is as follows:

$.ajax({
    url:url,
    type: "POST",
    data:req,
    dataType:"xml",
    crossDomain:true,
    success: function (response) {
        alert(response);
    },
    error:function(error1)
    {
        alert(error1);
    }
});

I am getting same error...please help me.One thing is I cannot change the service now..

JoriO
  • 1,050
  • 6
  • 13
aravind
  • 978
  • 3
  • 12
  • 21
  • allow cross browser request in crome .. check similar question.. http://stackoverflow.com/questions/2600574/crossdomain-settings-in-google-chrome.. start crome.exe using --disable-web-security as argument i.e. "chrome.exe --disable-web-security" – Girish Nov 05 '14 at 07:50
  • Thanks girish for your reply..I cannot use this option as I cannot say to all my users to start it in this mode. – aravind Nov 05 '14 at 08:05
  • 1
    `Access-Control-Allow-Origin` is a **response** header, not a request header. – Quentin Nov 05 '14 at 09:51

3 Answers3

0

Actually it's not you who is supposed to set the header. The server should set the header, Access-Control-Allow-Origin: * in the response.

The browser sees that you are sending a cross domain request. As there are security issues with cross domain requests like CSRF and XSS, the browser checks if the server allows cross domain requests by sending another request and inspecting the response headers. If the server doesn't, the browser shows an error. If the server does, it sends your request and get the response. In your case I think the server doesn't set the header in the response..

You may contact server admins and ask them to set that header from the server side. Otherwise you may try JSONP. Basic example of using .ajax() with JSONP?

Community
  • 1
  • 1
Sampath Liyanage
  • 4,776
  • 2
  • 28
  • 40
  • 1
    The same origin policy has nothing to do with XSS and very little to do with CSRF. – Quentin Nov 05 '14 at 09:52
  • XSS and CSRF attacks both depend on the server doing something with submitted data. While the Same Origin Policy will (in the case of complex requests that require a preflight OPTIONS check only) prevent attackers from doing those things with XHR it won't, for instance, stop them just crafting a `
    ` and submitting it with JS. The Same Origin Policy prevents the attacker from *reading the response* of a request to a different origin. It's there to protect data that is private between the browser user and the site the request is being made to.
     – Quentin Nov 05 '14 at 10:03
  • Submitting a crafted form without using XHR is not very dangerous compared to submitting with XHR. The page will reload and the user will be redirected to the action url. But if it's done with XHR, a user being attacked will hardly notice. Because of Same Origin Policy, an attacker will have to find vulnerabilities form same domain in order to perform a XSS or CSRF attack. But if the Same Origin Policy is not there, an attacker can use one domains vulnerability to exploit another domain (If the XHR request is to x when origin is y, the browser sends cookies of x not cookies of y) – Sampath Liyanage Nov 05 '14 at 10:58
  • "It's there to protect data that is private between the browser user and the site the request is being made to". Could you explain this more? – Sampath Liyanage Nov 05 '14 at 11:00
  • 1
    Alice uses her online banking which is handled by a website run by Bob. Alice visit's Mallery's website. Mallery's website sends JavaScript to Alice's browser that makes it make a request to Bob's website. The Same Origin Policy prevents Mallery's JavaScript from reading the data on Bob's website (which would be Alice's bank account details). – Quentin Nov 05 '14 at 11:03
  • Thanks.. I feel like this is CSRF. There is CSRF vulnerability with Bob's website. Otherwise Bob's website wouldn't have sent those account information without checking for a CSRF token... Mallery is exploiting that vulnerability, by acting like Alice performing an action Alice didn't intend to do... – Sampath Liyanage Nov 05 '14 at 11:16
  • No. It is *expected* to be able to fetch data from a website given a URL and any authentication needed to identify yourself as authorised. There is no vulnerability because the Same Origin Policy protects the data. – Quentin Nov 05 '14 at 11:18
  • If, on the other hand, Bob's website allowed Mallery's website to trigger a transaction, then there would be a CSRF vulnerability. – Quentin Nov 05 '14 at 11:20
  • I meant if there was no Same Origin Policy then, it (the story) would be a CSRF attack. But having Same Origin Policy has prevented that CSRF attack... Therefore Same Origin Policy prevents CSRF attacks. – Sampath Liyanage Nov 05 '14 at 11:29
  • No, because it wouldn't meet the definition of a CSRF attack since it wouldn't involve an HTTP request that had side effects. The argument "CSRF attacks might be defined differently if browsers hasn't implemented certain security restrictions back when JS was first introduced" isn't a very useful area of discussion. – Quentin Nov 05 '14 at 11:31
0

Single line which helped me is to add 

request = new XMLHttpRequest();
request.open('POST', SERVERHOSTNAME+"/XXXXXX/XXXXXX/XXXXX/XXXXXInsert");
request.setRequestHeader("Content-Type", "text/xml; charset=utf-8");
request.send(req,300000);

I found that 500 error is not only related to cross domain and even to other things ..

aravind
  • 978
  • 3
  • 12
  • 21
-2

Please try to debug your code in the back-end.

Create a break point upon calling the script that the URL refers to in your AJAX call. I believe that will enlighten your problem.

If you script in the back-end did not trigger the debug, then something is wrong in your AJAX call or might in your other JS script.

Mark Moreto
  • 77
  • 7