httpリクエストへの応答を制御するには？（サーバー側とクライアント側）

すべての主要なブラウザと同期化されたトークンパターンと同じオリジンポリシーを除いて（すべての要求をトークン化するのは難しいでしょう）、リクエストが私のユーザーインターフェイスではなく、第三者を通じて提供されます。httpリクエストへの応答を制御するには？（サーバー側とクライアント側）

たとえば、iframeからyoutubeにリクエストを送信すると（つまり、src = ... not xmlhttprequestオブジェクトを意味する）、応答は空白のページになります（リクエストはどのように送信されますか）。 iframeからfacebook ajax.hovercard（コンテンツ取得リクエスト）を受け取ると、アドレスバーから空白のページ（コンテンツなし）が表示されます。 SO応答は、iframe要求からの通常のコンテンツです。

私の前に言ったように、要求は信頼できるソースから来ているかどうかをチェックします（いくつかのサーバー側のコードが望ましい）。

P.S. ：ヘッダー、idkに頼らないでください。なぜ起源がリクエストから受信しないのですか。また、すべての主要なブラウザで原点ヘッダーが実装されています。登録者は、一部のスパイウェアプログラムによって変更することができます。とにかくヘッダーは本当に信頼できるものではありません。しかし、そのようなshowldはチェックのための層であることは確かです。

出典

2012-04-06 Cata Cata

サードパーティを定義してください。 ISPもサードパーティーではないのですか？私はあなたがそれを所有していないことを意味します、そうですか？ – hakre

@hakre私はそれが明らかにこの問題は、クロスドメインのリクエストに関するものだと思っています。 –

$_SERVER['HTTP_REFERER']を確認し、自分のサイトから来ているかどうかを確認してください。

出典

2012-04-06 09:36:53

あなたの回答は、私はp.s.を追加しました。 –

あなたは本当にユーザーの起源を確かめることはできません。ユーザエージェントは簡単に偽装することができます。あなたのユーザーインターフェイスでいくつかのcsrfトークンを作成して、それらのトークンを持つクライアントのみを許可することができると思います

出典

2012-04-06 09:41:21

ええ、それは私が恐れていた、他の簡単な解決策を見つけることができません –

csrfの保護は実装が比較的簡単です。各ユーザーのセッションごとにトークンを作成し、Cookieに格納し、各ユーザーのアクション（POST、GET）にトークンを追加します。 http要求で渡されたトークンがクッキーからのトークンと等しい場合、ユーザーは合法です。もちろん、トークンをどのように作成したのかを攻撃者が知っていれば、これを偽装することもできます。 –

シンクロナイザトークンパターンを長いレーダムトークンで偽装することはできません。私はセッション変数を意味することを願っています。 –

httpリクエストへの応答を制御するには？ （サーバー側とクライアント側）

答えて

関連する問題

httpリクエストへの応答を制御するには？（サーバー側とクライアント側）