id:t_komuraさんの、最新の PHP スナップショットでの htmlspecialchars()/htmlentities() の修正内容についてを読みました。 見ていて気になったことが１つあります。 2. EUC-JP …（省略）… (2) \x80 - \x8d, \x90 - \xa0, \xff については、そのまま出力される <?php var_dump( bin2hex( htmlspecialchars( "\x80", ENT_QUOTES, "EUC-JP" ) ) ); var_dump( bin2hex( htmlspecialchars( "\x8d", ENT_QUOTES, "EUC-JP" ) ) ); var_dump( bin2hex( htmlspecialchars( "\x90", ENT_QUOTES, "EUC-JP" ) ) ); va
外出のため確認が遅くなってしまったのですが、「htmlspecialcharsに関する残念なお知らせ」という記事で触れたバグレポートが、reopenされ、fixされました。 「改善される見込みは薄い」という私の予測は外れたわけで、申し訳ないと思うと同時に、htmlspecialcharsの挙動が改善され、嬉しく思っています。ご尽力いただいた皆様、ありがとうございました。 PHPのバグレポートを初めて書く方へ PHPのバグレポートには、再現コードや期待される結果、実際の結果を書く欄があります。私のレポートでも埋めました。 PHPのコミッタはそれらを読み、バグだと思えばコードを修正するでしょう。また、仕様だと思えば却下するでしょう。私のレポートでいえば、janiさんは仕様と判断され、moriyoshiさんはバグと判断されたわけです。「それでいいのか」という気もしますが、そうなのだから仕方がない
http://d.hatena.ne.jp/IwamotoTakashi/20091006/p1 http://www.tokumaru.org/d/20090930.html#p01 先にはてブでコメントしてから2つ目以降を読んだっていうのはまあ秘密だとして。わたしは日本の人がどんだけPHPに関わっているか把握していませんが、見ていてこんなことを思いました: この問題は多分今のアプローチだと解決しないでしょう。というのは、今回岩本さんが書いたパッチは「仕様変更」を要求するものなので、bugtrackerで議論するだけでは結論が出せない/出しにくいもので、メーリングリストなどでちゃんと多くの人が見ているところで議論すべき内容なのです。開発者はほぼ例外なく開発MLを見ているでしょうが、バグレポートMLは（もしあれば）大量に流れてくるので、自分がメンテナンスしていない無関係なものは見ないという
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
■発注者のためのセキュリティ こちらの日記はずいぶん後沙汰しておりますが、標記のように、PHPカンファレンス2009 ビジネスデイにて発表する機会をいただきました。関係者のみなさまありがとうございました。 主催者からのリクエストが、「発注側として気をつけるべきセキュリティ」ということでしたので、今さらXSSやSQLインジェクションの話をしてもしょうがないと思い、発注者視点での話をこの機会にまとめてみようと思いました。そのため、タイトルは「45分で分かる、安全なWebアプリケーション開発のための、発注・要件・検収」といたしました。 発表の中でも述べましたが、発注者がセキュリティに関与できる場面は、発注と検収の場面しかなく、検収は発注仕様に沿っているかどうかを確認するものですので、発注と要件（発注仕様）が極めて重要ということになります。しかし、従来、このセキュリティ要件をどのように書けばよい
404方面でも絶賛されていたPHP逆引きレシピを購入した。本書はとても丁寧な仕事で素晴らしいと思ったが、セキュリティに関しては若干残念な思いをしたので、それを書こうと思う。 目次は以下のようになっている。 第1章 準備 第2章 PHPの基本構文 第3章 PHPの基本テクニック 第4章 ファイルとディレクトリ 第5章 PEARとSmarty 第6章 Webプログラミング 第7章 クラスとオブジェクト 第8章 セキュリティ 8.1 セキュリティ対策の基本 8.2 PHPの設定 8.3 セキュリティ対策 第9章 トラブルシューティング 第10章 アプリケーション編 PHP逆引きレシピ オフィシャルサポート 本書は、タイトルの示すように、コレコレしたいという目的ごとにPHPでの書き方が書かれている。よくある逆引き辞典タイプの本だが、類書に比べて丁寧に書かれている印象を受けた。私が感心したのは、PH
PHP6移行で増える脆弱なWebアプリ(yohgaki's blog) を読んで、結構気になったので、調べてみました。調べてみた結果、私には特に問題となるような箇所は見つけられませんでした。調べたことについてメモしておきます。 問題 PHP6移行で増える脆弱なWebアプリ(yohgaki's blog) で、PHP 6 への移行で脆弱な Web アプリケーションが発生すると指摘されています。その理由として、以下の2点が挙げられています。 mb_check_encodingで全ての入力文字エンコーディングが正しいかチェックしていない PHP6のhtmlentities/htmlspecialcharにはマルチバイト文字チェックコードが削除される http://blog.ohgaki.net/php6-web さらに、PHP 5.3 でも問題があると書かれています。 追記：PHP5.3のコード
(Last Updated On: 2009年9月19日)PHP6のリリースはまだまだ先の話なのですが、PHP6への移行で脆弱なWebアプリが大量に発生する可能性があります。 理由は2つ – mb_check_encodingで全ての入力文字エンコーディングが正しいかチェックしていない – PHP6のhtmlentities/htmlspecialcharにはマルチバイト文字チェックコードが削除される PHPのコードを書いている人も自覚していないと思いますが、この影響はかなりあると考えられます。 近日中にgihyo.jpのセキュリティブログに詳しい情報を記述します。 追記：PHP5.3のコードを見てみたら、バックポートすべきではないのにバックポートされてました。つまり、PHP6がリリースされたらと言う問題ではなく、今ある問題になっています。一応、改修を提案するつもりですがどうなるか判りませ
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
PHPのスクリプト読み込み用の関数である require／indclude文は、PHPが埋め込み型の言語であるために非常に危険なバグの温床となっています[1]。 つい最近のファイル読み込みバグ 執筆時点（4/24）でレポートされているファイル読み込みバグです。 WebPotal CMS（4/23） NotFTP（4/22） TotalCalender（4/22） SMA-DB（4/17） Job2C（4/16） FreeWebshop（4/16） GuestCal（4/15） Jamroom（4/15） ファイル読み込みバグはサーバの乗っ取りも可能とする致命的なバグですが、現在でも脆弱性が次々にレポートされているバグであることが分かります。 require／include文とファイル読み込みバグの問題 PHPはスクリプト（プログラム）と出力を同じファイルの中に書き込める、埋め込み型の言語
なぜPHPアプリにセキュリティホールが多いのか?：第25回 PHPのアキレス腱にて、大垣靖男氏がPHPのSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし，実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために，本来はsession_regenerate_id関数をログイン
PHPにはHTTPセッション管理モジュールが標準で付いてきます。このセッションモジュールには非常に重大なセキュリティ上の脆弱性が修正されずに残っています。その脆弱性とはセッションアダプションです。 セッションアダプションとは、セッション固定化攻撃に利用される脆弱性です。PHPのセッション管理モジュールがセッションアダプションに脆弱であることは、かなり以前、何年も前から知られています。しかし、開発者の理解不足より脆弱性が放置されたままになっています。 セッションアダプションとは セッションアダプションとは、ブラウザ等から送信された未初期化セッションIDをそのまま利用してセッションを初期化してしまう脆弱性です。ユーザが送信してきたIDでも第三者に予想できない文字列であれば大丈夫なのでは？と考える方もいると思います。その通りで第三者に予想できなければ問題ないですし、仮に予想できてもログインする際
追記: どっちが正しいとかそういう話ではないので念のため...。 追記2: Technical ReportがAnnexとなっていたのを修正。 追記3: 微妙に誤解があった部分を修正。結論としては同じ。 id:ockeghem さんの、 「POSIX正規表現の[:print:]は改行やタブがマッチするかどうかがPerlとPHPで異なりますね。Perlはマッチしない、PHPはマッチする。どっちが正しいんだ? 」というつぶやきを見て、いろいろ調べてみたんですが、 今回はPHPのせいじゃなかった みたいなのでいろいろほっとしました。 さて、まずは試してみる PHP: <?php foreach (str_split("\x09\x0a\x0d a") as $c) { var_dump(ord($c)); echo "preg_match(): "; var_dump(preg_match("(
New CakePHP 5.1 Chiffon. Faster. Simple. Delicious. What's new in 5.1 The migration guide has a complete list of /what's new in 5.1. We recommend you give that page a read when upgrading. A few highlights from 5.1 are: new plugin commands Components can now have dependencies injected by the container Upgraded to support PHPUnit 11.1+ Improved enum validation More events, so you can observe your ap
PHPは，数え切れないほどのWebサイトで使われている非常に有名なプログラミング言語である。基本的にはスクリプト言語であり，実行時にコンパイルされる。PHPは非常に多くのコミュニティによって支えられており，様々な機能を提供する膨大な数のオープン・ソース・ライブラリが公開されている。「WordPress」といった人気アプリケーションも，PHPで記述されている。ただし，PHPにもセキュリティの問題は存在する。 PHPのセキュリティ問題は，長年にわたって多くの開発者が問題の修正に取り組んできた。しかし，常に迅速な対応が行われてきたわけではなく，被害を受けるユーザーも存在した。2006年末には，PHP開発者のStefan Esser氏が，この状況に嫌気がさして，PHP Security Response Teamを辞任した。 Esser氏は自身のブログで，「（辞任した理由は）いくつかあるが，最も決
HTML Purifier ? Standards-Compliat HTML Filtering 16日(米国時間)、HTML Purifierの最新版となるHTML Purifier 3.3.0が公開された。HTML PurifierはPHPで開発されたHTMLフィルタライブラリ。HTMLをより標準規約に準拠したものへ変換する手助けをするほか、XSSとして知られている危険性のあるコードの削除などを実施できる。プラグインも提供されておりWordpressやDrupal、Joomla、Symfonyなど著名なCMSで利用できる。 HTML Purifier 3.3.0ではオーバーフローCSSプロパティのサポートが追加されたほか、特定のFirefoxバージョンで発生していたYouTubeレンダリング問題の修正、CSSDefinitionプリンタ関連の修正、iconv関連バグの修正、そのほかい
なんだかやけに長い説明ばかり検索に引っかかったので書きました。 Linuxのローカル環境でDockerコンテナ内のXアプリ（GUIアプリ）を利用するには $ xhost localhost + を実行した後に $ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path とすれば良いです。 もっと読む SSHなどよく知られたサービスポートで何も対策せずにいると数えきらないくらいの攻撃リクエストが来ます。不必要なログを増やしてリソースを無駄にし、もし不用意なユーザーやシステムがあると攻撃に成功する場合もあります。 SshguardはC作られており、flex/bisonのパーサールールを足せば拡張できますがカスタム版をメンテナンスするのも面倒です。必要なルールを足してプルリクエストを送ってもマー
(Last Updated On: )PHP4のサポートは2008/8/8を持って終了しました。サポート終了に合わせて、最後のPHP4リリースとなる4.4.9がリリースされています。サポートが終了していますが、稼動中のPHPの半分はまだPHP4であるとる統計情報もあり、まだまだ現役です。 PHPプロジェクトのサポート終了したため、PHP 4.4.9のセキュリティ脆弱性はCVEなどでも報告されなくなりました。この為、普通にセキュリティ情報を収集していてもPHP4.4.9に対する脆弱性情報は入手できません。 PHP4セキュリティ保守サービスではPHP 4にも対応しています。サポートしている脆弱性の概要は、弊社のお知らせをご覧下さい。 まだまだ、SQLインジェクションが無くなっていない事は非常に残念です。PHP4で作られたWebアプリケーションはSJISやEUCを文字エンコーディングに利用してい
大垣靖男さんの連載から 第21回 文字エンコーディングとセキュリティ（3）：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp … 技術評論社 一見この動作は無害のように思えるかもしれませんが，ブラウザなど，“\”がエスケープ文字になっているシステムでは重大な問題となります。 <div height="<?php echo addslashes($height); ?>" width="<?php echo addslashes($width); ?>"> この記事が公開された当初，上記のechoが抜けていた。しかし，echoがないと，プログラムの正常系としても動作しない。どこかから，突っ込みが入ったのであろう，その後echoが追加された。 しかし，まだ根本的におかしい。 なぜなら，以下の部分が間違っているからだ。 ブラウザなど，“\”がエスケープ文字になっているシステム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
