カテゴリー: PHP

PHPの文字エンコーディングの入力チェックを改善する方法について日本語のブログで議論があり、そのパッチを本家に提案したが、却下された、という話が盛り上がっているようです。

バグレポートされた岩本さん自身や、コメント欄やはてなブックマークでは、

• PHPの開発陣がダメだ
• マルチバイトに理解がない外国人がダメだ
• 残念だ

みたいな意見があまりに大勢をしめているので、そのバグレポートを見てみた上で、思ったことを述べたいと思います。

岩本さんのバグレポートを訳すと、こんな感じです

要約:
------------
セキュリティ的な要件により、htmlspecialchars()はバイト列をもっと
厳密にチェックすべきです。XSSするコードが見つかりました。
http://d.hatena.ne.jp/t_komura/20091004/1254665511 [日]

原始的なパッチを書きました。
http://iwamot.com/misc/html.c.patch.20091006
使えるかどうか知りませんが(笑)

再現コード:
---------------
// 越長 UTF-8 列
echo htmlspecialchars("A\xC0\xAF&",     ENT_QUOTES, 'UTF-8');
// 不正な Shift_JIS 列
echo htmlspecialchars("B\x80&",         ENT_QUOTES, 'Shift_JIS');
echo htmlspecialchars("C\x81\x7f&",     ENT_QUOTES, 'Shift_JIS');
// 不正な EUC-JP 列
echo htmlspecialchars("D\x80&",         ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("E\xA1\xFF&",     ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("F\x8E\xFF&",     ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("G\x8F\xA1\xFF&", ENT_QUOTES, 'EUC-JP');

予期する結果:
----------------
何も出てこないこと

実際の結果:
--------------
A_&B_&C&D_&E__&F__&G___&
("_"は不正なバイトを意味します)

もしあなたが日本語でオープンソースのプロジェクトをやってて、他にも毎日バグレポートを受けているような状態で、こんな感じのバグレポートが来て、「問題の詳細はこのURL、アラビア語ですけど」みたいに書かれていたとして、この問題について調査を始めたり、優先してこの問題に取り掛かったりするでしょうか? 僕ならしないと思います。

ましてや、”I don’t know whether it is useful though :)” 「使えるかどうか知りませんが(笑)」ですよ? こういうのは日本的な謙譲の美徳として日本のコミュニティでは通じても(どこでも通じるかはわかりませんが)、およそ真剣に「この問題について知ってほしい、興味を持ってほしい」という態度とは受け取られないと思います。

それまで、複数のブログでいろいろな人がしっかりした問題点の検証や議論を、かなりの長文の日本語でされていて、日本語でそれらを読んでいる人にとっては問題は自明なのかもしれません。

しかし、PHPの開発は英語でコミュニケーションされてますし、彼らが英語で上のバグレポートに出てくる断片からウェブを検索したとしても、日本語での議論のようなまとまった情報は見つからないかもしれません。

日本語で議論されている皆さんの努力にはとても敬意を払っていますが、最終的な問題がPHP本体を直すことにあるのであれば、英語に持っていって相手を説得するときに尻すぼみになっているのは残念です。

僕も英語でバグレポートするのは大変ですし、岩本さんのレポートも、パッチもあるし問題の背景が共有されているなら十分だとは思いますが、何が問題で、直さないとどういう問題が起こるか、起こったとして被害の大きさはどれぐらいか、修正がこれまでの他アプリにどんな副作用を起こしうるか(あるいは起こさないか)、といったことを書かないと、むしろ取り合わないのが普通じゃないかと思います。

はてなブックマークのコメントで書いたところ、岩本さんからこう追記をいただきました。

id:AKIMOTOさんに限らず、私のレポートの仕方が悪かったせいだと思われる方、ぜひ本件を引き継いでいただけないでしょうか。私の望みは htmlspecialchars の文字エンコーディング妥当性チェックが改善されることであって、どなたかが達成されるのであれば、それで万々歳です。採用されるレポートの書き方もそれで分かるでしょうし。

他人の英語について何かコメントしたら、こういう返しをされるだろうな、というのはわかっていました。

しかし、それぞれの人はそれぞれの優先順位があります。この問題が無視できる問題だ、とは僕は思いませんが、僕自身がこの先解こうとしている他の問題に比べれば、自分で引き継ぐほど差し迫った不利益を受けていませんし、また、議論されているみなさんほど、この問題について精通してもいません。英語が書けるというだけで、誰もが替われるような話ではないでしょう。少なくとも僕にはこの件の翻訳ボランティアになる動機がありません。

ただ、それが「自分に取って優先順位の高い問題で、どうしても通したい」ときにどうしてるか、は紹介できるかと思います。

ちょうど昨日、僕も一本のバグレポートを書きました。主な興味の対象のレイヤーが違うのですが、PHPのメールライブラリSwift Mailerのバージョン4に関するもので、日本独自仕様の提案に関係するものです。

具体的には、NTT Docomoなどが過去に間違って導入した、RFC違反の形式でピリオドを持つメールアドレスを受け付ける特別なモードを導入してほしい、というものです。

PHPとSwift Mailerではレイヤーも規模も、何もかも違いますが、

– 何が問題なのか
– その問題に他のアプリケーションはどう対処しているのか
– mail addressの場合、iPhoneやGmailが日本市場向けに何をしているか書きました
– 文字エンコーディングの入力チェックの場合、他の言語や処理系でどう扱っているか、というような話になるかと思います
– その変更を採用することで、既存のユーザーに影響するか
– 今回は影響するもの、影響しないものを合わせて複数の取りうる修正案を併記しました

といったことをまとめ、何が問題で、どうしてこんなばかばかしいRFC違反のメールを受け付けられることが日本の一部のユーザーにとって(ひいてはSwift Mailerの日本での普及にとって)大事か、というのを伝えようとしたつもりです。なんといっても、こんな修正日本以外のユーザーには何のメリットもないですからね。

# ちなみにこのレポート書くのに何日もかかってます。英語でブログ書いてるからといって、複雑な内容を一瞬で書けるわけではもちろんないです。

このメールの件は、いわば「悪い仕様を追認する」汚い修正なので、念入りにiPhoneなど他社の対応状況も添えましたが、PHPのエスケープで起こる問題が本当に筋のいいものであれば、これまでの日本語での議論をきっちりまとめて伝えることで、それよりは受け入れやすいのではないかと思います。

英語でバグレポート書くのも大変でしょうし、却下されれば凹みもするでしょうけれど、それを日本語に持ち帰ってきて「残念だ、残念だ」と騒いでも、それは決して相手に伝わらないですよ。

はてブコメントで「残念」と書いている人の中に、そのバグレポートを開いて見てみた人がどれぐらいいるんでしょうか。

「いつもの同じ問題」じゃないとわからせるには、わからせるだけの証拠を積み上げて見せないといけないし、バグレポートで届かないなら、(英語の)ブログを書いたりサイトを立ち上げたり、メーリングリストで問題提起したり、却下した本人にメールしたり、いろいろとあるのではと思います。

この問題で議論されているみなさんの努力、バグレポートまで書かれてチャレンジされた岩本さんの努力には(一PHPユーザーとして)たいへん感謝していますが、努力することが重要なのじゃなくて、どうやって自分(達)の意を通すかが大事ではと思います。それが「PHPのせい」「コアチームのせい」「英語のせい」「外国人のせい」で終わってしまうとしたら、僕はそれが残念です。

# あと、↑途中書いた僕自身のスタンスをよく読まずに「じゃあお前やれば」とコメントしないでくださいね。僕の次のバグレポートは、Swift Mailerでのiso-2022-jpサブジェクト行のエンコード&行分割に関するものになる予定です

[追記 2009.10.09]

徳丸浩さんが、PHPが今すぐ直らないとしても実施できる、このセキュリティホールが起こりうる条件と、その回避法についての解説をまとめられています。

[追記 2009.10.09]

moriyoshiさんが最初のバグレポートをcomitしてくださいました。ありがとうございます。

将来のマイナーアップデートリリースでこの問題は解消されるでしょう。実際に今このセキュリティホールが有効になる条件下のアプリケーションを運用されている方は、個別にパッチをあてたPHPをビルドして差し替えるか、上の徳丸さんの対策を行なう必要はあります。