HTML入力のブロック、データのサニタイジング、Cookieの保護、Webアプリファイアウォール（WAF）の展開によって、悪意のあるスクリプトの実行やユーザー情報の窃取を防止します。
この記事を読み終えると、以下のことができるようになります。
記事のリンクをコピーする
Cross-site scripting（XSS）は、攻撃者が1つまたは複数のWebスクリプトを介して悪意のあるコードを正当なWebサイトまたはWebアプリに挿入する戦術です。ユーザーがWebサイトを読み込んだり、Webアプリを実行したりすると、これらのスクリプトがユーザーのブラウザ内で実行されます。
スクリプトは、ユーザーのHTTP Cookie、セッショントークン、その他の機密情報を盗むなど、さまざまな悪意のあるアクションを実行する可能性があります。攻撃者はこの情報を使ってユーザーになりすまし、ソーシャルメディアプラットフォームや銀行Webサイトなどのさまざまなプラットフォームのアカウントに不正アクセスする可能性があります。さらに、スクリプトによりWebサイトを改ざんしたり、ユーザーを悪意のあるサイトに誘導したり、Webアプリから機密データを抽出したりする可能性もあります。
詳しくは、「Cross-site scriptingとは？」をご覧ください。
XSS攻撃には、反射型（非永続的）XSSと保存型（永続的）XSSという2つの特徴的なタイプがあります。
反射型XSS攻撃は、正規のWebサイトがユーザー入力の検証またはサニタイズを失敗した場合に発生する可能性があります。この攻撃は、多くの場合、ソーシャルエンジニアリングから始まります。ソーシャルエンジニアリングでは、攻撃者はフィッシングメールを送信したり、オンラインフォーラムの投稿にメッセージを残したり、ユーザーがクリックしようと思うように仕向けたりします。通常、リンクには悪意のあるコードが追加された正規WebサイトのURLが含まれています。
ユーザーがリンクをクリックすると、ブラウザは正規のWebサイトにリクエストを送信します。正規のWebサイトは、挿入されたコードをユーザーのブラウザに反射します。Webサイトは入力を適切にサニタイズしないため、悪意のあるスクリプトがユーザーのブラウザで実行されます。
コードはユーザーのCookieをコピーし、攻撃者に送信する可能性があります。攻撃者がセッションCookieを入手した場合、セッションを制御する可能性があります。これにより、不正な購入やバンキング情報の窃取、ソーシャルメディアプラットフォームへのスパム投稿などの悪意のある行為を可能にする可能性があります。
このタイプのXSSは、悪意のあるスクリプトがWebサーバーから反射してユーザーのブラウザで実行されるため、「反射型」攻撃と呼ばれます。スクリプトは、ページが読み込まれた時にユーザーのブラウザでのみ動作し、継続的ではなく動作するため、「非永続的」とも呼ばれます。
保存型XSS攻撃は、反射型XSS攻撃よりも深刻です。保存型XSS攻撃では、悪意のあるスクリプトがターゲットサーバーに永続的に保存されます。
攻撃者は通常、コメントボックス、ユーザープロファイル、またはユーザーコンテンツを受け入れて保存する入力フィールドなどのフォームフィールドに悪意のあるスクリプトを埋め込むことによって、この形式のXSSを実行します。投稿、コメント、またはフォームが送信されると、スクリプトがWebアプリに挿入され、Webアプリのデータベースに保存されます。他のユーザーが影響を受けたページを読み込むと、保存されているスクリプトがブラウザで実行されます。反射型XSS攻撃と同様に、スクリプトはCookieやその他のユーザー情報を盗み、攻撃者に送り返す可能性があります。
このタイプのXSSは、ページがアクセスされるたびに実行されるため、「永続的」とも呼ばれます。これは、保存型XSS攻撃が特に危険と言われる理由でもあります。単にWebページを閲覧する以上のやりとりなしに、多数のユーザーに影響を与える可能性があるからです。
個々のユーザーは、XSS攻撃のリスクを軽減するためにいくつかの手段を講じることができます。
多くのXSS攻撃はフィッシングスキームやその他のソーシャルエンジニアリング戦術から始まるため、ユーザーは不審なメールやメッセージの識別方法を学ぶ必要があります。適切なITチームまたはセキュリティチームに通知することで、ユーザーはXSS攻撃を阻止し、その他のセキュリティ問題に対処することができます。
もしユーザーがオンラインフォーラム内や、未知の、信頼していない人からのソーシャル投稿でリンクを見つけたら、それをクリックする前によく考えるべきです。一見正当なリンクでも、ユーザーは慎重に進める必要があります。XSS攻撃のきっかけとなるリンクの多くは、その中に正当なURLが含まれているため、一見正当なリンクに見えます。しかし、ユーザーは、.com、.org、.gov、またはその他のサフィックスの後の全要素を含め、リンク全体を確認する必要があります。ページアドレスの後の予期しないテキストは、悪意のあるコードである可能性があります。
開発者は、以下の主要なベストプラクティスを実装することにより、XSS攻撃の防止において重要な役割を果たすことができます。
開発者は、一定の基準を満たさない限り、ユーザーがページやフォームにデータを投稿できないようにするルールを実装できます。例えば、フォームが社会保障番号や電話番号を要求する場合、開発者はこの入力に数字、ダッシュ、または丸括弧のみを使用するというルールを作成できます。より堅牢な攻撃防止のために、開発者は、< script >タグなど、XSS攻撃で一般的に使用されるタグや文字を明示的に拒否する検証ルールを設定することができます。
開発者はまた、ユーザーがコメント、投稿、フォーム入力でHTMLを使用するのを防止することもできます。HTMLコンテンツは、悪意のあるスクリプトを投稿したり、悪意のあるコードを含むURLへのリンクを隠したりする手段になり得ます。
企業がユーザーにフォーマット化されたテキストや画像などのリッチコンテンツの投稿を許可する場合、Markdown（軽量マークアップ言語）を組み込んだり、「What-You-see-Is-What-You-Get」（WYSIWYG）エディター内でリッチテキストのフォーマットを有効にしたりすることができます。いずれの方法を用いても、リッチコンテンツをより安全にサポートできます。
開発者は、Webサーバーに投稿された後、別のユーザーに表示される前にデータを検査するプロセスを実装することで、XSS攻撃による被害を防ぐことができます。例えば、開発者がHTMLの使用を許可している場合でも、ブラウザで実行される前にすべてのHTML入力をサニタイズし、悪意のあるコードを除外することができます。
出力エンコーディングと「エスケープ」は、同様のアプローチに従います。これは、ページに何かが書き込まれる前に、ユーザーの入力内にある悪意のあるスクリプトやその他のコードを通常のテキストに変換することを目的としています。出力エンコーディングは、コードを別のフォーマットに変換します。エスケープは、コードに特殊文字（バックスラッシュや引用符など）を追加します。どちらの場合でも、ブラウザは結果のテキストをコードとして解釈して実行することはありません。サニタイジングはコードを除外しますが、出力エンコーディングとエスケープはコードを無害化しながら保存します。
開発者は、Webアプリ開発全体にセキュリティを統合する必要があります。例えば、ユーザーの入力を受け付けて表示する領域に焦点を当てたコードレビューを実施する必要があります。また、アプリを公開する前に脆弱性を特定するために、脅威モデリングとテストを実施する必要もあります。
セキュリティチームは、XSS攻撃を防止して迅速に対応するために、いくつかのベストプラクティスを実施できます。
セキュリティチームは、Webサーバーが悪意のあるスクリプトをブロックし、攻撃者によるユーザーCookieの盗用を防止するために正しく設定されていることを確認する際に役立つ、いくつかの手順を実行できます。
コンテンツセキュリティポリシーの実装：開発者とセキュリティチームが協力して、WebサイトとWebアプリのための強力なコンテンツセキュリティポリシー（CSP）を定義し、Webサーバーに実装する必要があります。CSPは、特定の種類の攻撃を検出して軽減することができるセキュリティの追加層です。XSS攻撃を防止するために、実行できるスクリプトを制限します。ブラウザが有害なスクリプトを読み込むことを防止するCSP HTTP応答ヘッダーを返すようにWebサーバーを設定できます。
Cookieの保護：セキュリティチームは、WebサーバーがCookieを処理する方法について特別なルールを設定し、Cookieの窃取の可能性を減らすことができます。例えば、Cookieを特定のIPアドレスに紐付けることができます。ほとんどのユーザーは動的IPアドレスを持っているため、IPアドレスとCookieの接続は長く続きません。その結果、攻撃者はこれらのCookieを盗んで使用することができません。
さらに、セキュリティチームは、JavaScriptがCookieにアクセスするのを完全にブロックできます。その手段の1つとして、Cookieを生成する際にHttpOnlyフラグをCookieに追加する方法があります。フラグは、セッショントークンや認証資格情報といったユーザーの機密情報がCookieに含まれている可能性があることを示します。HttpOnlyフラグをサポートするブラウザは、その情報を公開しません。
Webアプリファイアウォール（WAF）は、XSS攻撃に対する重要な防御線を提供することができます。WAFは、Webアプリの前に配置されたリバースプロキシサーバーとして動作し、アプリとインターネット間のHTTPトラフィックを監視およびフィルタリングすることで、当該アプリを保護します。企業は、WAFルールを設定してURLに悪意のあるスクリプトがないか検査し、ユーザーへの反射をブロックすることができます。機械学習を用いたWAFソリューションは、ルールを掻い潜ろうとする試みを検出し、既知の攻撃のバリエーションを特定することで、さらに強力な保護を提供します。
多くのXSS攻撃はフィッシングから始まるため、セキュリティチームはフィッシング攻撃に対して防御を強化する必要があります。疑わしい電子メールやメッセージを識別する方法をユーザーに教えるだけでなく、セキュリティチームは、電子メールをブロックするセキュリティ機能を実装したり、マルウェアの実行を防止するためにブラウザ分離サービスを使用したり、ユーザーが悪意のあるダウンロードを防止するためにセキュアWebゲートウェイ（SWG）をインストールしたり、リアルタイムでフィッシング攻撃を検出してブロックするために、メールセキュリティツールを展開したりすることができます。
セキュリティチームは、本番環境で脆弱性をテストする必要があります。チームは手動で侵入テストを実行したり、自動XSSスキャナーを使用したりすることができます。
広範な防止策にもかかわらず、企業は依然としてXSS攻撃の対象となっている可能性があります。早期復旧のためには、インシデント対応プランを整備することが不可欠です。このプランには、Webアプリケーションのアクティビティを監視し、疑わしいイベントが発生した場合に対処するための戦略を含める必要があります。次に、チームは根本原因を分析し、攻撃手法を特定します。攻撃が終わったら、学んだ教訓を応用してセキュリティ機能を強化し、ポリシーを更新し、Webアプリの脆弱性にパッチを適用する必要があります。
Cloudflareは、企業やユーザーがXSS攻撃を防止する際に役立つ製品と機能をご用意しております。
Cloudflare WAFについて詳細をご覧ください。