文字のセキュリティー

文字のセキュリティー

[13] 文字なんてただ並んでいるだけのようにも思えますが、 セキュリティー上のリスクがあちこちに潜んでいます。

識別子における文字

[1] URL を構成する文字は、セキュリティー問題につながる場合があります。 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 の問題)。

[6] 零幅文字は、透明なだけでなく表示領域すら見えないもので、 ますます危険です。

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

[3] これらは電子透かし的に文章に混入させ悪用されることがあります。

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

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

[26] 関連: 識別子文字, URL安全, ファイル名安全

空白

[2] 空白文字参照。

エスケープ、引用、終端

[9] 厳密に言えば文字自体に起因するセキュリティー問題ではありませんが、 文字を使って記述される構文 (データ形式プロトコル要素など) の構造に含まれるべき文字は適切に扱わなければ、 深刻な問題に発展し得ます。

[10] よく問題を起こす文字というものもあります。 エスケープ, 文字参照, SQLインジェクション, XSS, ", ', NULL

[11] 文字符号化文字を使って記述される構文の相互作用による問題もあります。 円問題, 表\示, ダメ文字

不正入力

[7] 不正な入力バイトや入力文字を、不正だからといってただ削除すると、 セキュリティーの問題となる場合もあります。 復号非文字

[12] 文字を使って記述される構文 (>>9) による問題とも関係します。

[8] 非文字に特定の意味を与えていると、 外部から不正に非文字を与えられて誤動作することがあります。

不可視文字

[19] まったく、または一見、表示されない文字の混入により、セキュリティープライバシーが脅かされることがあります。

[23] ZWJ, ZWNJ, 異体選択子など

[24] 文字入力が必須とされるときに、不可視の文字によって見かけ上制限を回避できることがあります。

[25] 電子透かし的埋め込みなど利用者を不正に追跡する目的で使われることがあります。 この場合、不可視の文字だけでなく、字形の似た文字も悪用されることがあります。

[5] 歌詞表示サービスGenius、同社のコンテンツを無断使用したGoogleを提訴 | スラド IT () https://it.srad.jp/story/19/12/06/2239229/

WSJの報道で証拠とされたのは、Geniusが一部の曲の歌詞でアポストロフィー「'」の一部を右シングルクォーテーションマーク「’」に置き換えた「ウォーターマーク#1」によるものだ。「'」をモールス符号の短点、「’」を長点に置き換えると「red handed」と読めるようになっているが、このウォーターマークをそのまま含む歌詞がGoogleの検索結果に表示されていたという。

WSJの報道後、Googleの検索結果にはウォーターマークが除去されたバージョンが表示されるようになったが、証拠隠滅を疑ったGeniusは8月にスペースの(U+0020)一部をfour-per-em -space(U+2005)に置き換えたウォーターマーク#2の埋め込みを開始したそうだ。

[18] 「テキストの内容と句読点を変更する」という新たな電子透かし技術が開発される | スラド YRO, https://yro.srad.jp/story/13/06/21/0358257/


[21] これは似てるけどグリフデータレベルで使った事例。

[20] 日立が紙文書の文字の中に情報を埋め込む技術を開発 | スラド, https://srad.jp/story/03/10/06/066209/

[22] HITACHI : ニュースリリース : 紙に印刷された情報の追跡を可能にする、透かし強度を調節可能な二値画像電子透かし技術を開発, hitachi, ltd., , https://www.hitachi.co.jp/New/cnews/031003.html

レンダリング

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

構造や状態

[14] 文字の中には、複数のビット組合せ符号位置の組み合わせによって機能を実現するものがあります。

[15] 入力はその正当な構文に従ったものとは限りません。異常な入力であっても、 危険な動作は避けなければなりません。

結合文字, IDS, paired stateful controls, 文字のレンダリング, 制御機能

文字符号化

ISO/IEC 2022, UTF-8, サロゲートペア

メモ