下図は、SoftBank iPhoneのMailが用いるShift_JISのIBM拡張文字領域*1。どうだ、驚いたろう。 SoftBank iPhoneのMailは、charset=Shift_JISをよく使う。髙村薫の「髙」や宮﨑あおいの「﨑」などのWindows外字もShift_JISで送るし、絵文字もShift_JISで送る。しかし、WindowsのIBM拡張文字領域とSoftBankの絵文字領域は、もともと衝突しており、共存できない。なので、SoftBank iPhoneのShift_JISでは、IBM拡張文字のうち下図ピンク部分が使えない。 だったらその分は、NEC選定IBM拡張文字のほうを使えばいいじゃないですか、どうせダブってるんだから（下図）。というのが、大ざっぱに言えば、SoftBank iPhoneのMailが用いるShift_JISである。 その外字領域をまとめると、
2. Copyright © 2010 HASH Consulting Corp. 2 本日お話しする内容 • 文字コード超入門 • 文字コードの扱いに起因する脆弱性デモ6+1連発 • 文字コードの扱いに関する原則 • 現実的な設計・開発指針 • まとめ 3. 前提とする内容 • 文字コードに起因する脆弱性とは – 正しいセキュリティ対策をしているかに見えるコードにおいて、 文字コードの取り扱いが原因で生じる脆弱性 • 以下の脆弱性に関する一般的な知識は既知のものとします – SQLインジェクション脆弱性 – クロスサイト･スクリプティング(XSS)脆弱性 – パストラバーサル脆弱性 Copyright © 2010 HASH Consulting Corp. 3 4. Copyright © 2010 HASH Consulting Corp. 4 徳丸浩の自己紹介 • 経歴 – 198
4. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • その他 – 1990年にPascalコンパイラをCabezonを開発、オープンソースで公開 「大学時代のPascal演習がCabezonでした」という方にお目にかかること
PHP: Hypertext Preprocessor PHP開発チームはPHP6におけるUTF-16化を断念。開発ブランチをPHP5.3へロールバックし、これまでに開発した機能をロールバックしたブランチへバックポートするという方針へ変更した。これはPHP6で取り組まれたUTF-16対応実装が予想以上に困難だったためと、UTF-16に移行することで得られる利益よりも不利益が多いことが判明したためだ。PHPにおける文字集合とエンコーディング回りの議論は振り出しに戻った。 しかし、変化は確実に訪れている。Mind the encodings!において「default_charset」がiso-8859-1からUTF-8へ変更されたことが紹介されている。ブラウザはサーバからのデータにエンコーディングの指定がなかった場合、これまではISO-8859-1をデフォルトエンコーディングとしていた。逆にP
これまでに挙げた文字コードについて、正規表現を使用して mb_check_encoding() の代替用の関数を書いてみました。ある程度、妥当なものになっているとは思いますが、間違い等に気付いた方がおられましたら、ご指摘ください。 UTF-8 については、RFC3629 を参考にしました。各文字は4バイト以下、冗長な表現、サロゲートペアの領域を FALSE と判定します。 <?php function is_valid_encoding( $str, $encoding ) { switch ( $encoding ) { case 'ASCII' : $regex = '/(?:' . '[\x00-\x7f]' // ASCII (mb_check_encoding) // . '[\x00\x09\x0a\x0d\x20-\x7f]' // ASCII (mb_detect_enco
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「危険な文字列の検出」「安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか（このルールを符号化方式あるいは文字エンコーディングと言います）に注意しなければならないこともあるでしょう。攻撃者は巧みに文字
じつはコメントを送っていたNTTドコモ 最初に前回のおさらいをしておきましょう。スタート当初の携帯電話の絵文字には、キャリア間でメールのやり取りの中で文字化けしてしまう欠点があったこと、それを解決する仕組みをキャリア各社が作ったものの、その場しのぎの欠点の多いものであったこと、そして絵文字のUnicode符号化というのはそうした欠点を一挙に解決するはずであること。ついでにGoogleが絵文字のUnicode符号化を進めることで、キャリア各社は今まで自分たちが育ててきた絵文字の主導権を奪われてしまうということも。 それから前回の最後では、キャリア各社に対してGoogleの提案についてどう思うか、パブリックレビューに参加する意向があるかを聞いてみました。そこでの回答は、各社そろって消極的と受け取れるものでした。 ところが前回の掲載後に、NTTドコモがGoogleの絵文字メーリングリストに投稿し
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
（2009/10/05追記）「サロゲートペアに相当する3バイト表現も正しいとみなしている」という件はバグとしてPHP5.3.0から修正されているようです。id:moriyoshiさんに超感謝。 PHPのmb_check_encoding関数の調査、おそらく今回が最終回です。今回はUTF-8について調べてみました。 UTF-8 UTF-8というのはUnicodeのエンコーディング形式の一つです。本当にざっくり言ってしまうと、ASCIIが1バイト、ヨーロッパ圏の文字が2バイト、漢字などが3バイトで表現されるようなエンコーディングです。 今回は、「UTF-8 - Wikipedia」を参考に、4バイトまでのビットパターンを全数調査しました。5バイト、6バイトも少し実験しました。 1byte : 0xxxxxxx 2byte : 110yyyyx 10xxxxxx 3byte : 1110yyyy
前回に引き続き、PHPのmb_check_encoding関数について調べてみます。今回はEUC-JP、eucJP-win、CP51932の3つについて調べてみました。 EUC-JP EUC-JPというのは0xA1から0xFEまでの2バイトの組み合わせでJISX0208漢字（いわゆるJIS第一水準＆第二水準）を、SS2(0x8E)からはじまる2バイトでJISX0201カナ（いわゆる半角カナ）を、SS3(0x8F)からはじまる3バイトでJISX0212補助漢字を、それぞれ表現するようなエンコーディング形式です。 EUC-JPに対するmb_check_encodingの挙動はシンプルで、次のものがtrueになります。 0xA1A1（JISX0208 1区1点）から0xFEFE（JISX0208 94区94点）まで 0x8EA1（半角カナの句点「。」）から0x8EDF（半角カナの半濁点「゜」）ま
(2009/02/15 17:20)「個人的な感想」を追記しました。また、下記はPHP5.2.1以降の挙動です。PHP5.2.0以前のmb_check_encodingは更にカオスなので、あまり使い物にならないと思います。 (2009/02/16 12:30)追記2：バグっぽいと思った件は本当にバグで、修正がhttp://news.php.net/php.cvs/56276の通り取り込まれました。PHP5.2.9から修正される予定です。 (2009/02/22 16:20)追記3：他のエンコーディングについても調査しました。「（その2 EUC-JP編）」と「（その3 UTF-8編）」も合わせてご覧下さい。 PHPのmb_check_encoding関数が一体何のチェックをしているのか、エンコーディングごとに一通り調べてみます。 まずはSJISとSJIS-win(CP932)について調べてみ
Unicode® Character Name Index A Name, Alias, or CategoryChart Link
さんざん悩んでちょっと方向転換してみたら、「あー、そういえばあったかも」って事に。 mb_encode_numericentity mb_decode_numericentity mb_decode_numericentity 関数を使って(10進数の)数値文字参照を文字に変換する事が出来る。以下は、(とりあえず)UTFに限定しておいて処理するお試しコード。 function nument2chr($string) { // 文字コードチェック $encoding = strtolower(mb_detect_encoding($string)); if (!preg_match("/^utf/", $encoding) and $encoding != 'ascii') { return ''; } // 16 進数の文字参照(らしき表記)が含まれているか $excluded_hex =
基本的にmbstringモジュールが無い環境を想定しているYakiBikiですが、入っていればちゃんと文字エンコーディングのチェックをしておきたいなぁとずっと思ってまして、入れたのですが。 昔設定した mbstring.substitute_character とか、mbstring.encoding_translation が On になっていたりで、不正な文字を入力させてみても mb_check_encoding() がいつもtrueを返してきたので焦りました。 まず基本方針としてはコレを見ました。 ・「これからのプログラムの作り方 - 文字エンコーディング検証は必須」 http://blog.ohgaki.net/a_a_a_a_a_ra_ca_a_oa_pa_fa_ma_sa_sa_raf ところが、コードを組み込んで適当なバイナリをGETパラメータとかに渡しても通ってしまう。・・
UnicodeがASCIIを追い越し、World Wide Web上で最も多く利用されている文字コード体系になったとGoogleのシニアインターナショナルソフトウェアアーキテクトMark Davis氏がブログで述べている。また、UnicodeはASCIIだけでなく、Western Europeanもほぼ同時に追い越している。 Unicodeは多くの言語に対応した標準文字コード体系で、発音区別符号などを利用したローマ字なども扱っている。何十年も前に定められたASCIIコードは128文字あるいは256文字（ASCIIで128 文字、拡張ASCIIで256文字）しか表現できず、タイプライターの影響を受けた同文字コードの拡張は苦戦している。 UnicodeがASCIIとWestern Europeanを追い越したのは12月で、双方が追い越された日は10日も違わなかった。 Unicodeの動きについ
CakePHPは、PHP言語の高速開発用フレームワークです。日々、発展を遂げる各種フレームワークの動向を見極めつつ、日本発のCakePHP応援ブログとして、最新情報をお届けします。 MySQLの文字コードの設定は、ujis、utf8なんかでいいんですが、HTMLのほうの文字コードとなると、業務で使用している人には常識で、そうでないと知らない、みたいなものがあると思うので、参考まで。 お客さんがWindowsを使うと分かっていて、日本語の名前に関するデータ処理をするようなプログラムを書く場合、 $str = mb_convert_encoding($str, "EUC-JP", "UTF-8"); なんてやっちゃだめです。 $str = mb_convert_encoding($str, "EUCJP-win", "UTF-8"); としないと、あとできっと、顧客からクレームが来ます。 $s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
