■

http://support.microsoft.com/kb/940521

去年の.NET Framework 2.0のセキュリティフィックスで、エンコーダ/デコーダで未定義の文字バイトに遭遇した時は、デフォルトではUTF8EncodingもUnicodeEncoding (utf-16)もString.Emptyを置換文字列とする[Encoder|Decoder]ReplacementFallbackを使用していたのを、“\uFFFD”を使用するようになった。つまり、不正な文字が入力中に含まれていた場合は、スキップするのではなくて、REPLACEMENT CHARACTERが代わりに埋め込まれるわけだ。

これは結局セキュリティの問題ということになってしまったわけで、そうなると今度は id:atsushieno:20050406:p2 はセキュリティ問題にはならないのかという疑念が生じてくる。siokoshouさんがid:siokoshou:20050412でマイクロソフト（日本法人かな）に問い合わせてセキュリティ上の問題ではないという回答を得ていたわけだけど¹、実際にはセキュリティ上の問題になると判断した方が妥当なのかもしれないな。国際化ドメインで使用されうる外観上区別が困難な文字列もセキュリティリスクとして評価される時代なわけだし。

コメント

siokoshou — 01/10/2008 15:26:43

なるほど〜、MSのフィックスした問題は.NETからコーデックの違う別のシステムに文字列を渡したときに、そっちでセキュリティの問題が起きる可能性がありますね。多層的な防御ってやつでしょうか。セキュリティは想像力しだいですね…。
〇はどうなんでしょうｗ 外人が〇の意味を勘違いした結果こうなってるんじゃないかと思ってますが(^^;

atsushieno — 01/11/2008 15:31:11

〇については、意味を勘違いしたということは多分無くて、そもそも照合のためのデータが存在していなかった（たぶんUnicodeのUCDの古いバージョンに無かった）ものについては「無視する」と決めたためではないかと思います。

外観、と書いたのはちょっと話を狭くしてしまったかもしれません。不明な文字が単に無視されると、機械的に照合する時にも「問題」になりえますね。その「問題」をどう理解するかがセキュリティリスクの評価に関わってくるのですけど。何を以てセキュリティリスクと評価するか、真面目に考えるといろいろ（いい意味で）足跡がたくさんついた論争のありそうな問題なので、その評価はひとまず保留しますw

ちなみに、エンコーディング変換が具体的なセキュリティリスクを引き起こす事例があると評価されても、文字列照合では具体的なセキュリティリスクが存在しなかった、といった基準で、一貫性のある判断をMicrosoftが示すことは、なおもあり得るとは思っています。

siokoshou — 01/15/2008 13:48:46

〇って古いバージョンには無かったんですか。てっきり、ゼロだけに無視していいと勘違いされてしまったのかと思ってました(^^;
(遅レス失礼しました)