サーバーの設定により、recaptchaの秘密鍵は公開されていました。
キーは新しいキーに更新されましたが、悪意のあるユーザーがキーを手に入れることによる実際の影響は何ですか?
Documentation 影響について明確ではない
秘密鍵は、アプリケーションのバックエンドとreCAPTCHAサーバー間の通信を承認して、ユーザーの応答を確認します。秘密鍵は、セキュリティのために安全に保管する必要があります。
私が推測したはずの答えではありませんが、
漏洩した秘密鍵については大胆な声明のように見えますが、この1つのケースでは、秘密鍵を漏洩しないことに関する警告は、実際の懸念よりもベストプラクティスに関するものだと思います。それはかなり変わった答えなので、私は通常懸念されることを分析し、それらがここでは適用できない理由を説明したいと思います。
1。キャプチャ検証の回避
これは明らかに主要な懸念事項です-漏洩したキャプチャ秘密鍵が攻撃者にキャプチャ保護の回避を許可する場合、深刻な問題が発生します。ただし、recaptchaフローの仕組みにより、これは不可能です。最も重要なことは、検証はユーザーの応答を(秘密鍵を使用して)google APIに送信し、確認を確認することによって行われます。さらに、リプレイ攻撃を防ぐために、応答は特に1度しか確認できません。これは単に、攻撃者が秘密鍵を使用して自分自身を真ん中に置き、確認を偽造する余地を残さないだけです。それは本当にそれと同じくらい簡単です。
2。広範なアクセス資格情報
多くの場合、単一のキーを使用して複数のサービスの認証を行うことができます。 reaptchaだけでなく、Googleクラウドシステムの他の管理タスクにも使用される秘密鍵を想像できます。このような鍵を漏らすことは、ほぼ無限の影響を与える可能性があるため、非常に危険です。
結局のところ、recaptchaのキーは、recaptchaシステムでの使用のみに制限されているようです。どうやら、これは他のGoogleサービスから少し分離されており、recaptcha以外に使用されるキーを作成することはできないようです。
。有料サービスの利用
使用量に基づいてサービスの料金を支払う場合、シークレットキーへのアクセス権を取得すると、効果的に誰かがサービスを使用して料金を支払うことができます(ただし、この場合、寛容に構成された公開キーも必要になります)。もちろん、このサービスは無料ですので、それは誰の助けにもなりません。
4。レート制限によるDoS
私はそうは思いませんが、これは懸念されるかもしれません。多くの無料のgoogleサービスには、過度の使用を防ぐため、または使用レベルに応じて有料階層に移動するためのレート制限があります。検証エンドポイントのレートが制限されている場合、秘密キーを持つ攻撃者がエンドポイントにスパムを送信してキーを効果的にDoSし、サービスがキャプチャを検証できない可能性があります。これが与える影響は、サービスが拒否された検証試行をどのように処理するかによって異なります。
ただし、ドキュメントにレート制限についての言及はありません。これは必ずしも制限がないことを意味するわけではありませんが、制限がない場合、この攻撃は絶対に不可能です。
概要
何かを見逃した可能性もありますが、recaptcha秘密鍵の場合、リークによる実際の影響はないと考えています。私はまだ提案に従い、それを秘密にしておきます。ベストプラクティスを実践することが常に最善です。
キーの目的は、Googleのバックエンドに対してreCAPTCHAインスタンスを識別/認証することです。理論的には、キーは他のGoogleアカウントへのアクセス権を持つべきではありません。
キャプチャで起こり得る最悪の事態は何ですか?保護がバイパスされ、攻撃者がサービスをスパムしたり悪用したりする可能性があります。現在、この方法でreCAPTCHAをHijackすることが実際に可能かどうか、または追加の保護が実施されているかどうかはわかりません。
この影響は、攻撃者が悪用できるサービスによって異なります。