kses.phpの日本語不具合

[miya]

meに添付されているwp-includes/kses.phpに不具合があり、altタグに「業務」とか「業界」など「業」をつかったテキストが入力
されると、文字化けを起こします。

原因は、
該当ファイルの３６９行目及び４５８行目にある
$string2 = preg_replace('/\xad+/', '', $string2);
が、「業」の後ろの１バイトにマッチしてしまうためです。

いろいろ調べたのですが、
これはOperaの仕様に対応するための処置のようですが、詳細は不明です。

弊社で、いくつかの顧客に該当箇所をコメントアウトした状態で納入しましたが、特に問題は指摘されていませんので、コメントアウトしたほうがいい気がす
るのですが、どうでしょう？

ちなみに、preg_replaceをmb系の関数に置き換えても問題は改善しませんでした。

参考までに、kses.phpの開発元には、以下のような記述があります。
- For some reason, the Opera developers decided to make chr(173) a
whitespace
character in URL protocols, both when it occurs raw and in an
entity. kses
now handles this.

http://sourceforge.net/project/shownotes.php?release_id=187629&group_id=81853

[Takayuki Miyoshi]

miya さん、

状況がよく理解できなかったんですが、ご指摘の問題はどういう手順で再現させられるのか詳しく教えてもらえますか。altタグ、とありましたが、これは何のタグのことでしょうか。alt 属性のことかと推測して試しに<img> の alt に「業務」と入れてみましたが特に問題は見られなかったので...

miyoshi

08/02/03 に miya <mi...@theta.ne.jp> さんは書きました:

[tenpura]

miya さん、こんにちは。

確かに

$string2 = preg_replace('/\xad+/', '', $string2);

はUTF-8の「業」にマッチして破壊するようです。
このコードは trunk にも残ってますね。
どうしたものか・・・

tenpura

[miya]

Miyoshiさん、tenpuraさんはじめまして。

alt属性の間違いでしたね。（笑）

tenpuraさんのおっしゃるとおり、UTF-8の「業」にマッチしてしまうのですが、再現させるのにコツ？がいるようです。
（リッチエディターのON/OFFとか、configの内容とか、新規投稿でうまくいっても編集したらだめだったりとか。。。adminユーザーか否か
も関係あるようです。）
以前にメールのやり取りでtaiさんのほうでも再現したみたいなので、不具合があるのは確かなのですが。。。

この不具合は、本家のMUのほうのフォーラムで、いくつか指摘があるのですが、「kses.phpの不具合はkses.phpのプロジェクトのほうでど
うにかしてもらって」みたいなリアクションなので、WordPress本家のほうでは修正しないと思います。

私もコアは触りたくなかったのですが、
この部分だけは直接修正しています。

コアを触れないということであれば、プラグインで、
global $wp_filter;
unset($wp_filter['the_content']);
見たいな感じで、エントリーに適用されるフィルタープラグインを取り除いて、日本語にあわせてゴリゴリ書き直すという手もありますが、大変そうなので私
は断念しました。

[tai]

> 以前にメールのやり取りでtaiさんのほうでも再現したみたいなので、不具合があるのは確かなのですが。。。

うーむ、今回は再現しませんでした。
再現状況がはっきりするまでスルーでいいんじゃないでしょうか。

--
Tai
tek...@gmail.com
http://tekapo.com/

[Takayuki Miyoshi]

手元で再現できました。kses のフィルタだから管理者ユーザにはもともと適用されてないわけですね。忘れてた。

再現手順:
1) Author 以下の権限でユーザを作成
2) そのユーザで新規投稿、<img src="xxx" alt="業界" /> みたいなことを書いて保存

ビジュアルエディタは有効無効に関係なく再現できるみたいです。

これはたしかにけっこう問題ですね。

そもそも、Opera はなんでこんなこと要求するの? てのが疑問なんですが...。そこがわかれば根本的な対処も取れると思うんですが。

場当たり的には、クライアントが Opera ではないときには\xad の除去をさせないようにする、という手が一番シンプルかと思います。

miyoshi

08/02/03 に tai <tek...@gmail.com> さんは書きました:

[miya]

よかった。（よくはないか。。。）
私の手元でもなかなか再現しなくて、どうしようかと思いました。（笑）

> そもそも、Opera はなんでこんなこと要求するの? てのが疑問なんですが...。そこがわかれば根本的な対処も取れると思うんですが。
>
> 場当たり的には、クライアントが Opera ではないときには\xad の除去をさせないようにする、という手が一番シンプルかと思います。

operaでも同じ不具合は発生するので、上記の方法ではOperaのユーザーには解決しませんでした。
どうせOperaで解決しないなら、男らしく（笑）コメントアウトしてしまうか、
http://www.din.or.jp/~ohzaki/perl.htm#JP_Match
みたいなのをphpで書いて、単独の\xadだけを取り除くかだと思います。

[Takayuki Miyoshi]

そもそも、

参考までに、kses.phpの開発元には、以下のような記述があります。
- For some reason, the Opera developers decided to make chr(173) a
whitespace
 character in URL protocols, both when it occurs raw and in an
entity. kses
 now handles this.

URL protocols とは何の関係もない alt 属性値にまで \xad 除去が適用されているということに問題があるような気がする。URL だけに適用されるならかなり害は少なくなってるはずですよね。

日本語ドメインとか、やっぱり影響受けちゃいますけど。あれ? てことは Opera で日本語ドメインの URL 開けないってことなのか? なんか変だ。

miyoshi
 

08/02/03 に miya <mi...@theta.ne.jp> さんは書きました:

[Takayuki Miyoshi]

てことは Opera で日本語ドメインの URL 開けないってことなのか?

そんなことはない。Opera 9.25 で「営業.jp」は開けました。

08/02/04 に Takayuki Miyoshi <takayu...@gmail.com> さんは書きました:

[miya]

Operaが、POSTやGETで渡されたデータから、\xadを除去しないといけない仕様なら、ほとんどのWEBシステムは問題が出ているはずなの
で、私はOperaの日本語版には関係ない仕様ではないかと勝手に解釈しています。

普通のメールフォームとかで、

string2 = preg_replace('/\xad+/', '', $string2);

なんてことしてないですよね。

もうひとつ考えられるのは
ContentEditableかdesignmode内のコンテンツに、Operaは、\xadをいれちゃう仕様ではないかと。

でも問題箇所をコメントアウトして試しても、特に不具合は見つかりませんでした。

そもそも、adminユーザーには適用されないフィルターなので、これだけならコメントアウトしても問題ないと解釈してもいいのではないでしょうか？

[Takayuki Miyoshi]

確かにそのとおりで、kses フィルタで \xad 除去をやる必然性もないように思いますし、\xad 除去を除去しても実害はなさそうですね。

ただ、\xad 除去のコメントアウトを WordPress 日本語版に取り込む、というのはあまり適切な対応とも思えないので(日本語に限った話じゃないですから)、やるなら筋どおり、本家のコードに取り込んでもらうよう働きかけるべきだろうと思います。

で、そうはいっても理由があって入れられていたはずの \xad 除去を止める、となるとそれなりに理由付けが必要ですし、うまい話の持って行き方を考えておかないと、あっさりスルーされるかも知れません。

調べることも多いですし、僕としてはこの件少し時間をかけて考えてみたいと思ってます。

本家 Trac にバグとして報告して修正してもらう、という方向で、いかがでしょうか?

08/02/04 に miya <mi...@theta.ne.jp> さんは書きました:

[tenpura]

妥当な対応だと思います。

tenpura

[miya]

私もOKです。

ちなみに
if (function_exists('mb_ereg_replace')) {
$string = mb_ereg_replace('\xad+', '', $string); # deals with Opera
"feature"
}else{
$string = preg_replace('/\xad+/', '', $string); # deals with Opera
"feature"
}
としても、UTF-8で同様の現象になるのはPHPのバグといえるんですかね。
仕様なんでしょうか？
マルチバイトに対応してないじゃんって思ったんですけど。

[tai]

いいと思います。
よろしくお願いします。

2008/2/4 Takayuki Miyoshi <takayu...@gmail.com>:

> 確かにそのとおりで、kses フィルタで \xad 除去をやる必然性もないように思いますし、\xad 除去を除去しても実害はなさそうですね。
>
> ただ、\xad 除去のコメントアウトを WordPress
> 日本語版に取り込む、というのはあまり適切な対応とも思えないので(日本語に限った話じゃないですから)、やるなら筋どおり、本家のコードに取り込んでもらうよう働きかけるべきだろうと思います。
>
> で、そうはいっても理由があって入れられていたはずの \xad
> 除去を止める、となるとそれなりに理由付けが必要ですし、うまい話の持って行き方を考えておかないと、あっさりスルーされるかも知れません。
>
> 調べることも多いですし、僕としてはこの件少し時間をかけて考えてみたいと思ってます。
>
> 本家 Trac にバグとして報告して修正してもらう、という方向で、いかがでしょうか?
>

--
Tai
tek...@gmail.com
http://tekapo.com/

[Takayuki Miyoshi]

少し調べてみて今のところわかってきているのは:

* \xad とは
  * ソフトハイフン (soft-hyphen)
  * 長い英単語が改行で分割されるときのハイフン挿入ポイントを示す特殊文字
  * \xad (Latin-1 符号)
  * U+00AD (Unicode コードポイント)
  * \xc2\xad (UTF-8 符号)
  * &shy; (文字実体参照)

* いくつかの古いブラウザ実装にソフトハイフンの処理にからむ脆弱性があった
  * https://bugzilla.mozilla.org/show_bug.cgi?id=267669
  * https://bugzilla.mozilla.org/show_bug.cgi?id=307259
  * http://ha.ckers.org/xss.html#XSS_Null

肝心の kses での \xad 除去について直接関係する情報がまだ見つかっていません。

しかし、

http://sourceforge.net/project/shownotes.php?release_id=187629&group_id=81853

上の changelog と kses の実装を見る感じでは、URL protocol whitelisting を確実に(Operaも含めて)適用するための前処理として \xad 除去をやっているように見え、\xad を除去すること自体はセキュリティのための直接の対処とは考えられていなかったように思えます。

そうするとここでの \xad はソフトハイフンのみを意図していたはずなので、「業」(\xe6\xa5\xad) のような部分として \xad を含む文字への適用はそもそもの想定外だったと考えてよいのだろうと思います。

決定的な情報がないのでなんともいえませんが。

ひとまず、今のところは miya さんにご指摘いただいた下のリンク先の内容をベースに kses.php を修正して、

http://www.din.or.jp/~ohzaki/perl.htm#JP_Match

ソフトハイフンと単独の \xad 以外にはマッチしないようにするのが一番妥当な対処かと、僕は今のところそのように考えています。

どう話をもっていったらいいかまだ考えがないのですが、とりあえずパッチを書いて Trac に上げてみようと思います。

関係のあるチケットをもしご存じでしたら教えてください。

miyoshi

08/02/05 に tai <tek...@gmail.com> さんは書きました:

[tenpura]

Miyoshi さん

> 肝心の kses での \xad 除去について直接関係する情報がまだ見つかっていません。

kses の作者に直接問い合わせるのがてっとり早いのではないでしょうか。

> ソフトハイフンと単独の \xad 以外にはマッチしないようにするのが一番妥当な対処かと、
> 僕は今のところそのように考えています。

そうですね。
そしてもしこれが日本語のみの問題でありかつ可能ならプラグインでの対応でも
良い気がします。

tenpura

----- Original Message -----
From: "Takayuki Miyoshi" <takayu...@gmail.com>
To: <wp-j...@googlegroups.com>

[Takayuki Miyoshi]

tenpura さん、

> 肝心の kses での \xad 除去について直接関係する情報がまだ見つかっていません。

kses の作者に直接問い合わせるのがてっとり早いのではないでしょうか。

それもそうですね。まずその辺りあたってみます。

# でも SourceForge のプロジェクトページ見ても最近全然動きがないみたいで、ML にもスパムしか流れていないのです...... 開発者つかまるかな..

そしてもしこれが日本語のみの問題でありかつ可能ならプラグイン

での対応でも
良い気がします。

その線も考えておいた方がいいかもしれませんね。kses の関数相当のものを用意してデフォルトのフック関数をそっちに置き換える、という手が使えると思います。

miyoshi

08/02/09 に tenpura <210...@gmail.com> さんは書きました:

[Takayuki Miyoshi]

遅くなりました。

この問題への直接の対処にはなってないのですが、kses のコードを見ていたらもっと根本的な問題を見つけたのでそれのパッチを書いて送っています。

http://trac.wordpress.org/ticket/5917

bad protocol のチェック(\xad除去もその中で行っています)がすべての属性値に適用されていたので、それを URI タイプの属性に限定するようにするものです。

これの適用により、<img alt=""> に「業務」と書いても通るようになります。

取り込んでくれるかどうか微妙ですが、ダメならまたその時考えるということで。

miyoshi

08/02/09 に Takayuki Miyoshi <takayu...@gmail.com> さんは書きました:

[tenpura]

miyoshi さん

英語でも問題が起るんですね。
これは直されるべきでしょう。

[tai]

ありがとうございます。

ところで、Yurikoさんも同じ問題に悩まされたようです。
http://www.yuriko.net/arc/2008/02/04a

# Miyoshiさんのチケットの件でコメントしたんですが、なぜか反映さない。
# スパム扱いされたのかしらんorz

2008/2/19 Takayuki Miyoshi <takayu...@gmail.com>:

> 遅くなりました。
>
> この問題への直接の対処にはなってないのですが、kses のコードを見ていたらもっと根本的な問題を見つけたのでそれのパッチを書いて送っています。
>
> http://trac.wordpress.org/ticket/5917
>
> bad protocol のチェック(\xad除去もその中で行っています)がすべての属性値に適用されていたので、それを URI
> タイプの属性に限定するようにするものです。
>
> これの適用により、<img alt=""> に「業務」と書いても通るようになります。
>
> 取り込んでくれるかどうか微妙ですが、ダメならまたその時考えるということで。
>
> miyoshi
>

--
Tai
tek...@gmail.com
http://tekapo.com/

[miya]

ご無沙汰してしまいました。

なるほど、miyoshiさんのパッチをみると問題箇所を単純に削除するのは乱暴すぎるような気がしますね。
勉強になりました。

On 2月19日, 午後10:53, tai <tek...@gmail.com> wrote:
> ありがとうございます。
>
> ところで、Yurikoさんも同じ問題に悩まされたようです。http://www.yuriko.net/arc/2008/02/04a
>
> # Miyoshiさんのチケットの件でコメントしたんですが、なぜか反映さない。
> # スパム扱いされたのかしらんorz
>

> 2008/2/19 Takayuki Miyoshi <takayukis...@gmail.com>: