CSRF保護なしのHTMLログインフォーム
最近、内部アプリケーションの1つにあるHTMLフォームの1つがCSRF保護されていないという脆弱性レポートを入手しました。最初は、ヘッダーとXSRF-TOKENがヘッダーに存在するCookieを確認する開発者ツールを使用して、手動ですぐにそれを再現することはできませんでした。
しかし、その後、シークレットタブまたは「クリーン」ブラウザで問題を再現しました。問題は、最初のログイン試行のみでした。最初のログイン要求がポストされた時点では、クライアントまだXSRFトークンを持っていませんのようです。これは、これがクライアントとサーバー間の最初の対話だからです。
それはまだ脆弱性であり、最初のログイン要求でのみ再現される場合に対処する必要がありますか？この種の問題は一般的にどのように対処されますか？クライアントが事前にXSRFトークンを取得できるように、ログインフォームを送信する前に、何らかのクライアント/サーバーの相互作用が必要になる可能性があります。
これは「ログインCSRF」と呼ばれ、実際に対処する必要がある実際の問題です。
攻撃者はユーザーの資格情報を知らないため、攻撃者が被害者をだまして自分のアカウントにログインさせることはできませんが、攻撃者は被害者をだまして攻撃者のアカウントにログインさせることができます。これは、被害者が自分自身としてサインインしていると信じているときに、被害者をだまして攻撃者に情報を提供しないようにするために使用できます。
これは確かに悪意のある目的に使用されているものです。 From Detectify ：
PaypalはかつてCSRFにログインする脆弱性があり、攻撃者はユーザーに攻撃者のPaypalアカウントにログインさせることができました。ユーザーが後で何かをオンラインで支払ったとき、彼らは無意識のうちに自分のクレジットカードを攻撃者のアカウントに追加しました。
別の、それほど明白ではない例として、Googleにかつて存在していたログインCSRFがあります。これにより、攻撃者はユーザーに攻撃者のアカウントにログインさせ、後でログイン中にユーザーが行ったすべての検索を取得することができました。
これがあなたのサイトで活用されることができる方法を考えることができなくても、巧妙な攻撃者はそうするかもしれません。許可する理由はありません。
それで、どうやってそれをブロックしますか？ユーザーが最初に行うアクションがログインであっても、サーバーとの最初の対話はログインページのフェッチです。これは、CSRFトークンを割り当てる機会です。次に、ログインを含め、サーバーの状態を変更するすべてのリクエストでそれを確認します。
（接線に関連する脆弱性はセッションの修正です。過去のログインを維持するCSRFトークンがあると、その可能性があるため、ソリューションの実装を開始する前にその内容をよく読んでください。）
Anders で説明されているように、ログインフォームにcsrfがないことは重大な脆弱性です。恐らく、多くの攻撃ベクトルがありますが、私の心に浮かぶ別の可能性があります。最悪の場合、被害者の資格情報を盗まれる可能性があります。
攻撃者が自分のアカウントに永続的な自己XSSを持っている場合、ユーザーに自分のアカウントにログインさせるだけでそれをトリガーできるため、ソースページ全体を変更し、サインアップまたはサインインフォームを表示できます。
これは AirBnbのエクスプロイト セルフxssに加えて、ログインフォームにcsrfトークンがないことを利用しています。