基本を超えて：XSSの脆弱性を深く理解する

Webアプリケーションはその性質上、サイバー犯罪者によるさまざまな攻撃に常にさらされており、すべての情報漏えいの26%に関与しています。攻撃者は、既知の脆弱性を探すために公開されたアプリケーションを絶えずスキャンし、攻撃に向けた情報を収集します。攻撃対象となり得る候補を十分に集めると、検出した脆弱性をできるだけ多く悪用しようと、次々と攻撃を試みます。脆弱性を先回りして検出・管理しなければ、組織はすぐに侵害されるおそれがあります。

この記事では、最も一般的なWeb攻撃の一つであるクロスサイトスクリプティング（XSS）攻撃について、その発生の仕組みと防止策を解説します。

XSS攻撃とは？

組織が直面するWeb攻撃の中でも、XSS攻撃は特に一般的です。この攻撃では、悪意のあるスクリプトをWebページに埋め込み、ユーザーがページにアクセスした際に実行させます。深刻な影響をもたらすことから広く発生しており、現在のOWASP Top 10で3位にランクインしています。

ユーザーのプライバシーを侵害し、組織に多大な損害を与える可能性があるため、こうした脆弱性は重大なセキュリティ脅威です。XSSの脆弱性が悪用されると、Cookieやセッショントークンが盗まれてユーザーセッションが乗っ取られ、攻撃者が機密性の高い個人情報や財務データに不正アクセスできるようになります。データ窃取だけでなく、Webサイトの改ざんによって組織の評判が損なわれ、ユーザーの信頼が失われるおそれもあります。

また、フィッシングなどを目的としてユーザーを悪意のあるサイトにリダイレクトしたり、ユーザーに気づかれないままWebアプリケーション上の操作を改ざんしたりすることも可能です。こうした改ざんにより、偽の情報を送信させたり、不正な金融取引を開始させたりする場合があります。

XSS攻撃の仕組み

XSS攻撃にはいくつかの種類があり、それぞれ仕組みや潜在的な影響の度合いが異なるため、問題はさらに複雑です。主な種類は、格納型、反射型、DOMベース型の3つです。

格納型（永続型）XSS

この攻撃では、データベース、フォーラムの投稿、訪問者ログ、コメント欄など、標的のWebサーバーに悪意のあるスクリプトを直接保存させます。問題のスクリプトを含むデータをブラウザーが取得すると、ユーザーのブラウザー上で自動的に実行されます。悪意のあるコンテンツがサーバーから削除されない限り脅威が続き、多数のユーザーを標的にできるため、特に危険な攻撃です。

たとえば、攻撃者がスクリプトを含むコメントをブログに投稿します。投稿が送信されるとサーバーに保存され、別のユーザーがその投稿を開いた際に、スクリプトがそのユーザーのブラウザーで自動実行されます。

反射型（非永続型）XSS

永続型XSSとは異なり、反射型では悪意のあるスクリプトを保存する必要はありません。代わりに、URLやWebリクエストにスクリプトを埋め込んで攻撃します。悪意のあるリンクをクリックする、フォームを送信する、悪意のあるサイトに移動するなど、ユーザーの操作をきっかけに攻撃が成立します。ユーザーがスクリプトを含む操作を行うと、メッセージが送信され、Webサーバーから反射されて被害者のブラウザーで実行されます。そのため、サーバーから送られたように見えます。攻撃者は、フィッシング、悪意のある広告、Bit.lyのようにURL全体を隠す短縮URLなどを使い、ユーザーに悪意のあるリンクをクリックさせようとします。

反射型攻撃の例として、攻撃者がスクリプトを埋め込んだリンクをユーザーに送るケースがあります。ユーザーがリンクをクリックすると、スクリプトがサーバーに送信され、ユーザーのブラウザーに反射されて実行されます。複数のユーザーに影響を与えるようサーバーに保存されるのではなく、ユーザーが操作するたびに一度だけ実行されます。

DOMベース型XSS

DOMベース型XSSは、Webページのドキュメントオブジェクトモデル（DOM）を利用する点で、ほかの2種類のXSS攻撃とは大きく異なります。サーバーにペイロードを送信するのではなく、多くの場合クライアント側のスクリプトを通じて、被害者のブラウザー内のDOM環境を改変し、ペイロードを実行します。

たとえば、適切な検証を行わずにURLのデータを使用するWebアプリケーションが該当します。検証が不十分だと、DOMの改変に使えるデータが入力され、悪意のあるスクリプトが実行される可能性があります。XSSがクライアント側で実行され、サーバーの応答に悪意のあるコードが含まれない場合があるため、検出が困難です。

XSS攻撃を防ぐには？

現代的なXSS対策は、開発ライフサイクルにセキュリティを組み込むことから始まります。開発者ファーストの包括的なセキュリティプラットフォームは、静的アプリケーションセキュリティテスト（SAST）や動的アプリケーションセキュリティテスト（DAST）など、複数のテスト手法を用いて脆弱性を包括的に把握します。

AIを活用したSASTツールはソースコードの欠陥を分析し、DASTツールは実行中のアプリケーションをテストして、実行時にのみ現れる脆弱性を検出します。これらのテストツールをCI/CDパイプラインに統合することで、組織は開発者が脆弱性を早期に発見・修正できるよう支援し、本番環境で悪用されるずっと前に対処できます。

脆弱性の可能性が検出された場合、すべてのユーザー入力を信頼しない方針を徹底することで、XSS攻撃の防止に役立ちます。この対策では、入力が想定された形式に合っているかを検証し、有害なコンテンツを取り除く、または無害化するサニタイズを行います。入力があるところには常にXSSの脆弱性が生じる可能性があるため、入力はサニタイズするのが基本です。

包括的に防御するには、出力もエンコードして無害化する必要があります。この処理により、特殊文字がHTMLまたはURLエンコードされた文字に変換され、埋め込まれたスクリプトが機能しなくなります。悪意のあるユーザー入力が保存されてしまった場合でも、そのデータが後の攻撃に悪用されることを防げます。

Snyk API & WebでXSS攻撃を防ぐ

アプリケーション開発を安全に進めるには、脆弱性を検出するだけでなく、開発者がすばやく修正できるよう支援するプラットフォームが必要です。

Snyk API & Webは、XSSやSQLインジェクションなど、3,000件以上の脆弱性を検出します。Snyk AI Trust Platformの一部であるSnyk API & Webは、CI/CDパイプラインに直接統合できます。既存のワークフロー内で、優先順位付けされた実行可能な修正アドバイスを提供し、開発者を支援します。この自動化された開発者ファーストのアプローチにより、スピードを犠牲にすることなく、ライフサイクル全体を通じてアプリケーションを安全に保てます。

デモを予約して、Snyk API & Webでアプリケーションを保護する方法をご確認ください。

よくある質問

XSS攻撃はあらゆるWebサイトに影響を及ぼす可能性がありますか？

ユーザー入力を処理も表示もしない静的なWebサイトだけが、XSS攻撃の影響を受けません。

最新のWebフレームワークはXSS攻撃を受けないのでしょうか？

最新のフレームワークはリスクを軽減できますが、特に正しく使用されていない場合、完全に安全というわけではありません。

定期的なセキュリティアップデートでXSS攻撃を防げますか？

定期的なアップデートで脆弱性を軽減できますが、プロアクティブなセキュリティ対策やコーディング手法も重要です。

XSS攻撃を防ぐには、入力値の検証だけで十分ですか？

入力値の検証は不可欠ですが、効果的に防止するには、出力エンコードやその他のセキュリティ対策と組み合わせる必要があります。