ほぼすべての Web サイトが CAPTCHA 画像を使用してフォームをスパムから保護しています。しかし、これが最も安全な方法でしょうか? 私が理解している限り、CAPTCHA の考え方は、「認識しにくい」テキストを含む画像でユーザーに挑戦し、訪問者が人間 (ボットではない) である場合に投稿できるようにすることです。機械ではなくデータ。Web サイトは、キャプチャ コード (画像) と、おそらくキャプチャ画像のハッシュ化されたバージョンを含むセッション変数を送信します (正しい答えですが、ハッシュ化されています)。ユーザーがフォームを送信すると、サーバーは、ユーザーが入力した文字のハッシュ = セッション変数に含まれるハッシュであることを確認する必要があります。私 (スパマー) が同じ要求を模倣してサーバーに送信するソフトウェアを作成したらどうなるでしょうか? 言い換えると、キャプチャが abc123 で、ハッシュ (任意の HTTP スニファーで読み取ることができるセッション変数内) が xyz345 (これを 32 文字の文字列と見なす) であり、このデータをポスト リクエストでサーバーに送信したとします。それから私はより創造的になり始めます。このコードを 10,000 ループに入れて、スパム データでサーバーを圧倒します! CAPTCHA はそんなに安全なのですか? 私がそのような脅威に直面できるオプションはありますか? ありがとう
2 に答える
あなたの仮定は間違っています:セッションデータをクライアントが読み取ることも、キャプチャがDOS攻撃を軽減することを意図したものでもありません。
キャプチャは、サーバーがクライアントに、人間だけが解決できるように意図されたチャレンジを発行するチャレンジ/レスポンス技術です。ほとんどのキャプチャが存在する光学式文字認識(OCR)の課題は、1つのバリエーションにすぎませんが、OCRはほとんどの識字者にとっては簡単ですが、コンピューターにとっては問題となるため、確かに優れています。
ただし、チャレンジへの応答が推測、導出、またはその他の方法で簡単に取得できる場合、キャプチャは価値がありません。期待される応答をプレーンまたは非表示のフォームフィールドの派生フォームで送信するのは、そのような例です。応答をパラメータとしてキャプチャ画像に渡すことも別の例です。
そのため、期待される応答は、セッションデータとしてサーバー側にとどまる必要があります。これは、セッションの識別子のみが送信されるため、クライアントが読み取ることはできません。
キャプチャがDOS攻撃を防ぐことができないという2番目の懸念は真実です。繰り返しますが、それはキャプチャが解決することになっていた理由ではありません。キャプチャは、「コンピュータと人間を区別する」ために発明されたものであり、他には何もありません。それらは、自動スパムが成功するのを防ぐのに役立つだけです。しかし率直に言って、激しいチャレンジ/レスポンス生成はDOSにつながる可能性がかなりあります。
キャプチャは、セッションCookieの盗難を防ぐ方法ではありません。安全なセッションが必要な場合は、HTTPSなどを使用してください。
Captchaは(D)DOS攻撃を防ぎません。サーバーを、1秒あたり10.000のスパム要求に対して保存したい場合は、それに対する対策を講じてください。
キャプチャの唯一の目的は、リクエストが人間からのものか機械からのものかを判断することです。これにより、アカウントなどを作成する自動スクリプトが防止されますが、他の方法でキャプチャのセキュリティを含め、Webサイトを保護する必要があります。キャプチャの回答を公開するサーバー、またはユーザーが解決するキャプチャが間違っているかどうかをユーザーに判断させるサーバー。
理想的なキャプチャは、すべての人間を解決するのは簡単ですが、すべてのマシンを解決することは不可能です。したがって、それはユーザーにとっての課題ではありません。残念ながら、マシンはかなり良いので、あなたは挑戦を提起しなければならず、それは私たちにとっても難しいことです。