スクリプト対策から脆弱性チェックまで
クロスサイトスクリプティング攻撃とは 後編――防止方法
いまだに攻撃者の攻撃手段として利用されるクロスサイトスクリプティング（XSS）。この、簡単に実行できてしまうXSS攻撃による被害を最小限に抑える方法を取り上げる。
前編では、クロスサイトスクリプティング（XSS）攻撃の基礎知識として、XSS攻撃が成立する仕組みについて説明した。今回はXSS攻撃を防ぐための手法を紹介する。
XSS攻撃の防止方法
自社のサイトがXSS攻撃の被害に遭う確率を下げるためには、何らかの形のセキュリティ開発ライフサイクル（SDL）を使ってWebアプリケーションを開発することが不可欠だ。その目的は、アプリケーションの設計とコーディング段階でセキュリティ関連問題の数を減らし、問題が見つけられずに残ってしまった場合でも危険性を抑えることにある。セキュアなアプリケーションの開発において学ぶべき鉄則として、そのアプリケーションが受け取るデータはすべて、信頼できないソースから来ることを前提としなければならない。これは、そのアプリケーションで受け取るデータ、cookie、電子メール、ファイル、画像など、あらゆるデータに当てはまる。たとえ自分のアカウントにログインして認証を済ませたユーザーからのデータであっても同じだ。
ユーザーの入力データを信頼しないということは、データを信頼できる境界へと受け渡す都度、そのデータの種類、長さ、フォーマット、レンジをチェックするということだ。例えば、Webフォームからアプリケーションスクリプトに変換し、その後エンコードしてから動的ページへ再表示するような場合がこれに当たる。実際の環境では、自社のサイトでユーザー提供のデータが処理されるすべてのポイントを見直し、ユーザーに再提示する前にクライアントサイドから受け取った値をすべて確実にチェックし、フィルタにかけ、エンコードすることになる。
クライアントサイドのチェックは当てにはならないが、ユーザーの入力したデータをWebアプリケーションで利用する前に、サーバサイドの処理で強制的に最小限の英数字セットにすることはできる。正規表現を使って検索と置換を行えば、ユーザーの入力したデータに悪質な意図がないことを確認できる。このクリーニングと検証の作業は、別のプロセスに受け渡す前に、すべてのデータについて実行しなければならない。例えば、電話番号の欄ではカッコと長音記号以外の句読点などは一切受け付けてはならない。「<」「>」などの特殊記号をユーザーが入力してきた場合は、再表示する前にエンコードする必要がある。例えばスクリプトタグをエンコードすれば、ブラウザで<script>と表示されるが実行はされなくなる。エンコードと併せて、Webページでは必ず文字コードを指定し、ブラウザが別の文字セットの特殊記号エンコーディングを解釈してしまわないようにする。
ブラウザではそのページの文字コードのデフォルトの値が必ずしも認識されず、サーバによっては文字コードのパラメータを送ることを認めていない、あるいは認める設定になっていないことを考えると、Webページにこのメタタグを欠かすことはできない。これによって、スクリプトを挿入される可能性が大幅に減るからだ。もしも自社のWebアプリケーションでISO-8859-1の文字コード以外の文字を表示する必要がないのなら（英語など欧州言語の場合はこれで十分足りる）、全ページに次のメタタグを入れて文字コードを指定しておくといい。
<META http-equiv="Content-Type" content="text/html; charset= ISO-8859-1">
リッチデータを受け入れる必要のないWebアプリケーションは、エスケーピングを使えばXSSのリスクを完全に排除できる。もちろん、アプリケーションで「<」「>」などのHTML記号を受け入れなければならないときもある。例えば、フォントのフォーマット指定を機能として取り入れているソーシャルネットワーキングサービス（SNS）などだ。このような入力情報のセキュアなエンコーディングは、HTMLの柔軟性と複雑性故に難しくなる。
そこで、わたしはセキュリティエンコーディングライブラリの利用を勧めている。MicrosoftのASP.NETでは、ユーザーの入力情報をチェックできる認証サーバコントロールを提供している。Apacheサーバで実行しているWebアプリケーションやPerlプログラミング言語を使っているWebアプリケーションなら、「Apache::TaintRequest」モジュールや「PerlTaintcheck」を使って外部データ処理のプロセスを自動化できる。こうした追加的な安全措置をコードに取り入れる方法は、自社の開発者全員に理解を徹底する必要がある。
オーソドックスだが有効な方法
XSS攻撃に対するもう1つのガードとして、認証を受けたユーザーが特定のサービスにアクセスするためにもう一度パスワードを入力しなければならない「境界クロッシング」がある。例えば、ユーザーがcookieで自動的にサイトにログインしたとしても、重要なアカウント情報にアクセスするためには再度ユーザーネームとパスワードを入力しなければならない。こうして境界を増やすことにより、XSS攻撃によってセッションが乗っ取られる可能性を抑えられる。もう1つ、単純だが効果的なのは、複数のマシンがそれぞれ異なる2つのIPアドレスから同じセッションデータを利用しようとしてきた場合、直ちにセッションを終了させる技術だ。セッションIDは、タイムスタンプやIPアドレスなど各ユーザー特有の情報を使って作成できる。この技術はIP詐称によってかわすことが可能だが、自動化された攻撃に対するセキュリティの層を厚くする効果はある。
アプリケーションの開発中には、自動ソースコードスキャンツールとWeb脆弱性スキャナの利用を検討するといい。優れたWeb脆弱性スキャナは、XSSの脆弱性などよくある技術的な弱点を見つけてくれる。自社のサイト上で検索エンジンなどのサードパーティーパッケージを利用する場合、既知の脆弱性や設定上の問題について、必ずベンダーに確認することが必要だ。その後、不正な入力がどう処理されるかを徹底検証する。セキュアだという前提に立ってはならない。
Webアプリケーションを実際に導入する前には侵入テストを実施する必要がある。攻撃のシミュレーションによって、システム設定の不備、ハードウェアやソフトウェアの脆弱性、そのサイトを守っている周辺防御の弱さなどに起因する潜在的なXSSの脆弱性がサイトに残っていないかどうかを判断できる。ISECOMの「Open Source Security Testing Methodology Manual（OSSTMM）」では、セキュリティ検査の実施と結果判定について定評のある方法論を提示しているので、一読をお勧めする。
現在ではほとんどのサイトが、クライアントサイドスクリプトなしには機能しない。従って、ブラウザでスクリプトを無効にするようユーザーに求めるのは、実質的な解決にはならない。何よりも、ほとんどのユーザーはどのみちそのやり方を知らないのだ。XSSに対抗する取り組みとして、MicrosoftがInternet Explorer（IE） 8にXSSフィルタを実装したのは評価できる。この目的は、一般的なXSS攻撃をサーバのレスポンスで再現しようとすると自動的に検出して防止する機能の提供にある。ユーザーに答えられないような質問を提示するのではなく、IEが単純に悪質なスクリプトの実行を阻止してくれる。
しかし行き着くところ、セキュア開発ライフサイクルに従うのはWeb開発者の責任であり、サイトの脆弱性をスキャンしてWebアプリケーションファイアウォールでサイトを守るのはWeb管理者の責任だ。XSSで最終的に傷つくのは顧客と自社の評判なのだ。
本稿筆者のマイケル・コッブ氏は、データセキュリティ・分析関連のトレーニングやサポートを提供するITコンサルティング会社Cobweb Applicationsの創業者、マネージングディレクター。CISSP-ISSAP（公認情報システムセキュリティプロフェッショナル―情報システムセキュリティアーキテクチャプロフェッショナル）の資格を持つ。共著書に「IIS Security」があり、大手IT出版物に多数の技術記事を寄稿している。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[NTTPCコミュニケーションズ株式会社] 「回線速度不足」だけが原因ではない？ Web会議の遅延を解決する方法とは -
製品資料
[東京エレクトロン デバイス株式会社] 工場の可用性向上に重要な「7つの領域」と対策 OTセキュリティ強化の基礎知識 -
製品資料
[リコージャパン株式会社] 問い合わせ対応で本来の業務が進まない、総務や情シスの負担をどう減らす？ -
製品資料
[リコージャパン株式会社] 自社データから高精度な回答を生成、簡単に生成AIチャットボットを構築する方法 -
技術文書・技術解説
[アトラシアン株式会社] IT運用や従業員サポートは生成AIでどう変わる？ 使い方や導入の流れは？
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
全社標準Copilotに絶望？ MS Copilotで問い合わせ6割減できた企業は何が違った
-
2
「Copilot」はなぜ放置される？ “議事録要約止まり”を脱する処方箋
-
3
「AI活用を前提とした業務PCへの移行」に関するアンケート
-
4
「データストレージの活用方法」に関するアンケート
-
5
身代金支払いは逆効果 情シスのためのランサムウェア対策ガイド2026
-
6
多要素認証導入済みでもランサムウェア被害に 復旧費用は平均2億7000万円
-
7
DXを阻む「動くだけ」のレガシーシステムに決別するための生成AI活用術
-
8
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
9
「ITインフラとデータ保護・バックアップ対策」に関するアンケート
-
10
自社を守る「SCS評価制度」活用法 7割の企業が取引先起点の情報漏えいに直面
ホワイトペーパーランキング PR
-
1
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
2
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
3
生成AIで文書活用を進めるには？ 効率化と安全性をどう両立する
-
4
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
5
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
6
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは？
-
7
「スクラム」と「カンバン」の違いとは？ アジャイル型開発手法を徹底比較
-
8
AI時代に成功するための「ナレッジマネジメント」ベストプラクティス
-
9
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー