何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
第7回 Unicodeからの多対一の変換［前編］ | gihyo.jp
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです）、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
アポストロフィの悩み | Okumura's Blog
何でもいいから英語の単語に「痴」を付けてGoogleで検索してみる。例えば「he痴」でもいい。うまく見つからなければ，例えば Shakespeare痴 Got A Gun を見てみる。英語のサイトなのに何でこう「痴」が多いのか（うまく「痴」に見えないなら，ブラウザのデフォルトのエンコーディングをシフトJISにしてみてください）。 答え：Windows-1252（CP1252）のアポストロフィは 0x92 であり，これにs（0x73）が付くと 92 73 となり，これはシフトJISで「痴」になる。つまり，「He's」が「He痴」に化けるページはアポストロフィをWindows-1252でエンコーディングし，エンコーディング指定をしていないのでシフトJISで表示してしまったのである。書いた本人はLatin-1（ISO 8859-1）のつもりかもしれない。 アポストロフィは '（0x27）でいいの
Microsoftが総括「Windows Vistaにフォントの混乱なし」 - もじのなまえ
あまり時間がないので短くご報告。 Microsoftの「Windows 7向けJIS90互換フォントパッケージの提供と今後について」記者説明会に行ってきました。これについてはプレスリリースも出ています。 Windows(R) 7 向け JIS90 互換フォントパッケージの提供 より詳しくはINTERNET Watchの記事などをご参照ください。 マイクロソフト、JIS90互換フォントの提供はWindows 7で最後 細部は記事にゆずるとして、ぼくが重要だと思ったことは以下の点です。 Windows Vistaによるフォント変更について、同社コールセンターに対し、クレームの電話は1件もかかってきていない。 Microsoftは（今のところ）この件について、ユーザーに大きな混乱は発生しなかったと考えている。 Windows Vistaでフォント・デザインが変更されたことについては、2006年に
MiAU勉強会の反省 - もじのなまえ
前回のエントリでご案内した第4回 MIAU勉強会ですが、ぶじに終了。その画面資料ですが下記にて公開します。 RFCから見た新常用漢字表の矛盾と整合 以前にも書きましたが、自分の仕事については誉めてくれるより批判的な意見の方がより参考になります。参加者のご意見で最後に発言してくださった方が、文字コードの話の部分と新常用漢字表（仮）の部分とで違和感があるという趣旨の指摘をしてくださいましたが、あらためて画面を見直すと、たしかにそうだなあと。 会場では別の部分でお答えしたのですが、振り返ってみればもっと違う言いようがあった。わざわざ来てくださった直井さんも、後半が飛躍しすぎといっていたけど、おそらく同趣旨のことではないか。 この発表を考えていた際、ずっと思っていたことは、「一部のRFCやXMLで規定されている互換漢字の置き換え処理／使用禁止と、常用漢字表の考え方の間には共通点があるように思えるが
JIS X 0213は改正しないと新常用漢字表に対応できない？ - もじのなまえ
書いておかないと忘れそうなのでメモ。 前日のエントリに対するUnicodeさん、mashabowさんのご指摘について調べるうちに、ハタと気づいたこと。 完全に見落としていたのですが、今までなんとなく「新常用漢字表」の「（付）字体についての解説」の「1 明朝体のデザインについて」は、表外漢字字体表におけるそれと下位互換だと思っでいたのですが、まったくの思い違いでした。 表外漢字字体表の「表外字だけに適用されるデザイン差について」（漢字使用の実態への配慮から、字体の差と考えなくてもよいと判断したもの）で挙げられていたものを、新常用漢字表はまったくふれていません。そもそも新常用漢字表における「1 明朝体のデザインについて」は改定されていません。 表外漢字字体表で挙げられているうち、新常用漢字表の追加字種に関わるものは以下のとおりです。 A 画数の変わらないもの (2) 傾斜・方向に関する例 (3
絵文字が開いてしまった「パンドラの箱」第4回--絵文字が引き起こしたUnicode-MLの“祭り”
普通では考えられない優遇策--「Google提案」を振り返る 皆さんこんにちは、毎度おなじみ（？）文字コード漫談の時間がやってまいりました。前回が3月の掲載ですから3カ月ぶりですか。今まで3回にわたって絵文字をUnicode及びISO/IEC 10646（国際符号化文字集合）に収録しようという提案の動きについてご説明してきましたが、今回から2回に分けて完結編をお届けします。どうぞよろしくお付き合いください。 ひさしぶりですから、ここまでのポイントを整理しておきましょう。前述した「提案」とは、もともとはUnicodeに収録するためにGoogleがAppleと共同で作成したものです。以下、主唱者の名前をとり「Google提案」と呼ぶことにします。これはこの2月に開かれた最高議決機関、UTC会議で承認されてUnicodeコンソーシアムの総意となりました。ついでGoogle提案はISO/IEC 1
二つの顔を持つ神 - もじのなまえ
幸いなことに先週末に掲載した絵文字が開いてしまった「パンドラの箱」第4回は好評をもって迎えられた様子。ブックマークしてくださった方々が、さきほど確認したら360人。これは第1回の693人には及ばないものの、第2回、第3回を上回る数字であり、素直に喜んでいる。 また、ネット上でも拙文に触れてくださる方々が大勢いらっしゃり、折りにふれて楽しく拝見している。こういう場合、書いた本人を触発するという意味では、肯定するよりむしろ批判する文章の方に軍配が上がる（もちろん誉めてくれるのは無条件にうれしいのだけれど）。 「そうか、こういう考え方があったのか」「そういう受け取られ方をしたか」ということです。こうした直言は親しい人や編集者はなかなか言ってくれないことだから、なるべく素直に受け止めたいと思っている。誤解や曲解も含め、あらゆる反応は筆者にとって良い糧になりうる。鰯や秋刀魚のように骨まできれいに食べ
明朝、CNETに絵文字の原稿が掲載 - もじのなまえ
5日の朝6時以降に公開だそうです。 絵文字が開いてしまった「パンドラの箱」第4回--絵文字が引き起こしたUnicode-MLの“祭り" 今回は、絵文字をめぐって勃発したUnicode公式メーリングリストでの議論を紹介します。ここで去年12〜今年2月にかけて1,000通以上のメールが行き交う、絵文字についての大論争が発生したんですね。 たしか3月の京大東洋学セミナーに行った際、早朝のマクドナルドで必死に翻訳をやっていたのがなつかしい（といっても電子翻訳）。あれからもう3ヵ月近くか、原稿書くのが遅いですね……。 今回は前までの倍近い分量なので*1、今まで通り多くの方々に読んでもらえるか心配です。翻訳その他の監修をご快諾いただいた師茂樹さん、直井靖さん、それにCNET翻訳チームに感謝感謝。 この後、WG2ダブリン会議のことを書いて完結。いつ終わるのかなあ。いや、来週には書き終えるぞ！ *1:ちな
第12回■主要言語別：入力値検証の具体例
これまで2回にわたってWebアプリケーションにおける入力値検証とセキュリティ対策の関係を説明してきた。入力値検証はセキュリティ上の根本的対策ではないが，保険的な対策として効果が期待でき，特に制御コードや不正な文字エンコーディングによる攻撃対策には有効であることを説明した。 今回は，Webアプリケーション開発によく使われる4種類の言語（Perl，PHP，Java，ASP.NET）に関して，入力時処理の具体例を示す。ここで取り上げる「入力時処理」とは以下の内容を含んでいる。 文字エンコーディングの検証文字エンコーディングの変換入力値検証 Perlによる実装の方針 Perl言語はバージョン5.8から内部文字エンコーディングとしてUTF-8をサポートし，文字単位での日本語処理が可能だ。文字エンコーディング処理にはEncodeモジュールを使用する。入力値検証には正規表現を用いるのが便利だ。 ■文字エ
第11回■制御文字や不正な文字エンコーディングによるぜい弱性を知ろう
前回，入力値検証をセキュリティ対策として実施すべき理由を説明する中で制御文字や不正な文字エンコーディングの問題を指摘した。今回は，その具体例として「ヌルバイト攻撃」と「冗長なUTF-8によるディレクトリ・トラバーサル」を説明する。 制御文字悪用の代表格「ヌルバイト攻撃」 ヌルバイト攻撃とは，ASCIIコード0の文字（ヌル文字）を用いた攻撃である。リスト1に示すPHPスクリプトは，クエリー文字列pとして数値を受け取り，それを表示するというもの。結果を表示する前に正規表現関数eregを使って数字だけのデータかどうかをチェックし，数字でない場合にはエラーメッセージを表示するようになっている。通常，数字だけを使った攻撃は不可能であり，このような「安全な文字」だけを許可するような検査方法を一般に「ホワイトリスト検査」と呼ぶ。
アルファベットを全角で打つ奴が許せない:アルファルファモザイク
どっちかに統一してもらえれば、特に問題ない。 うちの上司の書類は全半角混入だからイライラする。 ex.aｂcとか\５，000とか・・・
第5回 不正なバイト列の埋め込み | gihyo.jp
今回は、「不正なバイト列の埋め込み」という攻撃方法について紹介します。 文字列を入力とするソフトウェアにはさまざまなものがありますが、それらの処理系によっては、入力として与えた文字列中に、その文字コード上は不正となるようなバイト列を埋め込んでいたときに、それらのバイト列が無視されたり、想定外の文字に変換されてしまうことがあります。 たとえば、とあるソフトウェアにて （1) 処理A ＝ 文字列中に特定の文字（あるいは文字列）が含まれていないか検査 （2) 処理B ＝ 処理Aから受け取ったデータを処理。その際に不正なバイト列が無視あるいは別の文字に変換される という流れになっていた場合、後続の処理にて本来はフィルタリングされるべき文字列が含まれてしまうことになります。 このような流れを引き起こす具体的な例をいくつか紹介します。 Mozilla Firefoxにおける0x80の無視 Mozil
第4回 UTF-8の冗長なエンコード | gihyo.jp
今回は、文字コードに関連するセキュリティの話題では古参ともいえるUTF-8の冗長なエンコードというテーマについて紹介します。 UTF-8とは UTF-8は、各文字を1～4バイトの可変長で表現するUnicodeの符号化方式のひとつです。 U＋0000からU＋007Fの範囲の文字を0x00から0x7Fの1バイトで表現しているため、US-ASCIIと互換性がある、バイト列の途中からでも文字の先頭バイトを簡単に検出できる、多バイト文字の途中に0x00や0x5C（\）、0x2F（/）などが現れない、などの特徴があります。 UTF-8での文字のビットパターンは表1のようになります。 表1 UTF-8でのビットパターン
第9回■上流工程で文字集合仕様と文字エンコーディングを決定する
これらの対策のうち，ここでは「文字集合の変換を伴う変換をしない」など，アプリケーション全体の文字コードの取り扱いについて上流工程で留意すべき内容について説明しよう。「入力値のチェック」については次回以降，「入力値の検証」の項で詳しく説明する。「アプリケーションでの正しいマルチバイト文字の処理」については，個別の処理内容の項で説明する。 文字コードの取り扱いについて，上流工程で留意すべき点としては，次の三つが挙げられる。 要求仕様として文字集合を定義する端末がサポートする文字集合を確認する実装に用いる文字エンコーディングを決定する まずアプリケーション仕様として，処理対象となる文字集合を規定する必要がある。日英語以外の韓国語や中国語，アラビア語などの対応が必要な場合はUnicodeを選択するしかない。さらに日本語だけの場合でも，例えばJIS X 0201＋JIS X 0208はJIS第2水準
News：「シコタホア」の意味が分かった
News：ニュース速報 2002年10月25日 04:48 PM 更新 「シコタホア」の意味が分かった 「シコタホア、ー偰」──毎日どっさり届くうわごとメールに悩まされているユーザーも多いだろう。彼らは何を言わんと欲しているのか？ 「シコタホア、ー偰」「タ・ロシコー・80％」「30ククソ・タ衂ミアンタヌヌ・ナテ！！」──毎日どっさり届くうわごとメールに悩まされているユーザーも多いだろう。彼らは何を言わんと欲しているのか？ 調べてみた。 ある日のメールソフトのごみ箱の中。こんなんばっか これらはスパムのSubject。Fromのドメインから判断すると原文はハングルらしく、当然すべて半角カナに文字化け済み。タイトルも本文も無意味なカナが並んでいる。日本語スパムはこの1年でずいぶんと減ったが、その一方でこうした文字化けスパムが急増している。 複数のメールアドレスを公開しているZDNet編集部も文
絵文字が開いてしまった「パンドラの箱」第3回--Unicode提案の限界とメリット
前回までを振り返る--Unicodeコンソーシアムの影響力 前回はどこまでお話ししましたっけ。世界中の文字の収録を目的とした文字コード規格、Unicodeは、米国のIT企業を中心に結成されたUnicodeコンソーシアムが制定するデファクト規格に過ぎないこと。しかし公的な国際機関が定めるデジュール規格ISO/IEC 10646と同期することで、WTO/TBT協定にもとづき世界中の国々に普及させられるメリットを得たこと。 また、Unicodeコンソーシアム自体はオープンな組織だけれど、意志決定を行うUTC（Unicode Technical Committee/Unicode技術委員会）で一票を投じる権利を持つのは一握りの団体に限られること。そしてUTCはISO/IEC 10646のアメリカ・ナショナルボディであるL2委員会と合同でしか開催されておらず、同時にL2委員会とUnicodeコンソー
第7回■文字エンコーディングが生み出すぜい弱性を知る
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
第8回■主要言語の文字エンコーディングの対応状況を押さえる
文字コードの問題に正しく対応する前提として，アプリケーションが稼働する基盤ソフトウエアがマルチバイト文字列処理に対応している必要がある。特に問題となるのが，言語処理系とデータベース管理システム（DBMS）である。利用者の使い方が正しくない場合も，ぜい弱性が混入することがある。このため，今回は主要言語とデータベース（MySQLとMS SQL Server）のマルチバイト文字対応状況について説明する。 文字列の処理単位は文字単位かバイト単位か Webアプリケーション開発で人気のあるスクリプト言語の多くは，かつては文字列をバイト単位で扱っているものが多かった。以下のPerlスクリプトは“漢字”という文字列の長さを表示するものだが，ソースの文字エンコーディングによって結果が変わる。具体的には，Shift_JISやEUC-JPの場合は4，UTF-8の場合は6と表示される。原因は，このスクリプトが文字
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロソフト、JIS90互換フォントの提供はWindows 7で最後 