2012-03-05 11 views
1

可能性の重複:私は今日、これらのフォーラムを見ましたが、私は私の質問に十分良い答えを見つけることができませんでした
How to know where a form came from?PHPフォームのリファラセキュリティ

が私のドメインからと表示されていない限り、フォームがサーバーに送信されないようにするにはどうすればよいですか。誰かが自分のフォームのHTMLを直接コピーして自分のプラットフォームに貼り付けると、フォームからのデータが自分のファイルを解析し、フォームが自分のサイトで行うように設定されていることを認識しました。

これを防ぐにはどうすればよいですか?私はリファラーが私のドメインから来たものかどうかを調べることを考えていましたが、これを研究したものから、これが起こるのを防ぐことはできませんでした。では、どうしたらこのことをやめることができますか?

+2

「フォームのHTMLを直接コピーして自分のプラットフォームに貼り付けると、フォームからのデータがファイルを解析し、フォームが自分のサイトで行うように設定されていることに気付きました。なぜこれが問題であるか(または問題となりうるか)明確にするあなたは本当にそれを防ぐことができません –

+1

あなたのサイトは '$ _SESSION'に格納されたランダムな値を生成することができます。これは隠された入力フィールドにフォームによって提出する必要があります。ハードル。あなたは本当にユーザー認証なしでこれを防ぐことはできません。 –

+0

すべての正直なところ、彼らはフォームのhtmlをコピーする必要はなく、投稿要求で十分です。それでも問題はどうですか? –

答えて

3

REFERERは簡単に偽装されますが、防御の主要な障壁としてそれほど悪くないので、簡単にチェックすることができます。より洗練された防止のためには、問題のフォームを含むページがロードされたときにトークンを生成し、それをユーザーセッションに格納し、フォームの隠しフィールドに保存し、フォームが送信されるときにセッションに対してチェックします値。誰かが望むのであれば回避することもできますが、HTTPSが最後の手段になる特定のケースに応じて異なります。

0

あなたはリファラーに頼ることはできません!無効にすることができます。

しかし、tokenは、a)隠し入力フィールドに、b)をユーザーのセッションに書き込むことができます。 あなたのターゲットスクリプトでは、それらが同等かどうかをチェックするだけです!

3

防御しようとしている攻撃には2種類あります。

サードパーティのトリック

サイト上のアクションを実行にユーザー

アリスは、例えば(その後、ボブのウェブサイトにログインする攻撃者のWebサイトを訪問し、攻撃者のWebサイトを作るためにアリスのブラウザの原因となる場所ですボブのサイトに「送金」リクエストを送信する。

これはCSRF attackであり、標準defenceは、隠しフィールドに、ユーザーのセッションにも存在するトークンを含めることです。

攻撃者はトークンを自分のフォームに入れることはできません。したがって、トークンが一致すると、フォームがサイト上にあることがわかります。

は、ユーザーは、彼らが本当に例えば

、アリスが編集要求を提出する前に、コメントのpost_idのを変更してはならないいくつかのデータを提出する形式でデータを変更するので、他の誰かの記事を編集、またはおそらく彼女は注文された商品の価格を変更するでしょう。

の入力はとなります。編集依頼が来たら、ログインしたユーザーに投稿の編集権限があることを確認します。注文が入った場合は、アイテムIDと数量にのみ注意してください。データベースから価格を取得できます。等

0

あなたのアプリケーションにPOSTが来たときに、サーバーのフォームから来たもので、どこか別のものではないことを確認しようとしています。これは、クロスサイトリクエスト偽造(CSRF)攻撃として知られています。

参照元を確認することに問題があります。まず第一に、HTTP仕様では、(さまざまなプライバシーの理由から)クライアントが参照文字列を送信しないようにすることができます。だから、あなたのクライアントの中にはそれを含んでいないものもあります。第2に、リフェラル文字列を偽装することができます。十分なスキルの攻撃者は、CSRFの攻撃を成功させるためには、必要なもののように見せることができます。

CSRF検証トークンを使用する方が強固なアプローチであり、CSRF攻撃に対する軽減方法として推奨されます。なぜこれがOWASP CSRF Cheat Sheetにあるのかについて読むことができます。

私は、両方を行うことができない理由はないことを指摘します。ディフェンス・イン・デプス(DiD)戦略は、攻撃者が攻撃を成功させるために複数の独立した防御を打ち負かす必要があるため、通常望ましいものです。ウィーク・リファラーチェック・アプローチを実装することができます(クライアントがリファラーを提供している場合は、リクエストに応じる前にリファラーが存在することを確認してください;リファラーが存在しない場合は、 CSRF検証トークンと一緒に使用します。このようにして、クライアントがそれを提供している場合には、より強力な検証トークン手法を使用しながら、参照された情報をチェックします。