Cross Origin Request being made without CORS - ajax

Somehow, we are able to make a cross origin XHR request on Chrome (latest stable) & Firefox without using CORS or anything of the sort. I am puzzled by this, hence this question.
Make an XHR Post Request to http://partychat-hooks.appspot.com/post/p_mwe2ztni with the data:
{body:"Some text"}
If you are on a Jquery enabled site, just type $.post("http://partychat-hooks.appspot.com/post/p_mwe2ztni",{body:"Hello World"}) on the console. SO has Jquery, so you can just press F12 now and paste this in your console.
The request goes from "Pending" to "cancelled" over in the network tab. The browser even gives us a warning about However, wireshark tells me that the request is actually getting made. (and is confirmed by a ping on the chatroom (join us at abhshkdz#im.partych.at)).
The following screenshots shows 3 things:
The request was made by JS
The browser aborted the request as it was a Cross-Origin Request w/o CORS. (Presumably an OPTIONS request should have been sent)
The popup on top-right shows that the request succeeded somehow.
Here is a screenshot of WireShark showing the Request response (served over Google AppEngine)
You can get the pcap file from here.
Also, notable is the fact that I don't see any OPTIONS request being made by the browser at all (which it should to check for CORS support).
Someone please help us solve this mystery.

Provided the request is a 'simple method' (GET/HEAD/POST) and the headers are all 'simple headers', then the browser can follow the 'simple' steps for the request, which don't include an OPTIONS pre-flight.

Related

500 error in Console, but nothing in Network

In Chrome Developer Tools, I'm getting a 500 error in the Console tab, for a GET request:
But in the Network tab, I don't see that request; I only see a POST request for the same page, with a 200 status:
Shouldn't I be seeing the SplitShip.aspx GET request in the Network tab?
Shouldn't I be seeing the SplitShip.aspx GET request in the Network tab?
You should of course, but maybe this request has been made using an AJAX call or something. So make sure you apply proper filter to your Network tab by selecting All:
This way Chrome will show All requests being sent to the server, including XHR ones. Are you seeing the smoking gun now?

Do browsers allow cross-domain requests to be "sent"?

I am newbie to website security and currently trying to understand Same-Origin-Policy in some depth.
While there are very good posts on stackoverflow and elsewhere about the concept of SOP, I could not find updated information on whether chrome and other browsers allow cross-domain XHR post requests to be 'sent' from the first place.
From this 5 year old post, it appears that chrome allows the request to pass through to the requested server but does not allow reading the response by the requester.
I tested that on my website trying to change user info on my server from a different domain. Details below:
My domain: "www.mysite.com"
Attacker domain: "www.attacker.mysite.com"
According to Same-Origin-Policy those two are considered different Origins.
User (while logged in to www.mysite.com) opens www.attacker.mysite.com and presses a button that fires a POST request to 'www.mysite.com' server...The submitted hidden form (without tokens in this case) has all the required information to change the user's info on 'www.mysite.com' server --> Result: CSRF successful attack: The user info does indeed change.
Now do the same but with javascript submitting the form through JQuery .post instead of submitting the form--> Result: Besides chrome giving the normal response:
No 'Access-Control-Allow-Origin' header is present on the requested
resource
, I found that no change is done on the server side...It seems that the request does not even pass through from the browser. The user info does not change at all! While that sounds good, I was expecting the opposite.
According to my understanding and the post linked above, for cross-domain requests, only the server response should be blocked by the browser not sending the post request to the server from the first place.
Also, I do not have any CORS configuration set; no Access-Control-Allow-Origin headers are sent. But even if I had that set, that should apply only on 'reading' the server response not actually sending the request...right?
I thought of preflights, where a request is sent to check if it's allowed on the server or not, and thus blocking the request before sending its actual data to change the user info. However, according to Access_Control_CORS , those preflights are only sent in specific situations which do not apply to my simple AJAX post request (which includes a simple form with enctype by default application/x-www-form-urlencoded and no custom headers are sent).
So is it that chrome has changed its security specs to prevent the post request to a cross domain from the first place?
or am I missing something here in my understanding to the same-origin-policy?
Either way, it would be helpful to know if there is a source for updated security measures implemented in different web browsers.
The XMLHttpRequest object behavior has been revisited with time.
The first AJAX request were unconstrained.
When SOP was introduced the XMLHttpRequest was updated to restrict every cross-origin request
If the origin of url is not same origin with the XMLHttpRequest origin the user agent should raise a SECURITY_ERR exception and terminate these steps.
From XMLHttpRequest Level 1, open method
The idea was that an AJAX request that couldn't read the response was useless and probably malicious, so they were forbidden.
So in general a cross-origin AJAX call would never make it to the server.
This API is now called XMLHttpRequest Level 1.
It turned out that SOP was in general too strict, before CORS was developed, Microsoft started to supply (and tried to standardize) a new XMLHttpRequest2 API that would allow only some specific requests, stripped by any cookie and most headers.
The standardization failed and was merged back into the XMLHttpRequest API after the advent of CORS. The behavior of Microsoft API was mostly retained but more complex (read: potentially dangerous) requests were allowed upon specific allowance from the server (through the use of pre-flights).
A POST request with non simple headers or Content-Type is considered complex, so it requires a pre-flight.
Pre-flights are done with the OPTIONS method and doesn't contain any form information, as such no updates on the server are done.
When the pre-flight fails, the user-agent (the browser) terminate the AJAX request, preserving the XMLHttpRequest Level 1 behavior.
So in short: For XMLHttpRequest the SOP was stronger, deny any cross-origin operations despite the goals stated by the SOP principles. This was possible because at the time that didn't break anything.
CORS loosened the policy allowing "non harmful" requests by default and allowing the negotiation of the others.
OK...I got it...It's neither a new policy in chrome nor missing something in SOP...
The session cookies of "www.mysite.com" were set to "HttpOnly" which means, as mentioned here, that they won't be sent along with AJAX requests, and thus the server won't change the user's details in point (4).
Once I added xhrFields: { withCredentials:true } to my post request, I was able to change the user's information in a cross-domain XHR POST call as expected.
Although this proves the already known fact that the browser actually sends the cross-domain post requests to the server and only blocks the server response, it might still be helpful to those trying to deepen their understanding to SOP and/or playing with CORS.

firefox repeating text/html GET http requests to the web app

Via Firefox, if I do a GET text/html request to my web app, I get a 200 response back, and then Firefox sends 3 more of the same request right afterward. All return 200s. Does anyone know what would cause this?
*Some other observations about the issue:
In Firebug's network tab, only one request shows up. I can only see the extra requests using Tamper Data or another tool that sees the Http requests sent from my browser.
This issue does not happen in prior versions of my web app. When I compare the responses that get returned by the two different versions of the web app, I can't see anything that would cause this issue (but then, I really don't know what to look for). The responses are identical except for the web app's cookies, which are different.
This issue happens with JavaScript enabled or disabled.
Something similar is happening with Chrome, though it seems to be sending only 2 extra requests.
I don't see any browser redirects in the Html header.
This is only happening with text/html requests, not css requests, for example.
All 4 responses returned seem to have the complete Html page in the body, and they also have the cookie that the web app uses.
In Tamper Data, the 'Load Flags' column (whatever that is) says the following: First request is VALIDATE_ALWAYS_LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI; second and third requests are LOAD_NORMAL; fourth request is LOAD_FROM_CACHE VALIDATE_NEVER
I don't see it happening with POSTs
It does not happen when the response is a 302.
If I go into the firefox config and set network.http.max-connections-per-server to 1, then Firefox only sends one request (the issue does not occur). (I don't think I can ask all our users to do that. :-))
*Why this issue is a problem:
This site has been around a long time and wasn't designed for this behavior. It's probably not going to go well.
(edited to add new findings)

Allowing cross-domain requests in Safari and Chrome? Server response vs. command line arguments

I am trying to make cross-domain requests with Safari on Windows. My Safari version is 5.1.2.
This is a classical question. I read in many places that Chrome and Safari allows cross domain requests as long as Server responds with the followin header in the response
Access-Control-Allow-Origin: *
I have read this post.
How to allow cross-domain requests in Safari?
and many others on the stackoverflow site too.
However, none of them answers my question.
I am having problems with Chrome AND Safari doing cross-domain AJAX requests even though I am sending the necessary header back from the server.
I finally ran Chrome with "--disable-web-security". Then it worked.
My questions:
1) What do I do with Safari? Do I use a similar command line argument?
2) More importantly, can I someone please tell me whether cross-domain functionality is allowed in Chrome and Safari by default as long as server responds with the header or do I have to make sure that
a) server responds with a header
AND
b) browser is started with a proper argument.
I found the problem. Reading more about CORS helped html5rocks.com/en/tutorials/cors. I realized that my requests were triggering preflight requests (OPTIONS) and the server was not set up to handle these requests properly. The reason it was causing preflight requests was because I was using JQuery and it was adding a custom header into my requests. I modified my code to prevent addition of this extra header and my requests no longer needed preflight requests. Now I do not have to disable web security and it works fine.

How to find whether Ajax request successfully send by Fire-bug add-on?

Please can some one explain me how to use Fire-bug add-on to check about whether Ajax request successfully send from our application ???
When you turn on Firebug, there's tab called 'Network' - there are shown all requests, especially ajax. The network tab allows you to filter requests and check request/response headers, status code, and message.
So, if you turn on Firebug and open Network tab (it's possible you'll have to enable tracking first, in that case it will show appropriate message), you will see if there was a request, where you expected it should be.
To see only ajax requests, check XHR on top bar, just under general tabs.
It will display in 'console' tab in firebug. i show you ajax call and request. it show ajax request like if ajax is successful then is gives 200 request and display the data or if the ajax request if fails is gives you a 301 request or some other request.

Resources