私は開発者でしたが、今は開発者の視点からXSSを検討しています。反映されたXSSの特定のケースを考えていました。脆弱なWebサイトがあり、攻撃者がユーザーをだまして悪意のあるリンクをクリックさせることができる場合、document.cookie
を使用してセッショントークンを取得できるとしましょう。
Webサイトがhttp-only
Cookieの使用を開始した場合(JavaScriptを使用してセッショントークンにアクセスできなくなると思います。ポイントを逃していませんか?)まだスクリプトインジェクションに対して脆弱ですそのような場合、攻撃者に残されたオプションは何ですか?この脆弱性を利用する他の方法は何ですか?
HTTPOnly
Cookieを使用するアプリケーションに影響を与えるXSSの脆弱性で武装した攻撃者が探索できる2つの主要な攻撃パターンがあります。
何よりもまず、攻撃者は悪用方法 Sammyワームと同様 を使用できます。この攻撃パターンでは、XSSペイロードはXMLHttpRequest
を使用してCSRFトークンを読み取り、被害者のいる場所のようにアクションを実行します。一般的なアクションは、新しい管理ユーザーの追加、パスワード(またはパスワードリセットを実行するための電子メールアドレス)の変更、さらには資金の送金です。認証されたセッションで実行できるアクションはすべて、CSRFトークンを読み取ることでJavaScriptで実行できるはずです。
2番目の攻撃は、信頼されたドメインを利用することです。ターゲットがhttps://sometrustedbank.com
であるとしましょう。そのHTTPSは情報を得たユーザーにはかなり光沢があるように見えますが、攻撃者はdocument.body.innerHTML
を任意の値に割り当てることにより、このページのコンテンツを変更できます。攻撃者は非常に説得力のあるフィッシング攻撃を行う可能性があり、無力な被害者がhttps://sometrustedbank.com
に誘導され、個人情報(および深い暗い秘密)を漏らすよう求められます。この場合、コンテンツは王様であり、ユーザーはこのコンテンツが攻撃者からのものであることを認識していません。
要するに; HTTPOnly
Cookieを有効にしますが、このセキュリティ機能がXSSを停止するためにインデントされたことはありません。