文字のセキュリティー

文字のセキュリティー

識別子における文字

[1] URL を構成する文字は、セキュリティー問題につながる場合があります。

[117] 似た形の文字: Unicode には図形記号が似た文字(列)が極めて多く含まれています。 紛らわしくて困るというだけなら (それだけでも大問題ですが) まだしも、なりすましなどの安全上の問題にもなります。

[186] かつての RFC 3987 の仕様ではできるだけ NFCNFKC を使うことを勧めていましたが、従来の文字符号化方式との関係 (RFC 3987 は従来の文字符号化方式で IRI が記述されていたら NFC に変換することを求めていますが、 RFC 3987 の対象外の世界で従来の文字符号化方式から UTF-8 などに変換済みなら NFC でないかもしれません。 IRI を作る側も、ファイル名など NFC でない因子を持っているかもしれません。) や悪意のある者が必ずしもそれに従うとは限りません。

[187] 見えない文字: Unicode には図形記号を持たない文字が多く含まれています。 例えば U+3000 (IDEOGRAPHIC SPACE) も IRI で使えます。 IRI のような文字列があった時にどこで終わるのかわからないので不便ですし、 IDSPEMSPENSP が2つ並んでいるものは区別できなかったりします (>>117 の問題)。

[188] 単に見えないだけではなく、何らかの意味を持った文字もあります。 PARAGRAPH SEPARATOR は段落境界を意味します。 IRI の途中で改段落などされると甚だ迷惑ではあるのですが、 仕様上は認められているようです。 悪意のある人は悪いことに使うかもしれません。

[189] 双方向性: かつての RFC 3987 には bidi に関する規定がありました。 要約すると、 Unicode の bidi 算法をそのまま使うというものです。 最近の色々な規格 (例えば CSS) は全面的に Unicode の bidi 算法を採用しているので IRI の部分だけ他の算法を採用するというのは非現実的ではありますが、 Unicode の bidi 算法は普通の文章を主に想定しているので、 記号を普通の文章とは違う特別な意味で使っている IRI では予期せぬことが起こります (RFC 3987//6 にわずかながら例があります)。

[190] 1つのアドレスの途中で直感とは異なる形で表示上の場所が入れ替わるのは実用上も大きな問題ですが、 なりすましなどの保安上の問題もかかえています。

空白

[2] 空白文字参照。

零幅文字

[3] 零幅文字参照。

レンダリング

[4] 文字のレンダリングに複雑な規則が適用される場合、 レンダリングの実装に深刻な不具合があり、 文字列レンダリングさせるだけで特定の実装をクラッシュさせるなどのセキュリティー上の問題を引き起こせる事例が知られています。