yohgaki's blog

一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。

その間違いとは

意図の取り違い - 誤読
言語の仕様と実装の理解不足
HTTPやPHP仕様の理解不足
セキュリティ対策をすべき場所の理解不足

です。(※0)

徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。

意図の取り違い - 誤読

最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに対して文字エンコーディングバリデーションを実行して欲しいという思いからこのタイトルになっています。他の言語は他のブロガーが書くべきと思ってもいたからです。しかし、中身を読めば私の意図はシステム全般に対して文字エンコーディングを厳格に処理しなければならない、と主張している事は分かるはずです。

未だに間違いが多いHTTPプロトコルレベルでの文字エンコーディングの取り扱いや、データベースの文字エンコーディングでの取り扱いにも十分に注意するように書いています。データベースに至っては、デフォルトの文字エンコーディングがバイナリかそれに近いエンコーディングに設定されたサーバも少なくありません。これが如何に危険な事であるか、環境やコードによっては致命的であるかは、ここなどを参照してください。

アプリケーションを含め、システム全体が文字エンコーディングを厳格に取り扱わないと十分なセキュリティは確保できません。だから、アプリケーションプログラマもデータベースやXML処理系の様に文字エンコーディングを厳密に取り扱わなければならないと考えています。こう考える理由は、最後の「セキュリティ対策をすべき箇所」を読めば理解できると思います。

私のブログの読者層を考慮したエントリなのでWeb開発者を意識したエントリになっていますが、本当にお願いしたかったのは、すべての開発者(Webに限らず)に文字エンコーディングバリデーションを行う事です。多重セキュリティを実現すべきということです。現在では多重のセキュリティの必要性は説明する必用ないでしょう。

言語の仕様と実装の理解不足

徳丸さんは言語の仕様と実装を十分理解しないで、簡単な実験による結果のみでこのブログのエントリを「何故か"PHPだけは"あたり前にならない文字エンコーディングバリデーション」とのタイトルにすべきだろうと間違った評価をしています。

PHP 4.2からmbstringはデフォルトモジュールとなりました。デフォルトモジュールすべきと提案したのは私だったのでよく覚えています。mbstringにはインプットを自動的に内部文字エンコーディング変換する機能とアウトプットに指定した文字エンコーディングを自動変換する機能を持っています。現状の良くある"日本のPHP環境"ではPerlよりは随分マシな状況です。

徳丸さんのPerlのサンプルコードは以下のようなコードです。

#!/usr/bin/perl
use strict;
use utf8;
use Encode 'encode';
# 非最短形式の'/'を強引に作成
my $s = pack("U0C*", 0xC0, 0xAF);
printf "is_utf8=%d\n", utf8::is_utf8($s);
print encode('utf8', "$s\n");
print $s eq '/' ? "eq\n" : "ne\n";
print $s =~ m#/# ? "matched\n" : "not matched\n";

[yohgaki@dev tmp]$ cat -n tt.php
     1  <?php
     2  mb_internal_encoding('utf-8');
     3  ini_set('mbstring.strict_detection','on');
     4  $s = pack("C*", 0xC0, 0xAF);
     5  echo $s = mb_convert_encoding($s, 'utf-8'), "\n";
     6  echo $s == '/' ? "eq\n" : "ne\n";
     7  mb_ereg('/', $s) ? print "matched\n" : print "not matched\n";
     8  ?>
[yohgaki@dev tmp]$ php -v
PHP 5.2.10 (cli) (built: Jul 22 2009 23:50:59)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
[yohgaki@dev tmp]$ php tt.php

ne
not matched

次の図はWebアプリケーションが動作するコンポーネントです。赤い×印が不正な文字エンコーディングを利用した攻撃が可能となる箇所です。白い線は入出力の可能性がある部分です。

フレームワークを利用していてもフレームワークの仕組みを意図的にバイパスしたり、意図的でなくてもバイパスしてしまう事は良くある事です。

この図の中で、文字エンコーディングをバリデーションする為に一番相応しいコンポーネントはどれでしょうか？まさか、Webブラウザなんて人は居ないですよね？ブラウザでは無理でしょう。エンコーディングがちょっとおかしいだけでページを表示しないブラウザなんて使ってもらえません。サーバ側のWebアプリ周辺のコンポーネントは頑張れば、何とかなるかもしれないですがブラウザだけは制御しようが無いです。

最も確実にチェックできるのは、中心に居るWebアプリです。

フレームワーク? フレームワークも頑張ればそこそこ行けるでしょう。開発環境である以上、フェールセーフには出来てもフールセーフには出来ません。（バカバカしいコード対策は無理）

CMSでも設定によっては簡単にバイパスできる物もありますが、どうしてもフールセーフフレームワークが欲しい方はCMSなどを最小限のカスタマイズで利用した方が良いと思います。

まとめ

徳丸さんのブログを見てびっくりすると同時に失望しました。徳丸さんがWebの基礎的な技術仕様や言語の仕様、実際の現場での利用方法などを理解していないで評論していることが分かったからです。PHPconのビジネスデイでは私も同じように思っていた「良い事」を沢山言われていたのに残念です。

徳丸さん風に書くとすれば、このエントリは「何故か"セキュリティ専門家"でさえ理解してない文字エンコーディング問題」とすべき、といったところでしょうか。

IPA文書の問題

どなたが書いたのか知りませんが、IPAの文書に「例えば、PHPを使わない」というセキュリティ対策を例示している文書があります。文字エンコーディングベースのXSS対策については全くダメなアプリばかりが現状のRubyやPerlについても「例えば、Ruby, Perlも使わない」と書くつもりなのでしょうか？

個人ブログでどの言語は良く無い、使うべきでない、使うに値しない、と書いても何の問題ありません。しかし、IPAは公的要素が強い独立行政法人です。そこの文書でセキュリティ対策として「例えば、○○は使わない」と書いて良いものでしょうか？

例のIPAの文書は職務放棄の文書だと言っても良いでしょう。Perl、Ruby、Python、PHPも作る人が作れば安全なアプリは作れるのです。

PHPにCVEが多かった理由はデフォルトモジュールとバンドルしていた物が比較的多かった事と共有サーバでsuExecなのどの仕組みを利用せず、Apacheモジュールを共有していたホスティング会社が多かった為、本来はフェールセーフ機能であるセーフモードのすり抜けがCVE登録された事にあります。PHPプロジェクトのセキュリティに対する意識の問題もありました。随分マシにはなりましたが、不満は沢山あります。しかし、これはIPAにとって「使わない」と勧める理由にはなり得ません。

PHPアプリに初心者が作るようなセキュリティホールが沢山あったのは、本当に初心者が沢山居たうえ、大量のアプリを作ったからです。また、PHPが簡易フレームワークの役割をしており時期的に本格的フレームワークを利用したアプリが少なかった事も理由の一つです。

IPAの職務に詳しくはありませんが、初心者がセキュリティホールを作るようなソフトウェアの利用を勧めない事が職務なら、真っ先にWindowsXPやFlash, PDFの利用を止めるように勧めるべきでしょう。

IPAの職務とはユーザや開発者がコンピュータをより安全に利用する為の方法を啓蒙する事ではないのでしょうか？プロダクトの利用を中止する勧める、しかも間違った認識に基づき「例えば、PHPを利用しない」などと文書に記載するのは職務放棄ではないでしょうか？

私の言っている事の説明が必要なのであればいつでも呼んで下さい :)

おまけ

以前、大阪？東京？でお会いした時、徳丸さんは私のWebアプリセキュリティ対策入門に書いていたSQLインジェクション対策が気に入らなかったらしく、全てのパラメータを文字列として扱いエスケープする方法ではなく、

(int)$number

のようなキャストであるべきと言われていました。「技術者なら気持ちが悪い」といった感想をお持ちのようで「技術者としてのセンスが悪い」といった旨の事を言われていたようです。

それから、全て文字列にすると遅くなる、などと言う理由も挙げられてました。しかし、速度を求めるならプリペアードクエリを使うべきです。クエリ文字列をダイナミックに生成する必要などありません。

何故間違っているか簡単に解説したのですが理解されていたのかどうか分かりませんでした。間違いを指摘されても、簡単に「はい、そうですね」とは言えない状況なので深追いはしませんでしたけど、どうなんでしょう？

キャストする方法は間違っている場合も多く、注意しなければ問題の原因になります。しっかりしたDB管理者ならDBの整数を言語の整数型等でキャストする危険性を十分理解していると思います。簡単な例を挙げます。DBのID型などは符号無し64整数であるのに、言語は符号付き32整数であることが多いです。64bitプラットフォームでも符号付きであることが多いです。つまり、キャストは意味的に正しくないことが多いのです。このような方法は最初に教えるべきではなく、基礎を理解した上でどちらでもよいTips程度に薦めることが妥当だと思います。このような問題はDB管理者で無くても普通のCプログラマなら知ってて当たり前でしょう。C/C++でプログラムはされた事はない？DBには任意精度型もあるので普通の言語でキャストしても思い通りならない事を前提とすべきです。

データベースアクセスの抽象化ライブラリなどでプリペアードクエリをサポートしないDBでも、プレイスホルダが使えるようになっています。メタデータを参照してキャストしていると思いますか？まだ疑問に思える方は各言語のDBアクセスの抽象化ライブラリの実装などを参照すると良いです。

そもそも自分でコンパイラなどを実装した事がある人であれば解る話です。SQLパーサを普通に実装すればパラメータはリテラルであれば良いことにするでしょう。リテラルには文字列、整数、任意精度整数、日付などが含まれると定義するはずです。SQLは方言の固まりでもあるので実装によっては使えない物もあるかも知れませんが、広く使われているDBMSの場合は問題ありません。

技術的知識を背景に最適な対策は何であるか？合理的でセキュアな対策は何であるか？選択する事はそれほど難しくないと思うのですが....

あまり身の無い議論は不毛なのでやる事やりましょう！

(※0)まっちゃさんが横から眺めて喜ばれそうな展開です。しかし、今回はブログで決着が着く話ですね。

(※1)実際に私が使った例をあげると、多数のフォーム入力でバリデーションを最適化するために、前のフォームでバリデーションした結果を圧縮してメッセージダイジェストを取り、改ざん防止をしてフォームに埋め直すという処理等を行うコードがあります。普通のサイトには必要ないですが、これはネットワーク負荷低減とパフォーマンス向上に役立って便利な事があります。

(※2)この記事を書くためにRFC1869を検索したのですが、最初に見つかった文書がHTTPヘッダと文書のエンコーディングが一致していない事には思わず苦笑いしてしまいました。こういうページがあるからブラウザのデフォルト設定が文字エンコーディングを自動認識するようになってしまうのです。自動認識を有効にすると文字エンコーディングベースのXSSにより脆弱になるのですけどね。

追記:「PHPで手っ取り早く対策するには?」と聞かれたので書いておきます。エントリ中にも書いていますが、UTF-8の場合は

mbstrign.strict_detetion = on
mbstring.http_input = auto
mbstring.internal_encoding = utf-8
mbstring.http_output = pass

とします。(strict_detectionを入れ忘れていたので追加しています)

php.iniや.htaccess、httpd.confでphp.iniの値を変更します。php.iniで変更した場合、多少自由度が落ちます。バイナリで受け取りたい場合、formを作ってenctype="multipart/form-data"にしなければなりません。(apacheを使っているなら.htaccessやhttpd.confでオーバーライドも可能です)

基本的に入力データをサニタイズしているのと同じです。個人的には

mbstrign.strict_detetion = on
mbstring.http_input = pass
mbstring.internal_encoding = utf-8
mbstring.http_output = pass

として、すべてのパラメータをしっかりバリデーションし不正な入力はログして、プログラムを停止するようにして欲しいと考えています。

ユーザエージェントなどを表示することは比較的よくあると思いますが、$_SERVER,$_ENV,$_FILESは一切エンコーディング変換されません。注意してください。

他にも考えなければならないケースがいろいろあります。exifなどにも不正な文字エンコーディングが含まれていて攻撃される可能性があります。id3などに含まれる情報も同じです。アップロードされたファイルの中身を読む(CSVなど)場合もバリデーションが必用です。

トータルでセキュリティを考えるなら、文字エンコーディングのバリデーションは自分で行うことを基本とした方がより安全なWebアプリを作れるようになります。exif, id3等でのJavaScriptインジェクション、SQLインジェクションにも当然注意してください。

追記2: バグっぽいと勘違いしたのはPHPのじゃなくてスクリプトのバグでした。バグ以外に古いほうのスクリプトを貼っていたようなので直しました。実行結果は変わりません。