HPを守る!クロスサイトスクリプティング(XSS)の脆弱性対策

「クロスサイトスクリプティングの概要はなんとなくわかったけれど、実際どう対策すればよいのだろう」――あなたがそう思ったとき、次のステップへ進むことができます。

前回は、「セキュリティ対策を行いたいとき、まず脆弱性を知るところからはじまる」という話をしました。

「クロスサイトスクリプティング(以下:XSS)の脆弱性」、その概要について触れてきたことを前提に、XSSの対策について説明していきます。

クロスサイトスクリプティングの脆弱性対策としてやるべきこと

XSSの対策としてやるべきことは、以下の項目です。

  • WAFを導入する
  • CMSでホームページをつくるときに気をつけるべきこと
  • プログラムを書くときに気をつけるべきこと
  • ヘッダに設定を加える

では、順を追って解説していきます。

WAFを導入する

「WAF」とは、「Web Application Firewall(ウェブ・アプリケーション・ファイアウォール)」のことです。Webサーバーを守るための門番、と捉えておくとよいでしょう。

ファイアウォールは、外部からのあやしいアクセスを防いでくれたり、内部から外部へ向かう不自然な通信を防いでくれたりします。

しかし、WAFを導入するだけでは安心できません。理由は後述します。

CMSでホームページをつくるときに気をつけるべきこと

CMSの選定

「CMS」とは、「コンテンツ・マネージメント・システム」のことです。ホームページをつくることができます。

実際にプログラムを書いてホームページをつくるということは、1から作品を創りあげるようなもので、相応の知識や指針がなければむずかしいでしょう。

その代わり、自由度が非常に高いです。

CMSは、1からプログラムを書いて、ホームページをつくるよりは手軽です。しかし、自由度に関しては劣ります。こちらも相応の知識がなければ、つくるのはむずかしいでしょう。

CMSは、ホームページをつくるノウハウや、テンプレートなど、探せばすぐに情報を得ることができます。

カスタマイズをおこなう分には事欠かないですが、セキュリティ面では非常に脆弱性が多い、ということもあります。

最新バージョンにグレードアップすることはもちろん、セキュリティ対策を施すことは必須です。管理のしやすさ、作りやすさなど、さまざまな観点でCMSを選定してみましょう。

プログラムを書くときに気をつけるべきこと

「プログラム」とは、人間の代わりに、コンピューターに指示を出してくれるものです。プログラムを書くときに気をつけておきたいことを挙げていきます。

サニタイズ処理をおこなう

サニタイズ処理のしくみ

「<」「>」「"」「'」などの特別文字を無効化する処理のこと、サニタイズ処理といいます。

外部から悪意のあるスクリプトを挿入された場合、「&lt;」「&gt;」「&quot;」「&#039;」というように、特別文字を変換することによって、スクリプトが意味を成さなくなります。

入力値を制限する

文字種や文字数を制限します。たとえば、入力フォームに郵便番号を入力してほしい時は、「半角数字」を「7ケタ」までしか入力できないようにしておくとよいでしょう。

「http」「https」のほかのスキームを入力できないようにする

「スキーム」とは、URLの先頭に記載されている、「○○://」のことです。「http://」「https://」などの通信プロトコルを指定します。

悪意のあるスクリプトを挿入されないよう、スキームをチェックするプログラムを書いておくとよいでしょう。

「http」「https」以外のスキームを入力できないようにしておくと安全です。

適切な関数を選定する/使用しているライブラリを更新する

ホームページができあがったあとに対策を施していても、プログラム内に書かれている関数に脆弱性があっては、意味がありません。

ふだん使っている関数に脆弱性がないか、一度調べてみる必要があります。ライブラリも同様の理由で、最新の状態に更新しておくことが必須です。

「パラメータ名」もサニタイズする

クロスサイトスクリプティング(XSS)の対策

たとえば、入力フォームで入力内容を送信する際、「パラメータ名」に「値」を設定します。「値」にサニタイズ処理をおこなう場合が多いかもしれませんが、「パラメータ名」はどうでしょうか。

「値」にサニタイズ処理をおこなっていても、「パラメータ名」にサニタイズ処理がされていないと、XSSの脆弱性を突いた攻撃をされる可能性があります。

文字コードを「UTF-8」に統一する

文字コードの変換ミスなどの不具合がある場合、その不具合を利用して、攻撃をされる可能性があります。

ミスが発生しないよう、文字コードを統一し、不具合を作りこまないように心がけることが大切です。

文字コードに関しては非常に複雑な話ですので、イメージをつかんでもらいやすいよう、大まかに説明していきます。

「文字コード」

コンピューターは、数字の「0」「1」で構成されたものしか理解できません。ひらがなの「あ」ですら認識することができないのです。

文字コードを「UTF-8」に統一する理由

そのため、人間とコンピューターがスムーズに伝達を行えるよう、対応表が存在します。その対応表が文字コードです。

文字コードを「UTF-8」に統一する理由
※わかりやすく説明するための例です。実際にこのような対応表は存在しません。

「UTF-8」

文字コードには、2つの対応表が存在します。

文字コードを「UTF-8」に統一する理由
※わかりやすく説明するための例です。実際にこのような対応表は存在しません。

≪対応表A≫

  • 文字
  • 文字にIDを割り当てたもの

≪対応表B≫

  • 文字にIDを割り当てたもの
  • 「0」と「1」で構成された数字

UTF-8は≪対応表B≫にあたるものです。UTF-8だけでなく、対応表にはさまざまな種類が存在します。

「ASCIIコード(アスキーコード)」

ASCIIコードは≪対応表A≫にあたりますが、2進数も割り当てられているので(「0」や「1」で構成されている)、≪対応表B≫の役割も担っています。

以下は、ASCIIコードと、UTF-8の文字コードを一覧から抜粋したものです。参考までにご覧ください。

※ASCIIコード(抜粋)

16進数 2進数 文字
41 01000001 A
42 01000010 B
43 01000011 C
44 01000100 D
45 01000101 E

※UTF-8の文字コード(抜粋)

40+α 文字
41 A
42 B
43 C
44 D
45 E

ASCIIコードとUTF-8には互換性があります。ASCIIコードに世界中の文字を加えたものが、UTF-8です。

文字コードをUTF-8に統一しておくと、人間とコンピューターがスムーズに伝達を行えます。文字化けすることもありません。

スクリプトでない文字列を、誤ってスクリプトと認識してしまうおそれもありません。よって、XSSの脆弱性も作りこみにくくなります。

ヘッダに設定を加える

「X-XSS-Protection」

最近のWebブラウザーには、XSSフィルタ機能(以下:フィルタ)がついています。「X-XSS-Protection」は、このフィルタを強制的に有効にするものです。

「X-XSS-Protection」のオプションである「0」はフィルタを無効にする値、「1」は有効にする値です。

「1; mode=block」は、フィルタを有効にするだけでなく、XSS攻撃された場合、Webページの読み込みをブロックします。

Webサーバーの設定ファイルや、.htaccessファイルなどで、ヘッダにパラメータを加えることができます。

「.htaccess」ファイル

Webサーバーをディレクトリ単位で制御できるファイルです。テキストファイルで作れるので、非常に手軽に設定できます。

制御したい階層にこのファイルを置くと、機能します。Webサーバーによっては使用できない場合がありますので、事前の確認が必要です。

≪設定例≫

<ifModule mod_headers.c>
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options DENY
Header always set X-Download-Options: noopen
Header always set X-Powered-By: ""
</ifModule>

<IfModule mod_php5.c>
php_flag session.cookie_httponly on
php_flag session.cookie_secure On
</IfModule>

<IfModule mod_php7.c>
php_flag session.cookie_httponly on
php_flag session.cookie_secure On
</IfModule>

WAFを導入しただけでは安心できない理由

そもそもWAFは、「応急処置として使う」ための装置です。「プログラムの不具合などを改修するまでに、応急処置としてWAFを設定する」という認識で、WAFを使うとよいでしょう。

応急処置として使うための装置ですので、WAFにも機能的な限界があります(WAFは、決められた文字列を定義して、フィルタリングをおこないます)。

プログラムの不具合は、システム固有のものです。まず、どのようなXSSの脆弱性があるか、しっかりと認識をしましょう。その上で、WAFのフィルタをチューニングする必要があります。

攻撃者は、さまざまな観点から情報を集め、ホームページを攻撃します。WAFを設定したことで安心し、ヘッダにセキュリティ対策用のパラメータを設定していないと、その甘さを攻撃者に見抜かれてしまいます。

また、「WAFを使っているが、その機能を理解していない」という場合も見抜かれてしまいます。

セキュリティ診断をおこなう際、擬似的な(実害のない)攻撃を加え、ホームページの脆弱性を検出します。

私自身がセキュリティ診断をおこなったホームページの中で、「WAFを使っていて、ヘッダにセキュリティ対策用のパラメータを設定していない場合、擬似的な攻撃が通ってしまう」いった検出パターンがいくつかあります。

「セキュリティ対策はWAFに頼ろう」という意識を改め、ホームページをしっかりテストしていくことが望ましいです。

また、しっかりとしたプログラム改修を基本に考えていきましょう。

まとめ

今回は、XSSの脆弱性対策としてやるべきことを紹介しました。WAFを導入することは簡単ですが、それだけで安心はできません。

また、万全に対策を行っているつもりでも、100%安全とは言いがたいです。攻撃者は日々スキルアップしています。

常に脆弱性情報に対して敏感であること、すぐに対策できるような知識を取り入れることが大切です。

次回は、「XSSの脆弱性をテストする方法」について触れたいと思います。