web-dev-qa-db-ja.com

CORS $ .ajaxセッションCookie（access-control-allow-credentials＆withCredentials = true）

この質問は12回以上行われており、それぞれの回答は私が正しく行っていることを示していますが、何かが足りない可能性があります。

AJAXは次のようにCORSリクエストを処理します...

$.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はそのようなCORSリクエストを処理します...

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");

すべてのドキュメントによると、「Access-Control-Allow-Credentials」サーバー側ヘッダーと「withCredentials = true」クライアント側ヘッダーが設定されている限り、ドメイン間のセッションCookie処理は透過的である必要があります。私は何かが足りないのですか？

ajaxcookiescors
8
jas-
async: false

リクエストごとにセッションCookieがサーバーに返送されないようにしていました。以下はそれを修正しました。

async: true

これにより、クロスオリジンリクエスト共有呼び出しを行うときにブラウザによってセッションCookieが設定されるようになりますが、次のシナリオに関して問題が発生しています。

サーバーAは、CORSを使用してクライアントクライアントに応答を送信し、サーバーBを要求します。

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

PHPセッション管理の非同期性のMUTEXロックにより、明らかに、要件により、XCookieなどの別のヘッダーオプションを使用してCookieを手動で設定する回避策が必要になる場合があります。サーバーセッションとクライアント要求が同期されました。

この特定の回避策は、セッションハイジャックやセッションリプレイ攻撃ベクトルのための簡単な移動手段を開くと私は信じているので、私にはうまくいきません。

SSL/TLSラップ接続を使用すると、上記のシナリオを防ぐのに役立つ場合がありますが、クライアントにセキュリティ対策を個別に提供するという点では、これで十分ではないと思います。

これについて何か考えがある人はいますか？

4
jas-

上記の例では、Access-Control-Allow-Originヘッダーを「http://someotherdomain.com」に設定しています。これは、JQueryに要求しているURLと同じです。 Access-Control-Allow-Originヘッダーは、リクエストの送信元のドメインの値である必要があります。簡単なテストとして、このヘッダーの値を「*」（引用符なし）に設定して、機能するかどうかを確認してください（「*」は、すべてのドメインが許可されていることを意味します）。

1
monsur