水無月ばけらのえび日記

＞\73CRIPT の後ろにスペースをひとつ入れて「\73 CRIPT」としても

こんにちは、スターダストです。\の後ろにスペースをひとついれると、スタイル属性の中では「\ 73script」になり、危険な文字列ではなくなります。つい最近まで、このフィルタリングによって、hotmailにはXSS脆弱性がないものとされていました。しかし、その後、スタイル要素の中では、\の後ろにスペースを二ついれないと、危険な文字列を抹消できないことがわかりました。バックスラッシュによるエスケープは、Hotmailでは全面禁止となっておりまして、unicode表現やら他にも制限が出てきています。マルチバイトな文字を使う国々にとっては、ときどきツライのかもしれません。

ばけらさんからメールを頂戴しておりますので、適切な形ではてなの日記の修正を入れたく思います。ありがとうございました。

　どうもです。

　本筋と関係ない細かいところなので恐縮でしたが、訂正していただいたようで……ありがとうございます。

>しかし、その後、スタイル要素の中では、\の後ろにスペースを二ついれないと、危険な文字列を抹消できないことがわかりました。

　この話、興味深いです。

　ちょっと分からないのですが、どうしてスペース一つだとまずいのでしょうか？

送信者がHotmail受信者に

<style>

h1 {

co\lor: red;

text-a\lign: center;

}

</style>

<h1>見出し</h1>

を送信すれば、Hotmailが、XSS対策の為に

'\' が、'\*'（*は空白)となるようにフィルターしても

<style>

h1 {

co\*lor: red;

text-a\*lign: center;

}

</style>

<h1>見出し</h1>

と受信されます。

これでは、赤い字のh1要素がcenterに位置づけられます。

（WinIEではそうでした。）

バックスラッシュの後のスペース文字が、どういうわけだか

無視されます。\32* の*が無視されるといいますか、

それは当然なのですが、なぜに\* の*は無視されるのでしょう。

仕様を真剣に読んでもわかりませんでした。

ひとつめの案　/に続くスペースはスペースだよと、\は主張します。

これだと、 co*lor: red; で、文字色が赤くなるはずです。変。

ふたつめの案 /2桁か6桁の16進数に空白 を処理したかったけど

16進数がみつからず、とりあえず放置。その後、空白がひとつある

のをみつけて、普段どおり、処置。ただの空白削除？になりさがる？

機械の気持ちはわかりませんが、上のふたつめなら、

私には変だと思いつつ記憶することが出来ました。

さて、危険な文字列が、importだとします。

送信者は、impo\rt と綴ります。

すると、hotmailは、これを、危険な文字列、

importだと思いません。いつもなら取り除くくせに

バックスラッシュ１個で、フィルターを通過します。

hotmailは空白を一個つけるだけです。

空白を*とすると

受信者は、

impo\*rt

を受け取りますが、IEは、この姿を見て

importだと解釈します。

空白1個削除するバックスラッシュ説ですが。

これで、XSS脆弱性が発現します。

仮に、Hotmailが、空白２個をバックスラッシュの

後に付加するならば、安全となります。

受信者は、

impo\**rt

をもらいますので

IEは、これを

impo*rtとみなし、スタイルシートの仕様に従い

無視します。

というわけです。

申し遅れました。現時点では、

Hotmailにおいてはworkaroundにて

\は\**と変換されています。

この後、さらに良いものになるかについては

不明です。

>これでは、赤い字のh1要素がcenterに位置づけられます。

>（WinIEではそうでした。）

>バックスラッシュの後のスペース文字が、どういうわけだか

>無視されます。

　むほっ、本当だ……。

http://altba.com/bakera/bug/backslash-space-test.html

>仕様を真剣に読んでもわかりませんでした。

　私にも分かりません。これは CSS 仕様の想定する挙動ではなく、MSIE が独自に気を利かせちゃっているのではないかと思います。

　@i も !i もこれもそうなんですが、余計なところで余計な気を利かせると前方互換性的にもセキュリティ的にもマズいですね。

　他にも気を利かせている例がありそうな気がしますが……。

>　私にも分かりません。これは CSS 仕様の想定する挙動ではなく、MSIE が独自に気を利かせちゃっているのではないかと思います。

　……と書いてから思い直したのですが、ひょっとするとバグなのかも知れません。以下はあくまで私が想像したシナリオですが……。

　バックスラッシュの後ろに 16進数の数値を書くというエスケープの方法があるのですが、それが MSIE の場合

"\[0-9]+ "

　ではなく

"\[0-9]* "

　にマッチするモノに対して処理されているのかもしれません。

　そうだとすると、\ の後ろに数字が無くてスペースが来る場合も (誤って) このパターンにマッチしてしまい \HH のエスケープとみなされます。数字部分は空ですがこれは 0 とみなされて、NUL 文字に展開されます。

　CSS2 では \HH エスケープに続く後ろの空白ひとつが削除される仕様ですから後ろのスペースひとつが削除されて NUL 文字だけとなり、NUL は消滅すると……。

<style>

h1 {

co\0 lor: red;

}

h2 {

co\00 lor: red;

}

h3 {

co\000 lor: red;

}

h4 {

co\0000 lor: red;

}

h5 {

co\00000 lor: red;

}

h6 {

co\000000 lor: red;

}

div {

co\ lor: red;

}

</style>

<h1>h1</h1>

<h2>h2</h2>

<h3>h3</h3>

<h4>h4</h4>

<h5>h5</h5>

<h6>h6</h6>

<div>div</div>

ばけらさんの正規表現を、ちょっと図解してみました。なっていませんが。

ブラウザの CSS が正しく実装されているならばdiv要素はブラウザの既定のスタイルで表示される、と考えてよろしいでしょうか。IEならば黒。h2要素とh6要素で赤くなるの正しいと直感的に思います。その他は、不勉強な私には不明です。

　すみません、私が出した正規表現に語弊があったようで申し訳ないです。

　16進エスケープの表現は仕様で正確に定められていまして、

\\[0-9a-f]{1,6}[ \n\r\t\f]?

　です。これは CSS2 の 4.1.1 に出ています。

　1桁から 6桁までの任意の数字が OK なのです。

#先の私の正規表現は出鱈目です。申し訳ないです。

　で、例によってテストを作ってみました。

http://altba.com/bakera/bug/zero-escape-test.html

　最後の二つは 7桁、0桁で不正なケースです。これら二つは黒背景・白文字になっては駄目です。

　……ただ、他の例についても NUL が無視されるという挙動は正しいのでしょうか？ Mozilla 系でもやっぱり \0 は無視されてスタイルが適用されているようですが……。

　NUL の扱いの規定って見た覚えがないので規定されていないような気がするのですが、調べてみます。

>　……ただ、他の例についても NUL が無視されるという挙動は正しいのでしょうか？ Mozilla 系でもやっぱり \0 は無視されてスタイルが適用されているようですが……。

Opera7.2だと、どれもスタイル適用されないですね。

なるほど、、、スタイル属性の中では、過去に検証したことがあります。

http://d.hatena.ne.jp/hoshikuzu/20030924

私の記憶では、crip\t が、Operaでも、Netscapeでも、IEでも通用してしまっていました。９月頃の最新で試したはずです。

書き込んでスグニ関連のない話題だと気がつきました。間違い。すみません。あわてもの。

ばけらさんのテストスイートを私の日記で参照させていただきました。ありがとうございます。

http://d.hatena.ne.jp/hoshikuzu/20031213#p4

IEだけがバギーと考えてもよろしいでしょうか。

>書き込んでスグニ関連のない話題だと気がつきました。間違い。すみません。あわてもの。

　関係ないつながりで関係ない話を書いてみますが、16日の日記について。

http://d.hatena.ne.jp/hoshikuzu/20031216#p4

>ふと、思いますが、”で囲わなくても良し、というのは、IEでは、いつからなのでしょう。これって困るんですけど。フィルターにとって。まじめなフィルターであればあるほど、CSSの部分をしっかり仕様にあわせて構文解析するはずです。仕様をあてにしてサニタイズするとダメですか？

　これですが、実は仕様自体が結構複雑でして、url() の中身となる場合は引用符で囲まなくて良いことになっています。CSS1 で最初に出てくる @import の例でも囲まれていません。

http://www.w3.org/TR/REC-CSS1#the-cascade

　また、url() 関数を使わないで文字列を直で書くこともできることになっていますが、その場合は「キーワード」ではなく「文字列」を書かなければならないので、引用符で囲む必要があります。結論としては、@import の書き方には

@import url("……")

@import url(……)

@import "……"

　の 3種があることになります。いちおう

@import ……

　という書き方は駄目なはずで、これについては IE が気を利かせすぎという話になると思います。

　また、二重引用符ではなく単引用符でも OK ですし、さらに後ろにメディアタイプ指定がついてくるパターンも存在します。

　@import の書式については、CSS2 のこの辺りが詳しいです。

http://www.w3.org/TR/CSS21/cascade.html#at-import

　余談ですが、仕様的には

color: red;

　を

color: "red"

　と書いては駄目ということになっています。しかしこれは昔の IE では気を利かせて red と同一視していました (私の記憶が確かなら)。

　これは IE6 の標準モードでは正しく無視されるという挙動になったのですが、互換モードだとやっぱり気を利かせて red と同一視します。

　こんなふうに標準モードと互換モードで挙動が違うという話もあったりするので、もうとにかく厄介です。

>　こんなふうに標準モードと互換モードで挙動が違うという話もあったりするので、もうとにかく厄介です。

IEだけじゃなくて、MozillaやOperaもそうですね。

って話の流れ上はIEだけが問題なのかな。

よくわかりませんが脊髄で書いてみました【謎】。

丁寧な解説をありがとうございます。color: "red"　などは、してしまうかもしれません。仕様通りに書かれていないスタイルは無視してくれるのが一番ありがたいのですけれど、、ブラウザ。@m など、あえて実装しているのなら公開文書が目につくところにないとセキュリティー対策上、困りますね。もっとも、目に付くところだと恥ずかしいかもしれません。

>IEだけじゃなくて、MozillaやOperaもそうですね。

　そうでしたっけ。

　じゃあ Moziila や Opera もということで。

　要するに、

・仕様にない記述でも通ってしまうということ

・そのことがドキュメントされていないこと

　が問題なわけですが、これはなにも IE に限った話ではないと思います。

>>IEだけじゃなくて、MozillaやOperaもそうですね。

>

>　そうでしたっけ。

"red" を red に補完するのは、無いですが、

co\00 lor とかのやつは、IE と Mozilla はほとんど同じ結果では。

Opera には一切効果ありませんでしたが。

KAMADAさんのところでものすごい例が続々報告されていますが、

http://homepage2.nifty.com/m_kamada/di200312.htm#19_04

>　IE6ではスタイルシート内に「<!--」や「-->」がいくつあっても閉じていなくても構いません。HTMLファイルの<style>要素だけでなく、CSSファイル内でも「<!--」がルールの区切りとして機能します。

これだけは(「@i」を置いておけば)CSSの仕様上ヘンな振る舞いとは言い切れませんね。

何か訂正が入ってるので少々補足。

>　IE6ではスタイルシート内に「<!--」や「-->」がいくつあっても閉じていなくても構いません。HTMLファイルの<style>要素だけでなく、CSSファイル内でも「<!--」がルールの区切りとして機能します。

まずこれ自体は100%正当な振る舞いです。CSSの「<!--」や「-->」はコメントのように見えるかもしれませんが、HTMLのコメントとはまったく関係ありません。ルールとルールの間には、空白とまったく同じように、どんな順番でいくつ現れてもかまいませんし、<style>要素内でも独立したCSSファイル内でもまったく関係ありません。

ではどのあたりが「仕様上ヘンな振る舞いとは言い切れない」とかいう自信なさげな【謎】表現につながったのかというと、サンプルの「-->」を空白に置き換えるとIEでも認識されなくなったからです。CSS2では4.2で定めている以外のエラー処理は定義されていないため、

http://www.w3.org/TR/REC-CSS2/conform.html#q3

「a」というrulesetともat-ruleとも解釈できない謎のtokenが出現したときにその部分だけ無視するか全体を無視するかはUA任せではあるのですが、それを言い出すといくつかのサンプルはそもそもエラーなのだからどういう解釈をしようがIEの勝手ということになりますし【謎】セキュリティ上は全体を無視するように振る舞うのが望ましいでしょう。サニタイザー【謎】的には、CSS core syntaxを通らない記述が含まれていたら全部弾く必要があるわけです。

> <style>要素内でも独立したCSSファイル内でもまったく関係ありません。

これはSGMLベースのHTMLの場合の話で、XHTMLのstyle要素内ではまずコメントとしての処理を行ってから、CSSパーサに渡されなくてはなりませんが、CSSファイル内にどんな順番にいくつでも書けるという点に変わりはありません。