クラウド・ホスティング運用現場の悩みを解決! from GMOクラウドアカデミー(19) Webサイト開発時のセキュリティ対策（前編）

皆さん、お元気ですか？GMOクラウドの縞子です。このところ、暑い日が続いたかと思うと肌寒くなったりしたせいか風邪をひいてしまいました。Web のセキュリティ対策も大事ですが、己のウイルス侵入対策がやや甘かったようです…。リ○ビタンＤを飲んで、体内システムの活性化を図っているところですが、エネルギーがウイルス攻撃に持っていかれているせいか、脳内CPUが断続的に停止し（日頃からよく止まりがちでしたけども）、なかなか筆が進みません。何はなくても健康は大事ですね。しみじみ。これから梅雨に入り不安定な気候が続くと思いますので、皆さんは体調を崩さぬよう、くれぐれもご自愛ください。

この記事は2部構成で、前編では「クロスサイト・スクリプティング」をご紹介させていただきます。

Ⅰ.はじめに
Ⅱ.クロスサイトスクリプティング
Ⅱ-Ⅰ 攻撃手順と影響
Ⅱ-Ⅱ 対策方法
Ⅱ-Ⅲ 脆弱性確認例と対策手順

Ⅰ.はじめに

今回のタイトルについては、Web エンジニアの方は日頃から気にされていることと思いますし、既にいろいろな対策をとられていることと思います。関連書籍は充実していますし、インターネット上にも多くの情報が存在しています。とはいえ、もしWebサイトを作り始めたばかりで、「セキュリティ対策ってまずは何をしたらいいのだろう」と悩んでいる方がいましたら、情報処理推進機構（IPA）の「安全なウェブサイトの作り方」を参考にすることをお勧めします。現時点、最新版は2015年3月26日に発行された改訂第7版であり、Webサイトの各脆弱性についてのトレンド、影響範囲、原因および対策方法について詳しくとりまとめられていますので、ぜひご一読ください。

今回は、「安全なウェブサイトの作り方」の第一章、"ウェブアプリケーションのセキュリティ実装"に列挙されている脆弱性のうち、報告頻度が高いクロスサイト・スクリプティングとSQLインジェクションについて攻撃パターンや対策方法などを紹介したいと思います。

Ⅱ.クロスサイト・スクリプティング

クロスサイト・スクリプティング（Cross-Site Scripting）は、よく略称のXSSで記載されることがあります。以下にXSSの攻撃手順や、実行された結果どのようなことが起こるのか、またその対処方法などを紹介します。

【Ⅱ-Ⅰ. 攻撃手順と影響】

Webサイトでは、ユーザーからの入力やHTTPヘッダー（※１）で送信された情報に応じて、Webページに出力を行うという処理がごく頻繁に行われます。例えば、あるサイト上で新規アカウントを作成した際、ユーザー名とパスワードを入力すると確認画面が表示されるのを見たことがあるかと思います。

もしこのサイトがXSS脆弱性を持っていた場合、確認画面にデータを出力する際、悪意のある人によって仕掛けられたJavaScriptが実行され、Cookie（※２）に保存された情報が漏えいする可能性があります。漏えいしたCookie情報に、サイトへのログイン認証に関係するもの（ユーザーIDやセッションIDなど）や個人情報（電話番号やメールアドレスなど）が保存されていたなら、それらが悪用される危険性があります。

または、偽の入力ページが表示される場合があり、そこに入力されたユーザー情報が盗みとられる被害が発生します（フィッシング詐欺による情報漏えい）。

※１. HTTPヘッダー…WebブラウザからWebサイトにHTTPでリクエストを送信するとき、もしくはWebサイトからブラウザにレスポンスを返すとき、ブラウザ情報、データの種別や遷移元ページのURLなど、HTTPメッセージに関するさまざまな情報をHTTPヘッダーに乗せて相手側に通知します。（参考サイト: HTTP ヘッダーのリファレンス）
※２. Cookie…Webサイト提供者が、Webブラウザを通じてサイト訪問者のコンピューターに一時的にデータを書き込んで保存させる仕組みです。例えば訪問者が最後にサイトを訪れた日時や、サイト訪問回数などがCookieに記録されます。（参考サイト: Cookie 【 HTTP Cookie 】クッキー）

【Ⅱ-Ⅱ. 対策方法】

攻撃手順で見ていただいたように、悪意のある人が仕込んだJavaScriptが実行されることが問題の原因となります。

そのためWebサイトの開発者は、外部から渡されたデータや値を使ってそのまま出力しないようにプログラミングする必要があり、最低限次の手順を実装します（「安全なウェブサイトの作り方」ではより詳しく対策方法を挙げていますので、そちらを併せて参照ください）。

Webページに出力するすべての要素に対してエスケープ処理を施す。
HTTPレスポンスヘッダーのContent-TypeフィールドにCharsetを指定する。

【Ⅱ-Ⅲ.脆弱性確認例と対策手順】

XSS脆弱性のあるページにてXSSが実行された際の様子と、対策処理を実装した場合の様子を比較のためテストしてみます。

下のPHPで実装したテストページ（hello.php）は、GETメソッドでusernameパラメーター値を取得し、Webページに「こんにちは○○さん！」と表示させるものです。

●hello.php

<?php
header("Content-type: text/html; charset=UTF-8");
setcookie("testcookie", "abc");
?>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">    </head>
<body>
<h2>こんにちは <?php echo $_GET['username']; ?> さん！</h2>
</body>
</html>

Usernameパラメーターに「縞子」をセットすると、ブラウザ上では次のように表示されます。

では、ユーザー名ではなく、alert(document.cookie);でCookieを表示させるスクリプトをusernameパラメーターにセットした場合はどうなるでしょうか。

アラートボックスの中にCookie情報が表示されてしまいました。ここで悪意のある人にCookieを送信するようなスクリプトが仕組まれていましたら、情報漏えいとなり悪用される危険性が生じます。

次に、対策のため出力文字列にエスケープ処理をした場合はどうなるか試してみます。PHPではHTMLの特殊文字をエスケープするhtmlspecialchars()という関数が用意されていますので、この関数を先ほどのhello.phpに追加します。

●hello.php

<?php
header("Content-type: text/html; charset=UTF-8");
setcookie("testcookie", "abc");
?>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">    </head>
<body>
<h2>こんにちは <?php echo $_GET['username']; ?> さん！</h2>
</body>
</html>

※補足: htmlspecialchars()のパラメーターについて htmlspecialchars() の第２パラメーターのENT_COMPAT|ENT_HTML5は、< >や&などのHTMLの特殊記号の他にダブルクオート（"）もエスケープ対象とし、またコードをHTML5として処理するよう指定しています。第３パラメーターでは、文字列を変換する際のエンコーディングをUTF-8に指定しています（PHP 5.4 以降では、デフォルトでUTF-8が指定されます）。

hello.phpを修正した後、再びJavaScriptを含んだURLを表示させた結果は次の通りです。

今度はスクリプトが実行されず、文字列として表示されていますね。なお、今回脆弱性を持ったページ（修正前のhello.php）を実行したところ、ブラウザによってはスクリプトを実行させないものがありました（InternetExplore 11、Chrome ver.43など）。ブラウザ側でXSS対策を行っていてくれることはセーフティーネットとなりますが、それでもWebサイト側での対策が不要となるわけではなく、やはりサイトのプログラムでの対策を行う必要があります。

以上、「クロスサイト・スクリプティング」について、説明いたしました。後編では、「SQLインジェクション」について、紹介いたします。

※ご利用中のクラウドサービスによっては、利用できない場合があります。

この記事を書いた人 GMOクラウド　縞子 GMOクラウド株式会社企画開発部開発グループ所属。2014 年に同社へ入社し、主に SaaS開発に携わる。これまで使用して来た言語は C/C++、PHP、Java、JavaScript。猫派ですが、肉球のある生物はみんな好きです。 GMOクラウド　縞子の記事一覧