PHP5.4のhtmlspecialcharsに非互換問題
第3引数を指定していない場合の影響前述のように、htmlspecialchars関数の第3引数を指定していない場合、PHP5.3までは、文字エンコーディングがISO-8859-1が指定されたとみなされます。この場合、入力内容にかかわらず不正な文字エンコーディングと判定されることはありません。したがって、文字エンコーディングのチェックが働かない代わりに、エラーになることもありませんでした。 これに対して、PHP5.4の仕様により文字エンコーディングがUTF-8とみなされた場合に、Shift_JISやEUC-JPの2バイト文字が入力されると、高い確率で「UTF-8として不正」というエラーになり、htmlspecialchars関数の出力は空になります。つまり、プログラムが正常に動作しません。 htmlspecialchars関数の第3引数を指定しておらず、内部文字エンコーディングがShift_
れぶろぐ - [PHP] mb_convert_encoding 関数の ISO-2022-JP と JIS の違い
■ mb_convert_encoding 関数の ISO-2022-JP と JIS の違い mb_convert_encoding() 関数でエンコーディングを指定する際、 ISO-2022-JP と JIS では意味が違うというのはご存知でしょうか？ PHP のソースコード (mbfilter_jis.c) を見てみると、 それぞれのエンコーディングが対応する文字種は、次のようになっています。 ISO-2022-JP ASCII JIS X 0201 ラテン文字 JIS X 0208 JIS ASCII JIS X 0201 ラテン文字 JIS X 0201 半角カナ JIS X 0208 JIS X 0212 要するに、JIS は半角カナに対応していますが、ISO-2022-JP は対応していません。 そのため、半角カナのメールを扱うという無茶なことをやりたい時には、 ISO-20
PHP 5.2.12 の文字エンコーディング関連の修正点 - t_komuraの日記
PHP 5.2.12 がリリースされました。 PHP 5.2.12 Release Announcement PHP 5.2.12 ChangeLog Release Announcement にも載っていますが、以前、日記に書いた htmlspecialchars() が Shift_JIS の一部の文字を通してしまう問題は、セキュリティ問題として修正されました。 他にもセキュリティ問題の修正がありますので、バージョンアップした方が安全です。PHP 5.2.12 では、htmlspecialchars() の他にも、mbstring 関連でも文字エンコーディング関連の問題が修正されましたので、メモしておきます。 htmlspecialchars()/htmlentities() で文字エンコーディングを指定した場合に、一部の不正な文字が排除されない問題の修正 以前の日記(最新の PHP
最新の PHP スナップショットでの htmlspecialchars()/htmlentities() の修正内容について - t_komuraの日記
前の記事(Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある)で Shift_JIS ではブラウザによっては XSS が発生する可能性があることを書きました。この問題は、PHP の開発版のスナップショット(snaps.php.net)で修正されたことを確認しましたが、それ以外にも、EUC-JP や UTF-8 について修正が行われました。この件で、行動された方に感謝します。どうもありがとうございました。その後、修正内容について調べましたので、メモしておきます。他の修正点など、何か気付いた方がおられましたら、ぜひ教えてください。 この修正は、PHP 5.3.2/PHP 5.2.12 で反映されることになると思います。実際の修正内容の大半は、以下で行われました。 http://svn.php.net/viewvc?view=revision
htmlspecialcharsのShift_JISチェック漏れによるXSS回避策
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2009年10月9日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の文字エンコーディングチェック不備をついたクロスサイト・スクリプティング(XSS)脆弱性について、PHP側のパッチが提供されない状況での回避策について説明します。 何が問題か PHPにおいて、XSS対策にはhtmlspecialcharsによって記号をエスケープすることが行われますしかし、htmlspecialcharsを利用していても、Shift_JISの先行バイトを利用して、XSSが発生する場合があります。 例えば、以下のようなINPUTがあ
mb_check_encoding() の代替関数 - t_komuraの日記
これまでに挙げた文字コードについて、正規表現を使用して 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
惜しいが間違っている - elf's blog
惜しいけど間違っている点がいくつか． ●default_charsetはデフォルトの文字コードのことではない。 非常に誤解しやすい内容。 default_charsetというパラメータはご存じの人も多いと思う。 それに大抵の初心者本にはこれを設定するように書いてあるが、 むしろ逆である。 default_charsetとは 出力時にHTTPヘッダとして送信する文字コード名 のこと。 これを指定しておくと以下のコードが自動で出力される。 default_mimetype = 'text/html'で default_charset = 'utf-8'の場合 header('Content-Type: text/html; charset:utf-8'); default_charsetは関係ない．もし未指定なら単に Content-Type: text/htmlが出力されます． これだとコン
第11回■制御文字や不正な文字エンコーディングによるぜい弱性を知ろう
前回，入力値検証をセキュリティ対策として実施すべき理由を説明する中で制御文字や不正な文字エンコーディングの問題を指摘した。今回は，その具体例として「ヌルバイト攻撃」と「冗長なUTF-8によるディレクトリ・トラバーサル」を説明する。 制御文字悪用の代表格「ヌルバイト攻撃」 ヌルバイト攻撃とは，ASCIIコード0の文字（ヌル文字）を用いた攻撃である。リスト1に示すPHPスクリプトは，クエリー文字列pとして数値を受け取り，それを表示するというもの。結果を表示する前に正規表現関数eregを使って数字だけのデータかどうかをチェックし，数字でない場合にはエラーメッセージを表示するようになっている。通常，数字だけを使った攻撃は不可能であり，このような「安全な文字」だけを許可するような検査方法を一般に「ホワイトリスト検査」と呼ぶ。
PHP+PostgreSQLでEUC-JP出力は非常識！？ 〜windowsでIBM拡張文字が文字化け：地方で活動するweb制作者の日々を綴るblog
2007年07月10日23:27 カテゴリ技術-PHP PHP+PostgreSQLでEUC-JP出力は非常識！？ 〜windowsでIBM拡張文字が文字化け PHPでプログラムを作成する場合、文字コードをEUC-JPで作成するケースが多いと思います。 SJISでソースは書けませんし、UTF-8は正直まだなじみが薄いといえます。 しかし... 今回の結論（突然ですが） PHP+PostgreSQLの環境でEUC-JPを使うと、Windows環境においてIBM拡張文字を正しく表示できずに文字化けを起こす。 表示させるには、出力文字コードをUTF-8やSJISとすること。 IBM拡張文字とは？ JIS基本漢字（JIS X 0208）以外に定義される拡張文字のことです。 IBMによって定義された「IBM拡張文字」 (115〜119区) と、NECが自社のPC-9800シリーズ用に定義した「NEC
mb_check_encodingは何をチェックするのか（その1 SJIS編） - hnwの日記
(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)について調べてみ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
