(Last Updated On: 2018年8月16日)追記：このエントリは古い情報です。今のHTMLエスケープの情報は以下の新しいエントリを参照してください。 PHPのHTMLエスケープ PHP_SELFはそのまま出力できないに htmspecialchars($str, ENT_QUOTES); じゃなくて、 htmspecialchars($str); で終わらせてしまった場合の、 問題例が非常に欲しいです！！ とコメントを頂きました。 htmlspecialcharsとhtmlenties関数はENT_QUOTESを指定しないとENT_COMPAT（セキュリティ上問題があるが互換性を維持）が指定された状態と同じ動作をします。 ENT_QUOTESは”と’の両方をHTMLエンティティに変換するオプションです。ENT_COMPATは”のみHTMLエンティティに変換します。 JavaS

外出のため確認が遅くなってしまったのですが、「htmlspecialcharsに関する残念なお知らせ」という記事で触れたバグレポートが、reopenされ、fixされました。 「改善される見込みは薄い」という私の予測は外れたわけで、申し訳ないと思うと同時に、htmlspecialcharsの挙動が改善され、嬉しく思っています。ご尽力いただいた皆様、ありがとうございました。 PHPのバグレポートを初めて書く方へ PHPのバグレポートには、再現コードや期待される結果、実際の結果を書く欄があります。私のレポートでも埋めました。 PHPのコミッタはそれらを読み、バグだと思えばコードを修正するでしょう。また、仕様だと思えば却下するでしょう。私のレポートでいえば、janiさんは仕様と判断され、moriyoshiさんはバグと判断されたわけです。「それでいいのか」という気もしますが、そうなのだから仕方がない

「htmlspecialcharsのパッチ私案」に書いた件、バグレポートを出してみましたが、「すでに同じバグレポートがあるだろ」という理由により、あえなく却下されました。 せめて先方が「同じ」とみなしているレポート番号ぐらいは示してほしくて、そのようにコメントしましたが、お相手のjaniという人は気難し屋のようで*1、教えてもらえる気がしません。 私なりに探した結果、下記のレポートがくさいように感じました。 PHP :: Bug #43896 :: htmlspecialchars() returns empty string on invalid unicode sequence 「不正なUTF-8シーケンスの場合に空文字列を返すのはおかしい」というレポートで、私のそれとは正反対どころか、Shift_JISにもEUC-JPにも触れられていない別個のものです。もちろん、私はレポート送信前に

大垣さんからコメントをいただきましたので、最後に追記しました(2009.09.22)。 少し時間が経ってしまいましたが、以下のページを読んで、PHP に関連する部分について思ったことを書きたいと思います。 http://blog.ohgaki.net/char_encoding_must_be_validated http://blog.ohgaki.net/is-char-encoding-problem-difficult 私の理解が間違っていなければ、「Web アプリケーションで文字エンコーディングに関連する問題を無くす」ことを目的として、全ての Web アプリケーション開発者が以下を実行しようという主張だと思います。 全ての入力文字列の文字エンコーディングの妥当性を確認する 文字エンコーディングを厳格に取り扱う データベースなどで「バイナリ」に近い文字エンコーディングは利用しない

今回解説するWebアプリケーションのバリデーションの欠陥はPHPに限った問題ではありません。多くのプラットフォームのWebアプリケーションで見過ごされているバリデーション仕様の欠陥です。それは文字エンコーディングのチェックです。 文字エンコーディングバリデーションの必要性 筆者の知る限りでは、2004年に相次いで今まで知られていなかったアタックベクタ（攻撃経路）が見つかりました。2004年に多く見つかった新しいアタックベクタとは不正な文字エンコーディングを利用した攻撃です。不正な文字列を利用したJavaScriptインジェクションやSQLインジェクションの攻撃手法が公開されました。 文字エンコーディングを利用した攻撃自体は当時でも新しい攻撃手法ではありませんでした。文字エンコーディングを利用した攻撃は、少なくとも2000年から広く知られていた攻撃手法でした。ブラウザが文字エンコーディングを

if ("0x0A" == "10") { print '(´ε｀　)ﾁｭｯ'; } チュッ。されちゃいます。 文字列であっても整数と解釈できる文字列の場合は勝手に型変換しやがる今世紀最大の愚行を犯してしまうってのは有名な話だよね。 文字列であっても整数と解釈できる文字列の場合は自動的に整数に型変換してくれる超便利機能があるってのは有名な話だよね。 だけどなんでコレが一致するかわけがわからんかった。 0x0Aは10進数で10になるので一致する。と、言いたいところなんですがそう単純な話じゃないんだ。 以下の例を目ん玉見開いて見て欲しい。 var_dump(0x0A); var_dump("0x0A"); var_dump((int)"0x0A"); var_dump((float)"0x0A"); var_dump(intval("0x0A")); 実行結果 int(10) string(4

PHPにはHTTPセッション管理モジュールが標準で付いてきます。このセッションモジュールには非常に重大なセキュリティ上の脆弱性が修正されずに残っています。その脆弱性とはセッションアダプションです。 セッションアダプションとは、セッション固定化攻撃に利用される脆弱性です。PHPのセッション管理モジュールがセッションアダプションに脆弱であることは、かなり以前、何年も前から知られています。しかし、開発者の理解不足より脆弱性が放置されたままになっています。 セッションアダプションとは セッションアダプションとは、ブラウザ等から送信された未初期化セッションIDをそのまま利用してセッションを初期化してしまう脆弱性です。ユーザが送信してきたIDでも第三者に予想できない文字列であれば大丈夫なのでは？と考える方もいると思います。その通りで第三者に予想できなければ問題ないですし、仮に予想できてもログインする際

中年以降の人生を考えるための５冊 今までずっと、ひたすらラクなことや楽しいことだけをやって生きていきたいと思っていたのだけど、40歳を過ぎた頃から、今までのやり方ではいろいろと行き詰まってくるようになってきました。何をやってもそんなに楽しくない。これからの人生はずっと下り坂が続いてい…