徳丸さんがセッションアダプションをなくしても、セッションハイジャックが出来るのでsession_regenerate_id(true) （trueを付けると古いセッションデータは削除される）をしなければならないという記事を書かれています。
セッションアダプションがなくてもセッションフィクセイション攻撃は可能
http://tumblr.tokumaru.org/post/37676352092/session-adoption-and-session-fixation
まず結論を書きます。徳丸さんが「セッションフィクセイション攻撃は可能」と言われているのは間違いです。正しくは「セッションハイジャックが可能」です。
この議論は別々の異なる脆弱性を一緒にした議論で正しい議論とは言えません。セッションアダプション、セッションフィクセイション、セッションハイジャックとはどのような脆弱性なのか整理して議論する必要があります。
PROVE2エンタープライズ版の先行販売を12/25日までの期間・数量限定で行なっています。PHP5.1/5.2をご利用中でPROVE2を運用・開発に組み込みたいとお考えの方は是非この機会にご購入ください。
PROVE for PHPへ紹介動画を掲載しました。PROVEの動作・操作を3分ほどで見て頂けます。より高解像度で見れるようYouTubeにHD版もアップロードしています。
PROVE for PHPはPHPの内部動作を記録・比較し、新しいバージョンで意図通りに動作しているか確認できるテスト・ツールです。PHPプロジェクトがソースコード管理システムをGitへ移行してから、予定通り毎月新しいリリースが公開されてます。PHPを最新の状態に保つ事はセキュリティ維持の為に書かせませんが、運用中のシステムのバージョンアップは容易ではありません。PROVEはそういったバージョンアップを簡単にします。
使い方は色々あります。
PROVEはPHPの動作環境を記録した時と同じ状態にして、スクリプトを実行できます。この為、テストケースの作成はブラウザでアクセスするだけ、テストは記録したログを再生するだけで完了します。PHPのバグフィックスやセキュリティフィックスで動作が変わった場合、どこで動作が変わったのか簡単に分かります。リリースノートなどのみでは分からない動作変更も見つける事ができます。時間関数やファイル関数、データベース、ネットワークなど状態や外部リソースに依存する関数は実行をオーバーライドし、記録した時点の結果を返すことが出来ます。つまりmicrotime関数やsrand関数などに影響されずに、（PHPの動作が変わっていなければ）記録時点と同じ実行結果を得る事ができます。
PROVEのホームページで解説していない利用方法として、スマートフォンや携帯サイト開発での利用方法を紹介します。PROVEには「再帰テスト為のリクエスト送信をWebアプリに送信」する事ができます。スマートフォン、携帯サイトなどの場合、機種などの応じて異なるレスポンスを行う事が良くあります。PROVEの場合、PHPアプリにリクエストされた「リクエスト情報」がそのまま記録されます。これを再生することにより、繰り返しスマートフォンや携帯を使わずにこれらのデバイスを利用したテストを再現できます。
PROVEには前回記録した状態を再現・外部リソースに依存せずに動作する機能がありますが、この機能を利用しない状態でも利用できます。この場合、データベースやファイルなどの外部リソースをテストケース作成時と同じ状態にして実行し、PROVEによる再現機能を使わずにより広い範囲のPHP機能のテストを行う事も可能です。
プロキシやブラウザでWebアプリケーションの動作を記録するテストシステムと比べると、PHP内部の動作を全て記録するPROVEのテストは比較にならない程強力です。
PROVEの基本機能
新しいPROVE2のベータ版が公開中です。ご興味がある方は是非一度お試しください。
ホームページ
ベータ版ダウンロード
廣川類さんが執筆された「PHP徹底構築」を頂きました。3/29日発売らしくアマゾンでも予約受付中の出来たてホヤホヤの本です。書籍イメージも無かったので自分の携帯で撮った写真を載せておきます。
最新版のPHP 5.4にも対応しています。先程届いたばかりなので読むのはこれからですが、内容を簡単に紹介します。
OSC愛媛2012の「PHP5.4とはどんなPHPなのか？」の資料を公開します。ポイントは以下の通り。
プラットフォームの選択には様々な事情がありますが、Traitsはコードを効率良く再利用するには便利な機能です。さっと移行してしまうのも良いでしょう。
ところで、Traitsの例としてアクセサの実装例を紹介しています。
https://gist.github.com/1379592
しかし、次のPHPではC#風のアクセサ文法がサポートされる可能性があります。
https://wiki.php.net/rfc/propertygetsetsyntax
こちらの方が色々便利です。利用する場合は、このような文法が実装される可能性があることを理解した上で使うと良いと思います。
第二回 岡山PHP勉強会のスライドです。
遅くなりました。多少追記したい部分があったのですが、取り敢えず公開します。
少し前にPHPのechoはカンマとドット、どちらの方が速い？というエントリを書きました。
この時は長めの細切れな文字列を連結しています。カンマの方が2割ほど速い結果でした。古いPHPでは短く単純な文字列の場合もで速かった、と記憶していました。手元のPHP5.3の性能が気になったのでabで簡単に試してみました。
Git HubがMass Assignment脆弱性に脆弱で他のレポジトリが見れる状態だったらしい。問題は既に修正されています。
この脆弱性はRailsに限った事ではないし、古くからPHPを使っているユーザにとってはある意味懐かしい脆弱性でもあると思ったのでエントリを書いてみました。
PHP 5.4がリリースされました。
詳細はソースに添付されているUPGRADINGとNEWS、マニュアルのマイグレーションガイドから参照できます。
昨日、echo ‘abc’,’xyz’ （カンマ） と echo ‘abc’.’xyz’ （ドット） とどちらが速い？と言う話になったので簡単な実験をしてみました。
PHPのソースコードを見るとどちらも有利な点と不利な点があります。随分前に試した時も一般にカンマの方が速いと思える結果でしたがPHP5.3ではどうなのか試してみました。 もっと読む
第2回岡山PHP勉強会の参加募集が始まりました。
前回はすぐ満席になったのでお早めに。
昨日は第一回の岡山PHP勉強会お疲れ様でした。参加枠を何度か拡大しても60名の満席でした。初回ということでプログラマ目線からのセキュリティ対策の基本を解説させていただきました。セキュリティってわかりづらい、何をすれば良いのかわからない、という声はよく耳にします。短い時間でしたが考え方の基本は概ね説明できたと思います。
重要なことは口頭で説明したので資料だけみてもよくわからないとは思いますが、勉強会の資料を公開します。なにかございましたらツイッターなどで問い合わせて下さい。ツイッターには岡山PHP勉強会のハッシュタグ (#okaphp) を付けると他の方にも分かりやすいと思います。
次回の岡山PHP勉強会は2月だそうです。
追記：Integrityの訳はネットを検索してきた訳語の「統合性」を使っていましたが、違和感があったので調べてみました。JISでは「完全性」と訳されているので正しい用語に修正しておきました。
PHP Advent Calender用のエントリです。
PHPのセッション管理は非常に簡単です。セッションをsession_start()で開始して$_SESSION配列を使うだけです。便利で簡単なセッションモジュールですがセッションアダプションに脆弱であるため、一般に言われてる「ログインする時にはsession_regenerate_id()を呼ぶ」コーディングではセッションアダプションに脆弱になってしまいます。
まずは危険性と対策を紹介します。 もっと読む
PostgreSQL Advent Calender用のエントリです。
エスケープ処理が必要なのにエスケープ用のAPIが無い状態は良くありません。エスケープしないために動かないのはまだ良い方です。エスケープが必要なのにエ スケープをしなくても動いてしまい、セキュリティ上の問題となる場合もあります。全てのアプリケーション・ライブラリはエスケープが必要なデータに対するAPIを持っておくべき です。今回はPostgreSQL 9.0から追加されたエスケープ関数を紹介します。
PostgreSQL使い始めて最初の頃に気づくのはuserなどの予約語がフィールド名に使えない事かも知れません。例えば、
yohgaki@[local] test=# CREATE TABLE user (name text); ERROR: syntax error at or near "user" 行 1: CREATE TABLE user (name text);
と失敗してしまいます。これはuserがPostgreSQLの予約語であるためSQL文の識別子として使用できないからです。MS Accessからデータベースに入った方には識別子に日本語を使う場合も多いので、PostgreSQLでは日本語のテーブル名やフィールド名はそのままでは使えない事に気が付いた方も多いのではないでしょうか？ もっと読む
gihyo.jpで新しい記事が公開されました。
なぜ簡単な対策で防げる脆弱性でもセキュリティ対策が確実に実施されないのか？それには理由があります。
その理由とはこの2つではないでしょうか。
続きは
http://gihyo.jp/dev/serial/01/php-security/0044
でご覧ください。
こちらはその記事のはてなブックマークです。
http://b.hatena.ne.jp/entry/gihyo.jp/dev/serial/01/php-security/0044
コメント一つ一つにコメントを付けるつもりはありませんが、モノリシックなコードと処理が重複しているかいないかは関係ありません。またセキュリティ対策が重複していないと「多重のセキュリティ」を実装している事になりません。
バリデーションが仕様の話、という意味は理解できません。出力時のバリデーションは出力結果を利用するシステムが誤作動しないようにするためのセキュリティ対策です。出力はバリデーションするしか方法がない場合が多くあります。出力先は多岐にわたり、エスケープ関数もヘルパー関数も何もない、というケースはよくあります。
「多重のセキュリティ」とは同じチェックやセキュリティ対策をするということではありません。もちろん同じチェック・対策をしても構わないのですが、一般に異なるレイヤーや場所でセキュリティ対策を繰り返し行う事を「多重のセキュリティ」対策と言います。”重複”と記載したので分かりづらかったのかも知れないですね。
入力時のバリデーションコードと出力時のバリデーションコードは同じコードが使える場合もありますが別のコードを使うべきです。別のコードを使わないと「フェイルセーフ対策」の意味もなくなります。
システム構築にアーキテクチャとよいコーディングスタンダードが必要なのと同じで、セキュリティにもアーキテクチャとコーディングスタンダードが必要です。入力、ロジック、出力を別のシステムとして考えるのはアーキテクチャの話と言えると思います。入力を切り分けるのは比較的簡単ですが、出力は簡単ではありません。文字列を加工し一部がエスケープ処理済みだったり、ヘルパーを使って処理したり、別の関連システムとのやり取りがあったり、と一度にまとめて処理する事が難しい場合が多いです。フレームワークの制約があったりして、フレームワークのベストプラクティスに従うと出力する部分を切り出す事が不可能な場合もあります。このよう場合はコーディングの話と言えると思います。
よく知らないのに、というのも面白いコメントですね。Railsの基本仕様とそれに影響を受けたフレームワークの話をしています。誤読ですね。文章は一旦書くとひとり歩きする物ですからある程度は仕方ないのでしょう。仕事柄、Railsは最新版ではなくよく使われているバージョンを使っているのですが、3.2とかではバリデーションのアーキテクチャが改善されているでしょうか？またそのうち確認することにします。
入力のバリデーションと出力のエスケープが重複したセキュリティ対策であっても「多重のセキュリティ」として両方実施する、が理解できていないのは「多重のセキュリティ」を理解していないのでしょう。「PHPになぜ」という部分は「Webアプリになぜ」とタイトルを変えた方が良いのかも知れません。開発者に基本的なコンセプトや現状の理解が足りてないから脆弱なアーキテクチャの理解ができなかったり、プリペアードクエリがセキュリティ対策として不完全な対策であるという簡単な事も理解できないのだと思います。
RailsをDisっているからコミュニティは反応した方が、というコメントもありましたが逆にRailsを使い込んでる人なら同じ意見だと思います。プログラムなので、もちろん入力のチェックを最初に行う事は可能ですが、フレームワークが提供していた基本機能はデータベース保存前のバリデーションです。この仕様に困ったなあ、と思った事がある人こそ本当にRailsを使っていた人なのではないかな？
ところで、たしかプリペアードクエリが万能かのように説いていたIPAのセキュリティ対策の文書でも、最新版のSQLインジェクション対策では「エスケープ」を最初に解説しています。何が正しいのか、考え方の基本として正しいものはどう反論しても正しいので無駄な努力はやめた方が良いと思います。
この文書ではまずリテラルのエスケープ方法から解説し、3.3のまとめの図では正しく、エスケープで組み立てるしか無い場合はそちらを優先し、次にプログラムクエリが使える環境ではプリペアードクエリなどを使うような図になっています。RailsでもPHPのフレームワークでも同じですがquoteメソッドを使う場合、実際にはエスケープしています。エスケープを正しく理解していないとこれらの実装が正しいのかプログラマが判断できないので適切な解説だと思います。残念なのはPostgreSQLのエスケープ手法が解説されていない点です。今のPostgreSQLはSQL標準に則り、'(シングルクオート）は’（シングルクオート）でエスケープします。libpqにはリテラルを正しくかつ完全に処理できるようエスケープするPQescapeLiteralが追加されています。(PHPではpg_escape_literalとして利用できるようになります） これでエスケープすると E’文字列’ という形でエスケープを行い、SQL標準のエスケープである事が明示されます。おかしな使い方でSJISテキストを使っても誤作動することが無いようになっています。APIをサポートするプラットフォームがまだ少ないからこれは仕方がない部分でしょう。あって当然だった識別子のエスケープも解説されていないのは残念ですね。一般論として識別子のエスケープについては解説があった方がよいでしょう。プリペアードクエリを使っていてもエスケープが必要なケースです。紹介しないと完全な解説にはなりません。
同じ事はサニタイズに対する批判でも起きています。入力サニタイズがセキュリティ対策の切り札のように言われていた頃、私はホワイトリスト方式に入力のバリデーションこそが正しいセキュリティ対策で、ブラックリスト方式のサニタイズは不完全で誤った対策である、と言っていました。いろいろ反論もありましたが現在では「入力はバリデーションすべき」に反論する人はほぼ居ません。出力対策はエスケープが基本である、という持論に反対された方も多いですね。しかし、出力対策はエスケープが基本であるとすることに反論するようでは、分かってない人と思われるようになる日も遠くはないでしょう。
しかし、ネガティブなコメントには具体的な誤りの指摘や反論が皆無ですね。はてブの文化なのでしょうか？はてなのサービスは悪いものではないように思いますが、今ひとつメジャー感が出てこないのはこういう部分に原因があるのかも知れないですね。
