CSRF防御のユースケース
プライベートIPアドレスを介してHTTPベースのWebUIをサポートする組み込みデバイスがあります。
HTTP（HTTPSではなく）を介してCSRF防御を実装することは理にかなっていますか？
回答
HTTPリクエストが状態を変更できる場合は、CSRF保護が必要になる場合があります。要求がトランスポート層で暗号化されているかどうかは、これとほとんどまたはまったく関係がありません。
CSRF保護がないと、被害者のブラウザが適切に認証されているか、認証が不十分または破損している場合、攻撃者がWebサイトまたは単一のリソースにアクセスするように説得すると、組み込みデバイスにリクエストを送信して制御できる可能性があります。これは、HTTPまたはHTTPSのどちらが使用されているかに関係なく発生します。
はい、理想的にはすべてがHTTPS経由です。ただし、現時点でほとんどのベンダーにとって「最良の」オプションは、自己署名証明書を備えた組み込みデバイスを出荷することです。これは、最初の使用での信頼とパッシブスニッフィングの阻止に適していることを除けば、多くの場合、プレーンHTTPよりもはるかに優れています。シナリオ。多くの場合、ユーザーは引き続き証明書の警告を受け取り、それをクリックします。この問題が解決されるまで、組み込みデバイスのHTTPSの見通しは依然として陰気です。
（削除された編集に対処する）確かに、XSSはCSRFの緩和策をバイパスします。ただし、脅威モデルはここでは少し異なっているように見えます。これは、最初のケースでは攻撃者がデバイスにアクセスする必要があるため、CSRFの問題よりも攻撃者が組み込みデバイスでXSSを悪用できる可能性がはるかに低いためです。
CSRF防御がないと、攻撃者は監視アラートを含む電子メール（おそらく、適切に標的化されたなりすましアドレス）を偽造して、重大な問題があるためにチェックアウトするように指示する可能性があります。電子メール内に、http：// yourswitch / factory_resetへのリンクがある可能性があります。
攻撃ベクトルは異なる場合があります。
そのデバイスにデフォルトのFQDNまたはIPアドレス（たとえば、ユビキタス192.168.1.1）を使用しない限り、この特定の種類の攻撃はかなり標的にされます。攻撃者は、実際に「興味深い」何かを実行するスイッチへの要求を作成し（これには、有用なパスを取得するためにFQDN / IPとベンダー/モデルを知っている必要があります）、あまり発生しない方法でこのリンクを送信する必要があります。あなたの眉毛（インターネットからの電子メールは奇妙だろう。多分あなたが使用する無応答の監視電子メールを偽造する何か？）。
いつものように、それはあなたの脅威モデルとあなたの対抗策の費用対利益を理解することに帰着します。
はい。
ネットワークスイッチまたはルータの場合には、それが受けることができると一般的な攻撃は、これらのアクション等のデバイスの再構成（例えば、外部の内部ポートを転送するように）、それは悪意のあるものに提供するDNSを変更するであろうべき必要認証ですが、変更されていないデフォルトのパスワードも使用している可能性があることを考慮に入れる必要があります。
（そして、はい、この種のことは野生で起こります）
それがプライベートアドレスに基づいているという事実 http://192.168.1.1攻撃は悪意のあるWebページによるものであるため、保護は提供されません。ネットワーク内のユーザーのブラウザーを介して、CSRF保護がないために受け入れられた悪意のある要求がスイッチを誤って構成します。
Mozilla Firefoxのバグ354493は14年間オープンしており、RFC-1918以外からRFC 1918アドレスへの攻撃を回避できますが、これまでのところ実装されていません。