8

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?

jas-
  • 1,724
  • 1
  • 17
  • 28
  • Answer :) - You are missing browser name and jQuery version from the question... Also check out http://stackoverflow.com/questions/2054316/jquery-sending-credentials-with-cross-domain-posts – Alexei Levenkov Nov 19 '12 at 16:20
  • jQuery v1.8.3 & Mozilla Firefox & Google Chrome I am actually setting that flag as you can see in the above code – jas- Nov 19 '12 at 16:23

2 Answers2

4
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?

jas-
  • 1,724
  • 1
  • 17
  • 28
1

In your example above, you are setting the Access-Control-Allow-Origin header to 'http://someotherdomain.com', which is the same as the url you are requesting from JQuery. The Access-Control-Allow-Origin header should be the value of the domain the request is coming from. As a quick, test, try setting the value of this header to '*' (without the quotes) and see if it works ('*' means all domains are allowed).

monsur
  • 39,509
  • 15
  • 93
  • 91
  • I thought of that first, but even with the wildcard enabled (which goes against everything noted @https://developer.mozilla.org/en-US/docs/HTTP_access_control indicating that as long as the client and server both set the 'withCredentials' option to 'true' and the 'access-method-allow-origin' is set to the origin header value specified in the pre-flight cors request the request should set and send the cookies between the two domains. – jas- Nov 19 '12 at 16:49
  • Oh I'm sorry, you are quite right: * can't be used with credentials. However, maybe you can update your example for clarity; its confusing to see the "someotherdomain" string in both the client and server code. – monsur Nov 19 '12 at 17:21
  • Besides, that is actually a "bad practice" CORS implementation according to https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet – jas- May 09 '13 at 14:57
  • CORS is a hinder for the life. It actually creates more problems than solving. – Alfonso Nishikawa Jun 10 '16 at 09:42