web-dev-qa-db-ja.com

Google Recaptcha応答のホスト名を検証する必要があるのはなぜですか？

GoogleのRecaptchaには、hostnameの検証が組み込まれています。ユーザーがRecpatcha応答を送信すると、応答の取得元のドメインが、Recaptchaのセットアップ時に指定したドメインのホワイトリストに対して検証されます。

ただし、複数のドメインでRecaptchaを使用している場合は、Googleのデフォルトのhostname検証を無効にして自分で処理するオプションがあります（ https://developers.google.com/recaptcha/docs/domain_validation ）。

Googleはこれに、特定の応答に対してhostnameを検証しないとセキュリティ上の脆弱性が生じることを示す目立つ警告を伴います。しかし、hostnameのなりすましがいかに簡単かを考えると、これがeverによってセキュリティの強化がどのように行われたかはわかりません。

簡単なテストで、Recaptcha応答のOriginを検証するためにGoogleが使用するhostname値を偽装するのがいかに簡単かがわかりました。

$ Sudo nano /etc/hosts
127.0.0.1    spoofedhostname.com

そして、テストRecaptcha応答を送信したとき、返された結果は次のとおりです。

{
    "success": true,
    "challenge_ts": "2016-12-24T14:15:22Z",
    "hostname": "spoofedhostname.com"
}

では、なぜホスト名の検証がまったく面倒なのでしょうか？

  1. ホスト名検証は、なりすましがいかに簡単であるかを考えると、役に立たないことが広く知られています。
  2. これは、攻撃者がRecaptcha公開鍵を盗み、有効なRecaptcha応答の束を生成することを防ぎ、機密のエンドポイント（/login、/reset-password）。理論的には、これはある種のブルートフォース攻撃で使用される可能性がありますが、応答トークンが1分後に期限切れになることを考えると、意味がありません。また、すべてのRecaptchaを手動で解決する必要がありますが、これは実際のドメインで簡単に実行できます。そして、繰り返しますが、たとえarehostname検証を行っていても、ドメインを簡単に偽装する可能性があります。

それは私には意味がありませんが、それがGoogle製品であることを考えると、セキュリティエンジニアは私が知らないことを知っていると考えなければなりません。

何が欠けていますか？

validation
10
AJB

設定したサイトにyour captchasを埋め込み、解決されたcaptchasを使用してサイトをスパムする人々と何らかの関係がある可能性があります。

たとえば、サイトをセットアップして無料で何か（海賊版の映画/ソフトウェア、ポルノなど）を提供するが、キャプチャを要求する。内部的にはこれは実際にはyour captchaであり、解決されたcaptchaはすべて、サイトをターゲットとするスパムボットに渡されます。これにより、攻撃者は、従来のキャプチャファームと比較して、人間のキャプチャ解決へのコスト効率の高いアクセスが可能になります。

ホスト名の検証により、キャプチャのJSが不正なサイトに読み込まれるのを防ぐことができます。

更新：最近、ヘッドレスブラウザーで元のサイトにキャプチャをレンダリングし、Websocketマジックを使用して「ベイト」サイトにストリーミングすることにより、これをバイパスするデモを実装しました（この場合、要求する単純なURL短縮ターゲットサイトにリダイレクトする前のキャプチャ）。これには、餌サイトに直接キャプチャをレンダリングする場合と比べて、かなりの量のRAM（各Firefoxインスタンスは約500MBでした）が必要でした。そのため、このホスト名検証機能はスパマーにとって大きな問題です。

11
André Borie

キーは2つあります。サイトキーとシークレットキー。これらは両方とも、reCAPTCHAを設定するときにWeb管理者に提供されます。

クライアント側統合の場合、それらはapi.jsとスニペット、およびWebサイトに挿入するサイトキーを提供します。

「ユーザーがreCAPTCHAを統合したフォームを送信すると、ペイロードの一部として「g-recaptcha-response」という名前の文字列が取得されます。Googleがそのユーザーを確認したかどうかを確認するには、GETリクエストをこれらのパラメータ： "<-したがって、URLを偽装している場合、サーバーはg-recaptcha-responseを取得することはありません。シークレットは送信されず、「g-recaptcha-response」の値は送信されず、リモートIPは送信されません。

ハッカーがWebサーバーから秘密鍵を取得する方法がありません。これは、Googleに直接送信されるだけです。

------私が見ているものの追加説明。

サイトキーは、サイトのHTMLコードで簡単に確認できます。ただし、サーバーに保存されている秘密鍵にはアクセスしたり、なりすましたりすることはできません。ハッカーがGoogleとの双方向認証を完了するために秘密鍵にアクセスする方法を知りません。

これはあなたが見逃していることだと思います。 （双方向認証）

参考文献： https://www.youtube.com/watch?v=Fvt1S0nBmwQ （google reCAPTCHAの設定に関するビデオ。

https://developers.google.com/recaptcha/docs/verify

また、GoogleのreCAPTCHAの悪用には、ウェブサイトに他の誰かのreCAPTCHAを埋め込んで、ページのどこかをクリックしたときに自動的に認証されるという非常に興味深い問題があります。

（評判は2つ以上のリンクを投稿するために低いです）

2
WorWin