クロスサイトスクリプティング（XSS）攻撃が Web サイトに与える被害と対策
ジェフリー・エドワーズ
|サイバー犯罪 | 2022年12月02日
サイバー攻撃というと、大企業や国家の IT システムやネットワークインフラに対する複雑で組織的なハッキングをイメージすることが多いかもしれません。ハリウッド映画で観たような、フーディーを着たハッカーが、大物のターゲットを狙って、ネットワークインフラや IT システムに高度な攻撃を行う様子を思い浮かべる方も多いかもしれません。
もちろん、そのような攻撃は現実世界でも起きてはいますが、実際のところ、ハッカーも他の犯罪者と同様、簡単な標的に狙いを定めることが多いです。そして、最もターゲットにされやすいのは、セキュリティの脆弱な顧客向け Web サイトであり、ハッカーはそのようなサイトを攻撃することで、大量の消費者データを盗み出すことができます。
クロスサイトスクリプティング（XSS）攻撃とは、Web サイトの攻撃に多用される攻撃手法のひとつで、信頼されている Web サイトに悪意のあるスクリプトを注入することで、カスタマージャーニーに影響を与えたり、データを盗み出したりします。
この記事では、XSS 攻撃とは何か、攻撃の仕組みや、ビジネスに与える被害、そして Web サイトを XSS 攻撃から守るための対策について紹介します。
XSS 攻撃とは
クロスサイトスクリプティング（XSS）攻撃は、最も有名で広く使われている Web アプリケーション攻撃のひとつですが、誤解を招きやすい名称かもしれません。この名称は攻撃者がクロスサイト（サイト横断）データを盗むことに重点を置いていた初期の攻撃手法に由来していますが、現在の「XSS」は、実際にはインジェクション（注入）攻撃の一種であると言えます。現在の XSS において、攻撃者はユーザーの行動の監視、クッキーへのアクセス、偽物のまたは外部のコンテンツのダウンロード、機密情報の窃取を行うために、悪意のあるスクリプト（多くの場合は JavaScript）を信頼されている正規の Web サイトやアプリケーションに注入し、悪意のあるコードをユーザーのブラウザ上で実行しようとします。
XSS 攻撃の仕組み
XSS には、２つの段階があります。まず、攻撃者は、Web サイトやアプリケーションに悪意のあるコードを注入する方法を見つけなければなりません。これは通常、JavaScript で行われますが、HTML やその他のマークアップ言語が使用されることもあります。
>> 無料診断で、ファネルに侵入しているボットの数を確認しましょう。
このステップを可能にするためには、対象となる Web サイトは、ユーザーの入力を検証したりエンコードしたりすることなく、ページに直接含まなければなりません。例えば、ユーザーはテキストのみを入力するという前提の元、コメントがページのソースコードに直接組み込まれるようになっていると、攻撃者は Javascript や HTML を含むコメントを注入することで、Web サイトを改ざんすることができます。
攻撃の第二段階として、XSSは、一部のブラウザがこの悪意のあるスクリプトと正当なマークアップを区別できないことを利用し、攻撃者の悪意のあるスクリプトが実行されます。これにより、ローカルストレージの読み取りや、クッキーへのアクセスなどの個人情報窃取、フィッシング、マルウェアの配布など、さまざまな攻撃が可能になってしまいます。
XSS 攻撃がビジネスにとって危険な理由
XSS 攻撃は、その発生以来、OWASP（The Open Web Application Security Project）の Web アプリケーションセキュリティリスクのトップ10に入り続けているほど一般的なものですが、昔ながらの脅威として過小評価してはいけません。
一般的な XSS 攻撃では、攻撃者はセッションクッキーを窃むするだけかもしれませんが、これは個人情報の窃取であり、EU の GDPR やカリフォルニア州の CCPA などのプライバシー法に大きく違反することに変わりはありません。そして、この違法行為が Web サイト上で行われた場合、サイト運営会社の責任が問われてしまいます。
また、医療記録や銀行取引などの機密データが窃取された場合、被害はさらに深刻になる可能性があります。
例えば、オンラインでスキミングを行う「Magecart」のハッカーは、XSS を利用して、コンピュータのハードウェアや電子機器の EC サイトである Newegg に侵入し、注文を完了する際に「secure.newegg.com」でホストされているページに悪質な JavaScript を注入することで、顧客の支払いデータを盗み出していました。盗み出された情報は、ハッカーが所有する「neweggstats.com」というドメインに送信されていました。この攻撃は、1カ月以上の間、秘密裏に行われ、合計数千人もの顧客データが盗難されました。
この種の攻撃は、規制当局による罰則や法的措置といった脅威をもたらすだけでなく、顧客からの信頼を大きく低下させる可能性があります。調査によると、87%の消費者が、データ流出があった企業とは当面の間取引を控えると回答しています。
XSS 攻撃の種類
XSS 攻撃には、Stored XSS（格納型/蓄積型/持続型 XSS）と Reflect XSS（反射型 XSS）の２種類があり、さらに DOM-based XSS（DOM ベース XSS）というあまり一般的ではない第３の攻撃もあります。
Stored XSS（格納型/蓄積型/持続型 XSS）
Stored XSS は、Persistent XSS（持続型 XSS）とも言われ、攻撃者が悪意のあるスクリプトやペイロードをあらかじめ Web アプリケーションや Web サイトに格納しておきます。こうしたスクリプトはサーバーに保存され、該当するページをユーザーが閲覧するたび、不正スクリプトが実行されます。
Stored XSS は、攻撃者が一度アクションを起こすと攻撃が継続されるため、最も一般的な XSS の形式となっています。
Blind XSS（ブラインド XSS）は、Stored XSS の一種で、攻撃者が入力した情報が Web サーバー上で保存され、アプリケーションのバックエンドや他のアプリケーションなど、別の場所で実行される場合に発生します。 例えば、攻撃者がフィードバックフォームに悪意のあるコードを注入した場合、アプリケーションの管理者がそのフォームを開くことにより、スクリプトが実行されます。
Reflected XSS（反射型 XSS）
Reflected XSS は、ペイロードが Web アプリケーションからユーザーのブラウザに返送されるときに発生します。通常、Reflected XSS は、Web サイトのコメント欄などに埋め込まれた悪意のあるリンクを通じて、ユーザーを脆弱性のある Web サイトへ誘導し、攻撃を開始します。Reflected XSS では、攻撃者は XSS の脆弱性を持つ Web サイトを探す必要はありませんが、ユーザーがリンクをクリックしない限り機能しないため、Stored XSS よりも成功率が低くなります。
DOM-based XSS（DOM ベース XSS）
DOM-based XSS はクライアントサイド XSS とも言われ、攻撃者が被害者のブラウザの DOM 環境を改変してペイロードを実行する XSS 攻撃です。
XSS の脆弱性への対策
XSS の脆弱性は、最も一般的な Web アプリケーションの脆弱性のひとつですが、比較的容易に発見することが可能であり、単純な攻撃へは業界標準の対策が効果的です。
コードレビューとペンテスト
Web アプリケーションや Web サイトを構築する際には、コードレビューが不可欠です。セキュリティの脆弱性を特定するためにはソースコードを検査し、さらなる問題を発見するためにペネとレーションテスト（ペンテスト）を実施する必要があります。
特に、ユーザが入力した情報を出力するコードは、適切な出力処理がされていることを確認する必要があります。ユーザーにより入力されたデータが含まれる HTML は、URLと同様にエンコードする必要があります。
コードレビューの参考資料としては、OWASP（The Open Web Application Security Project）によるコードレビューのための詳細ガイド(PDF ファイル)に、XSS 攻撃に関する記載が含まれています。
ユーザーが入力したデータのフィルタリング
XSS 攻撃の可能性を減らすためには、ユーザーが入力したすべてのデータをフィルタリングして、<script>、<body>、<html>などの危険なタグや属性を削除することが有効です。しかし、XSS 攻撃に対する唯一の防御方法としてフィルタリングに頼ることはお勧めしません。高度な攻撃者は、16進エンコーディングやユニコード文字のバリエーションなどの技術を利用して、フィルタリングを回避することができるからです。
エスケープ処理の使用
XSS の脆弱性を軽減するためのもう一つの一般的なテクニックは、エスケープ処理を導入することです。これにより、攻撃者がページにスクリプトを埋め込むことができても、悪意のあるコードを実行することができなくなります。エスケープ技術は、HTML、JavaScript、CSS などの言語によって異なるため、サイト上に存在する言語ごとに実装する必要があります。
エスケープ処理のためのコードを書くことは、時間のかかる冗長なプロセスですので、OWASP ESAPI や Microsoft AntiXSS のような既存のライブラリを活用することをおすすめします。
無害なコードの注入
XSS の脆弱性が疑われる場合、無害なスクリプトを手動で注入し、ブラウザがそれを実行するかどうかを確認することができます。alert() 関数などを利用するとよいでしょう。
コンテンツセキュリティポリシーの利用
コンテンツセキュリティポリシー（CSP）も、XSS 攻撃を軽減するために役立ちます。CSP は HTTP レスポンスヘッダで、リクエスト元に基づいてページへの読み込みを許可するものを制御することができます。
CSP は、インラインスクリプト、リモートスクリプト、安全でない JavaScript、およびフォーム送信を制限することができます。しかし、CSP は XSS 攻撃に対する唯一の防御手段として適切ではなく、また、安全な開発の代替手段にもなりません。Web アプリケーションがユーザーが入力したデータを適切に処理できていない場合、悪意のあるデータが逃げ出し、既存のスクリプトに独自のコードを注入する可能性があります。アカウントフレームワークの Angular や AngularJS もまた、課題を生じさせる場合があります。また、すべてのブラウザが CSP をサポートしているわけではありません。
XSS 攻撃から身を守るための Go-To-Market セキュリティ
XSS 攻撃に対する特効薬はなく、多面的な解決策を必要とする、現在進行形の課題です。上記のソリューションは、企業が XSS 攻撃から自社のアセットを保護するために有効ですが、必ずしも成功を保証するものではありません。
OWASP（The Open Web Application Security Project）とは、Webアプリケーションを取り巻く課題の解決を目指すオープンなコミュニティです。深層防護（Defense in depth）姿勢を推奨しています。これは多層防護とも言われ、セキュリティ保護とリスク軽減のため、入口対策から内部対策、出口対策を複数行い、冗長な層になっていることを意味します。
XSS 攻撃を防ぐには、Web サイト上で実行されているすべてのコード、特にサードパーティのコードに注意することが不可欠です。定期的にセキュリティ評価を行い、システムにはパッチを適用することで、脆弱性に対処する必要があります。また、未承認のソースからのスクリプトをブロックし、新しいスクリプトをリアルタイムで監査し、インジェクションを利用した攻撃をブロックできるように、クライアントサイドの保護も検討する必要があります。
元の記事：How XSS Attacks Threaten Your Website and How to Stop Them
筆者
ジェフリー・エドワーズ
コンテンツマーケティング マネージャー
CHEQ 常駐のコンテンツマーケティングの専門家です。数年間のジャーナリストとしての勤務経験を糧に、サイバーセキュリティにおける難解なトピックを丁寧に親しみやすく伝えることを心がけています。
