CORS $.ajax session cookies (access-control-allow-credentials & withCredentials=true)

Question

I realize this question has been asked a dozen or more times and each response given indicates I am doing it right but perhaps I am missing something.

AJAX serves up CORS request like so...

$.ajax({
url: 'someotherdomain.com',
type: 'post',
data: {key: 'value'},
dataType: 'json',
async: false,
crossDomain: true,
beforeSend: function(xhr){
    xhr.withCredentials = true;
},
success: function(x, status, xhr){

},
error: function(xhr, status, error){

}
});

PHP serves up CORS requests like so...

header('Access-Control-Max-Age: 1728000');
header('Access-Control-Allow-Origin: http://someotherdomain.com');
header('Access-Control-Allow-Methods: POST');
header('Access-Control-Allow-Headers: Content-MD5, X-Alt-Referer');
header('Access-Control-Allow-Credentials: true');
header("Content-Type: application/json; charset=utf-8");

According to all documentation as long as the 'Access-Control-Allow-Credentials' server side header, and the 'withCredentials=true' client side header is set session cookie handling between the domains should be transparent. Am I missing something?

Answer 1

async: false

was preventing the session cookie from being sent back to the server on each request. The following fixed it.

async: true

Although this does allow for the session cookie to get set by the browser when making a cross origin request sharing call, I am now experiencing problems regarding the following scenario:

Server A sends response to client Client using CORS makes request of server B

XMLHttpRequest -> PHP -> Session handler -> MySQL -> Stored Procedure 

Due to the MUTEX locks in the PHP session management the asynchronous nature and apparently, requirement may force a work around of manually setting the cookie with a different header option such as XCookie or something similar to keep the servers session and client requests synchronized.

This particular work around does not sit well with me as I believe it would open up an easy lane of travel for session hijacking and session replay attack vectors.

Using an SSL/TLS wrapped connection may assist in preventing the above scenario but in terms of independently providing security measures for the client I do not believe this should suffice.

Anyone with any thoughts on this?