スプーフィングフォームの提出を停止

Question

私はスプーフィングされたフォームの提出を止めることについて質問があります。どうすればいいですか？$_SERVER['HTTP_REFERER']私は自分のウェブサイトからのフォームにのみ投稿を許可しますか？それは助けてくれますか？ありがとう！

Answer 1

これは役に立ちますが、追加するのは簡単ですが、HTTP_REFERERヘッダーを偽装することはできません。

クライアントがHTTP_REFERERを送信する必要はありませんので、ヘッダーがない場合は、とにかく送信を許可したい場合があります。これが不可能な場合は、をチェックすることは助けになりません。

CAPTCHA を検索する「完全に自動化された公開チューリングテストを使用して、コンピュータと人間を分かち合う」これはあなたが本当に探しているものです。

Answer 2

停止？制限なし？おそらく。あなたのウェブサイトは、驚くほど多数の偽装されたフォーム提出で本当に打撃を受けていますか、あるいはあなただけが先制攻撃されていますか？そこにない問題は解決しないでください。

Answer 3

偽装フォームの送信を防ぐには、技術的にはは不可能です。 1つの文でそれを要約する：

もしあなたのブラウザがそれを行うことができれば、誰でもそれを行うことができます。

Answer 4

リファラーは簡単に偽装されます。

あなたは愚かなボットをキャッチし、サーバー側のCAPTCHAを使用する可能性が最も高いフォームを検証する必要があります。

Answer 5

Refererは簡単に偽装することができるため、フォーム提出を偽装したい攻撃者はRefererヘッダーを偽装することができます。また、WebブラウザがRefererヘッダーを送信する必要があるとは思わないので、合法的なユーザーからフォーム投稿を除外する可能性があります。

Answer 6

ReCaptchaのようなキャプチャを試してください。あなたはスパムボットがあなたのウェブサイトをスパムするのを防ぐだけでなく、あなたのフォームを使用する人々（少なくともある程度は、あなたがフォームを読み込んでキャプチャを取得し、応答）。

Answer 7

実際には役に立ちません。これを読んでください： http://shiflett.org/articles/form-spoofing

Answer 8

HTTPヘッダーをスプーフィングするのは簡単なので、厳格なセキュリティが必要なものには使用しないでください。一般的に使用される1つの手法は、暗号化されたCookieと一致する暗号化されたトークンの両方を、フォーム上の隠れた入力に送信することです。クッキーはHTTP専用のクッキーでなければなりません。フォームの送信時に、Cookieからの値と非表示入力からの値が一致することを確認します。これにより、サイトへのリクエストがCookie（MIM攻撃の場合）または隠れた入力（スプーフィングされたフォーム）のいずれかが失われるため、別のサイトから正常に作成できないため、クロスサイトリクエストフォージェリーを防止できます。もちろん、これは、あなたのサイトが安全であることを確認して、何を供給するかを見つけるためにトークンを嗅ぐことができないかどうかによって決まります。ここで

は、これはASP.NET MVCで行われている方法についての素敵な議論は、フォームスプーフィングとhttp://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Answer 9

主な問題だあなたは、クライアントが送信するものを制御することはできませんということです。ユーザーは任意のフォームパラメータを変更できます。したがって、クライアントがフォーム提出時に送信するすべてのものを検証し、検証する必要があります。

これは、フォームに送信するために提供するパラメータが少なくなるほど、検証と確認が必要ないことを意味します。特に、予め設定され、ユーザによって変更されないパラメータ（すなわち隠れたフォームフィールド）は、実際には必要でない場合には、フォームに埋め込む必要はない。代わりにcontainer in the sessionにそれらを格納し、隠しフィールドを介してこのコンテナを参照することができます。これがオプションでない場合は、MACでプリセット値を歌い、少なくとも完全性の欠陥を検出できることを確認してください。

もう1つの問題は、フォーム送信に成功するために送信する必要があるフォームパラメータがかなり予測可能であり、攻撃者が繰り返し有効なフォーム送信を繰り返し送信できることです。サーバによってのみ発行可能で、フォーム提出時に検証される予測不可能なパラメータが必要な場合は、フォーム提出が許可されていることを確認することができます。

解決策の1つは、フォームリクエストで生成されたランダムワンタイムトークンを使用し、セッションに格納され、非表示の入力フィールドとしてフォームに格納されることです。次に、フォームの提出時に、トークンが提供されているかどうか、およびトークンがセッションに格納されているものと等しいかどうかを確認します。等しい場合は、セッションからトークンを削除してフォームを処理します。そうしないと、フォーム処理が拒否されます。

あなたはまだフォームを要求してからスプーフィングされたフォームデータを送信できるので、このメカニズムは完璧ではありません。そこでは、Captchaやその他の自動要求を防ぐメカニズムを使用することができます。上記すべての手段の組み合わせを使用することであろう

最良：

• 十分にランダムな識別子を有するセッションにフォームコンテナを作成します。プリセットパラメータは、フォームから除外することができない場合、フォーム送信
• ストアの形容器に代わり形態
• の形態の容器の任意のプリセットのパラメータを識別するために、フォームの隠し入力フィールドとしてその識別子を入れ、その値を認証MAC（形当たりコンテナキーを使用）
• 怪しい繰り返しフォーム要求/フォームの提出がある場合は、さらに自動リクエストさらに

を防ぐためのCaptchaを使って考えると、これらのセッションベースのフォームコンテナもないようにするにはその識別子としてのCSRFは、第三者をタックする。

Answer 10

「なりすまし」の定義がなければ、空の話になります。

さまざまな「詐欺」があり、それぞれに異なる保護があります。

ほとんどの一般的なソリューションはCAPTCHAです。

Answer 11

トークンを使用することをお勧めします。一般的なMVCアーキテクチャを使用している場合、スプーフィング防止のために心配する必要はありません。しかし、自分のようなカスタムMVCアーキテクチャ上にいる場合、トークンがアプローチです。データベースクラスでは、すべてのCRUD（CREATE、READ、UPDATE、およびDELETE）関数に対して、トークンをチェックします。例えば トークンはmd5を介して生成することができる。

public function save(){ 
if(isset($_SESSION['token']){ 
//proceed with saving 
}else{ 
//kill it, 
die; 
} 
} 

また、あなたは簡単にこのクロスサイトリクエストフォージェリの保護キットを使用してWebアプリケーションを統合することができます。here