Webサイトのすべてのページに表示されるお問い合わせフォームをどのように保護する必要がありますか？
クライアントのウェブサイトのすべてのページに小さな「お問い合わせ」フォームがあります。これらのフォームにCAPTCHA検証を含めないことで使いやすいようにすることを強く求めていますが、ブルートフォース攻撃などに対して何らかのセキュリティを実装するのは私の責任だと感じています。フォームのUIの変更。
ちなみに、クライアントにはサーバーサイドスクリプト言語としてColdFusion 8があり、現在データベースにデータを挿入するために使用されています。ただし、ソリューションはColdFusionに固有である必要はありません。私はここでアイデアを探しています-必ずしもコードスニペットではありません。
これはCATPCHAに関する良い要約記事です：
http://www.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captcha/
CAPTCHAは使用しない方がいいと思います。調査によると CAPTCHAはコンバージョン率を3％、場合によっては最大30％低下させる可能性があります 。 mechanical turk 、 yourmaninindia.com などを使用して手動でフィルタリングまたは使用する場合でも、カスタマーエクスペリエンスにとっては安くて良いかもしれません
良い受動的対策：
Robooスクリプト 。今年Blackhatでデモを行い、DOS保護も提供しています。
決して完了してはならないハニーポットの非表示フィールドを追加します。 Javascriptを使用して、正当なフォーム送信時にこれを自動的に入力し、サーバー側を検証できます。
フォームの送信速度などの速度測定。
これらはすべて完璧ではなく、障害者に問題を引き起こし、誤検知を引き起こす可能性があります。それでも許容できない量のスパムまたはロボットの使用を取得している場合は、最も人気のある無料のオプションであるRe-Captchaを使用してください。理想的には、これを上記のパッシブな手順と組み合わせて、ボットの送信が疑われる場合にのみCAPTCHAを提示します（つまり、ユーザーに毎回提示されるわけではない適応的アプローチ）。はいRe-Captchaは研究室で壊れており、OCRテクニックを使用して 25％ と同じくらいの成功を収めていますが、保護されていないターゲットを探しているドラッグネットボットを阻止するには十分です（クマから走っている人よりも速く走っています） 。また、あなたはグーグルが世界の本を翻訳するのを手伝っており、duolingo.comが悪いことではない次の革新を思い付くまで。
NoBotはMicrosoftの 興味深い無料ソリューション です
説明
NoBotは、ユーザーの操作を必要とせずに、CAPTCHAのようなボット/スパムを防止しようとするコントロールです。このアプローチは、実際の人間の介入が必要な実装よりも簡単に回避できますが、NoBotには完全に見えないという利点があります。 NoBotはおそらく、ブログやコメントのスパムが問題であり、100％の有効性が要求されない低トラフィックのサイトに最も関連しています。
NoBotは、いくつかの異なるボット対策技術を採用しています。クライアントのブラウザーに構成可能なJavaScript計算を実行させ、ポストバックの一部として結果を検証します。 （例：計算は単純な数値の場合もあれば、ブラウザーが関与していることを保証するためにDOMが含まれる場合もあります）フォームが要求されてからポストバックできるまでの間に構成可能な遅延を適用します。 （例：人間がフォームを2秒未満で完了することはほとんどありません）構成可能な制限を、IPアドレスごとの単位時間あたりの許容可能な要求の数に適用します。 （例：人間が1分間に5回以上同じフォームを送信することはほとんどありません）
NoBotは、上記の手法に違反することでテストできます：すばやくポストバックする、何度もポストバックする、またはブラウザーでJavaScriptを無効にする。
CAPTCHAに煩わされないでください、それはほとんど価値のないことです。
代わりに、合理的なレートスロットリングメカニズムを実装します。つまり、特定の時間内に単一のIPアドレスから到着できる「お問い合わせ」リクエストの数を制限し、「数値」と「時間」の適切な値を求めます」例えば。それが理にかなっている場合、1分あたり10件以下の連絡要求、またはそれが理にかなっている場合、1時間に5件。
もちろん、IPアドレスは必ずしも1対1でユーザーにマップされない（DHCP、動的IP（例：ダイヤルアップ、企業プロキシなど））ので、あまり厳しく制限することはできません。部屋を少し揺らしますが、一方で、毎分2000リクエストは多すぎます。
リセットは簡単なので、セッションごとにスロットルを実装することはできません。
また、すべてのアドレスに対して、はるかに高いレートでグローバルスロットルを実装することも検討してください。これにより、何らかの形のDoSが発生する可能性がありますが、お問い合わせフォームを使用できるかどうかは重要ではないと思います。
OWASPには、自動化対策のためのリソースがいくつかあると思います。
特定のシナリオでは、すべてのHTMLリンク（連絡先フォームのHTMLフォーム送信基準など）である種のトークンを使用し、動的ページにコードを記述して、後で確認できるようにリファラーヘッダーを追加することをお勧めします。前のトークンと一致するリファラーヘッダーの存在。
ただし、そのようにすると、多くの問題が発生する可能性があります。たとえば、HTTPヘッダーインジェクションが発生する可能性があります。もちろん、インジェクションの欠陥、クロスサイトスクリプティング、パスリークなど、すべての動的ページにある問題がありますが、同時実行の問題、例外処理の問題なども追加されます。