8

私はこの質問が十数回以上尋ねられたことを理解しており、与えられた各回答は私がそれを正しく行っていることを示していますが、おそらく私は何かが欠けています。

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処理は透過的である必要があります。私は何かが足りないのですか？

4

2 に答える 2

4 
async: false

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

async: true

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

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

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

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

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

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

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

于 2012-11-19T20:46:47.977 に答える
1

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

于 2012-11-19T16:34:46.413 に答える