私は個人のphpフレームワークにスパム保護を追加しており、ハニーポットはスパムをブロックする優れた方法だと思います。残念ながら、それらは昨日発明されたものではなく、おそらくほとんどのボットはCSSをフェッチし、フィールドが実際のものかどうかを把握できます。たとえば、スパムボットを設計している場合、スタイル属性にdisplay: none
が含まれるフィールドや、width:0; height:0; border:none; background:none; position:absolute; cursor:defualt
などの比較的大きなスタイル属性が含まれるフィールドをボットに欠落させることは、非常に直感的です。私が現在使用している方法。さらに、他のすべてのフィールドにスタイル属性がない場合は、ハニーポットだけではない可能性が高くなります。
つまり、ハニーポットを見つけるのはそれほど難しいことではないように思えます。ハニーポットを隠すための最良の方法はどれですか。
そして私が言ったように、これはフレームワークの一部として構築しているため、JavaScriptは実際にはオプションではありません。
最後に、スパムタグはないので、これにセキュリティのタグを付けます。
Webフレームワークを構築している場合、これは、HTML、CSS、JSファイルなどのリソースを提供できることを意味します。必要な場合は、すべてのリソースをHTMLにインライン化することもできます。したがって、CSSおよびJavaScriptベースの手法を使用して、フォームをスパムすることを恣意的に困難にすることができます。
各フォームフィールドに、異なるclass
を適用できます。これらの1つだけがハニーポットの指定に使用され、CSSを使用してその入力を非表示にすることができます。これには、スパムボットに完全なCSSパーサーを含め、特定の入力が表示されるかどうかを確認する必要があります。これはかなり重要です。インラインスタイル属性を使用しても、/\bdisplay:\s*none\b/
などの正規表現を使用して属性を検出できるため、同様の保護は提供されません。このようなCSSの使用は、20%の努力、80%の成功ソリューションであり、実際に行う価値があります。
この保護は簡単に改善できます。 JavaScript経由で必要なクラスを適用する。ボットはJavaScriptインタープリターを実行する必要がありますが、CSSルールを解決するよりもはるかに簡単です。 CSSルールを難読化して、ボットがCSSを完全に実装することを要求できます。 .the-next-one-is-spam + .field { display: none }
などのルールについて考えてください。ページの読み込みごとにクラス識別子を自動生成できるため、ボットにとってサイトの特別なルールをハードコーディングしても意味がありません。または、独自のソリューションを一緒に投入するのをやめて、既存のキャプチャプロバイダーを使用することもできます。
ハニーポットの問題は、一方では実際の入力フィールドと区別できない必要があることです。一方、テキストベースのブラウザを使用しているユーザーや、支援技術に依存しているユーザーがいるかもしれません。他のユーザーは自分のスタイルシートを代用するかもしれません。 JSとCSSを有効にすることをすべてのユーザーに依存することはできません。それにもかかわらず、サイトが引き続き使用可能であればいいです。管轄区域およびプロジェクトのタイプによっては、支援技術のユーザーをサポートすることが法的に要求される場合があります。
また、ハニーポットは、実際のブラウザを使用する人間のスパマーに対する保護を提供しません。ハニーポットは防御の1つの層になり得ますが、それだけでは完全な保護を提供できません。それらは、90年代のスクリプトキディによるセキュリティの理解で書かれた安全でないコメントフォームのうろついている低努力ボットの群れを取り除くのにのみ役立ちます。