昨年のPHPカンファレンスで紹介したPORVE for PHP 開発版の公開を始めました。PROVE for PHPはこんなテストが出来ます。
使い方もとても簡単です。
http://www.provephp.com/
徳丸さんのブログでescapeshellcmdの余計なお世話の件が指摘されていたのでパッチを作りました。これmagic quoteと同じレベルの余計なお世話なのですが放置されています。個人的にはどのような関数にも全てバリデーション済みの文字列しか渡さないのでセキュリティ問題は発生しないのですが、UNIX系OSではペアとなる”と’はエスケープしない仕様に気が付いていないプログラマも多いかもしれません。
私がインタビューアーと執筆を担当させて頂いたRasmusさんへのインタビュー記事は好評だったようです。
http://gihyo.jp/news/interview/2010/rasmus
この記事の中で「美しいツールは美しい問題を解決するためには非常に効果的かも知れませんが，多くの場合は必要がありません。さまざまなルールを作り，フレームワークを使い，モデルやビューを使って解決できない問題があるのです。」の部分は解説が無いと理解できないかも知れません。Rasmusさんなら私と同じようにこう思っているハズという補足なので外している可能性もありますが、この部分の意図を補足します。
PHPカンファレンス2010ではビジネスデイにリグレッションテストツールのPROVE for PHPを紹介させて頂きました。その講演の資料です。Keynoteで話しながら説明するように作っていたので、PDFで見ても大丈夫なように少し改変しています。
http://blog.ohgaki.net/media/users/yohgaki/PHPCON2010PROVE4PHP.pdf
商用ですがビジネスモデルは決まっていません。今のところパーソナルユースは無償で利用できるようにする方向性でビジネスモデルを考えています。
このプレゼンの中では解説していませんが、厄介なのがSESSIONモジュールのデータの取り扱いです。セッションモジュールのセッションセーブハンドラは直接I/Oを行っているのでラッパーを書けません。幸いセッションセーブハンドラはモジュール構造を持っているので、少し無理やりですがPROVEが定義した関数を呼び出すようにしてTRACEとVALIDATIONモードが正しく動作するようにしています。
まだまだ作り足りない部分が多いのでリリースは先になりますが、アップグレード時の動作チェックが劇的に楽になります。
Mac OSX 10.6のPHPはPHP5.3なのでPHP5.2をビルドしてインストールしたい、と思っている方も多いと思います。Macportsが入っていれば、
sudo port install php52 php52-web
のような感じでPHP5.2をインストールできます。Portsじゃなくてソースから、そしてPECLなど他のモジュールもロードするのではなくスタティックに組み込みたい！という場合もあるでしょう。いちいちモジュールディレクトリを作ってphp.iniでロールするのは面倒ですから当然です。
もっと読む
本格的にSubversionからGitへの移行を行った際に作ったGit+SSHサーバの手順をWikiに書きました。この手順を実行すると
ができるようになります。
詳しくはWikiのgit sshサーバの構築をご覧下さい。
Subversionの頃はWebDAV+SSL+Basic認証だったので以前と比べればかなり認証の安全性は増したと言えます。
PHPが文字エンコーディング攻撃に比較的強い理由は入出力の文字エンコーディングのバリデーション（サニタイズ）が行えるだけではありません。PHPが提供するHTMLエスケープ関数が文字エンコーディング攻撃に対して強い事も理由の一つです。
PerlでHTMLエスケープと言えば、<,>,&,”,’をエンティティ変換するコードが一番に見つかります。
「perl html escape」でググると一番に見つかったページは次のページです。このページではまだ3バイトEUCの場合の例、CGIモジュールを使った例も載っているので良い方でしょう。
http://saboten009.blogspot.com/2008/04/perlhtml-xss.html
少し前にPerl, Ruby,Pythonユーザは検索で有用なセキュリティ情報を得られるのか？と疑問に思い調べました。これだけ知っていれば取り合えず十分というページはそう簡単には見つかりませんでした。
いつも問題になるのは PHP だけど Perl は問題ないのか、すでに議論し尽くされた問題なのか、PHPer のモラルが低いせいか。
Perl,Ruby, Pythonで議論し尽くされ対策が浸透している、とは到底思えません。Railsで文字エンコーディングを利用したXSS脆弱性が話題になっていることからも明らかです。PHPがいつも問題になるのはよく使われていて、初心者も多く、公開されているWebアプリも圧倒的に多いからです。モラルの問題ではありませんし、このページで紹介されているPerlのエスケープ方法だけではPHPのhtmlentities()やhtmlspecialchars()よりも脆弱です。文字エンコーディングを考慮するようになっていないからです。 もっと読む
Twitterで書いた方が良いようなエントリですが、たまには良いでしょう。
#perl – utf8::decode()ではなくEncode::decode_utf8()を使うべき理由
という記事がありました。PHPにも似た関数、utf8_decodeがあります。PHPでも使ってはなりません。日本人というよりマルチバイト圏で使っている人はほとんどいないはずです。理由はコードを見れば一目瞭然です。 もっと読む
一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。
その間違いとは
です。(※0)
私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。
不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。
参考：エンジニア向けにもう少し解りやすいブログを最近書いています。
Linux Foundationは全面的にDrupalと呼ばれるCMSに移行したそうです。日本のLinux Foundationも当然、Drupalに移行しています。そこでLinux Foundationの小薗井さんから一度講師をして欲しい、と頼まれていました。PHPカンファレンスにいったので、その次の日の日曜日、9月6日の勉強会に参加してきました。
外国人の方が多い、と聞いていたのですが本当に外国人の方の割合が多かった。20名弱(?)ほどのうち4名くらい(?)は外国人の方、日本人の方(?)でも帰国したばかりで日本語がたどたどしいと言われている方もいました。とてもインターナショナルな感じで学生のころを思い出しました。
ユーザ会のURL: http://groups.drupal.org/japan
勉強会の様子は次のような感じです。
その時に使った資料を公開します。
テーマはPHPを使った安全なWebプログラミングの概要です。
クリックしてSecure-PHP-Programming.pdfにアクセス
かなり古い資料をリフレッシュさせたのですが、時代の流れを感じました。昔は「まあ、いいか」と判断していた部分も今でもは「絶対ダメ」になっていたりしました。とは言っても「Webアプリセキュリティ対策入門」はこれより新しく書いたもなので今でも十分通用します。ちょうど良い時期に出版したといえるのかも知れません。
資料にタイポや概要の説明であっても分かり辛い点と思える箇所などありましたら、ぜひ教えて下さい。
DrupalなどのCMSは興味の対象外だったのですが、NetCommonsといい個人的にはブーム(遅すぎ?)になっています。ToDoリストにやりたいことが山積みです…
http://googlewebmastercentral.blogspot.com/2009/02/canonical-link-element-presentation.html
では、サーチエンジンに登録されるURLをまとめる為に
<link rel=”canonical” href=”http://example.com/page.html”/>
というタグをheadに埋め込むとあります。この仕様は
http://journal.mycom.co.jp/news/2009/02/26/018/index.html
によると、Google、Yahoo!、Microsoftの三社で合意されたそうです。
このブログも
http://blog.ohgaki.net/
http://blog.ohgaki.net/index.php
http://blog.ohgaki.net/index.php?no_such=value
等のURLでアクセスできるのですが、
<head>
<link rel=”canonical” href=”http://blog.ohgaki.net/ “/>
</head>
と入れておくと同じURLとしてサーチエンジンで処理してくれるそうです。
Zend_ToolのzfコマンドがZendFrameworkのバージョンによって使えたり、使えなかったりする問題で困っていたのですが原因が分かりました。
Zend_Toolのzfコマンドでプロジェクトを作成すると
$ zf create project
ZendFrameworkのファイルをカレントディレクトリのlibraryに全てコピーします。プロジェクトの雛形にはapplication/boostrap.phpが含まれ、ここでinclude_pathが設定されます。boostrap.phpは、エントリポイントとなるpublic/index.php
// @see application/bootstrap.php
$bootstrap = true;
require ‘../application/bootstrap.php’;
から毎回必ず呼ばれるので
// you may wish to add other paths here, or keep system paths: set_include_path(‘../library’ . PATH_SEPARATOR . get_include_path()
set_include_path(‘../library’);
ZendFrameworkのアーカイブはどこに展開しても構わないようになっています。
この事は知っていたのですが、zfコマンドを使わないでZendFrameworkを使えるよう、PEARをインストールしたディレクトリにlibrary/Zendディレクトリをコピーし、デフォルトのphp.iniでinlcude_pathに設定してZendFrameworkを使うようにしていました。
これがどうもダメだったようです。Zend_Toolのディレクトリ構成を見て、似通った構成だったのでもしかして、と思いinclude_path設定を変えて試してみました。すると動かないと思っていたバージョンでもzfコマンドが動作するようになりました。インクルードパスにZendFrameworkのライブラリをパスにいれると、意図しないスクリプトが読み込まれてエラーになったりしていたようです。中途半端に動く物もあったりしたのでですが「previrew版だから仕方ないか」と思って詳しく調べていませんでした。これで一つすっきりしました。
Zend_Toolを試す場合、ZendFrameworkのZendディレクトリはinclude_pathに入れないようにした方が良いようです。基本的な事ですが、探しても情報が見つからなかったので書いておきます。
追記：より新しい情報については間違いだらけのHTTPセッション管理とその対策をどうぞ。
PHPには広く知られているにも関わらず放置されている既知のセキュリティ脆弱性が幾つかあります。その一つがセッションモジュールのセッションアダプション(Session Adoption)脆弱性です。この脆弱性は現在広く利用されているWebアプリケーションの安全性に、非常に大きな影響を与える脆弱性です。
セッションアダプション脆弱性とはセッション固定化攻撃を可能とする脆弱性の一種です。セッションアダプションに脆弱なセッション管理システムは、ユーザ(ブラウザ)が送信してきた未初期化のセッションIDを受け入れ、セッションを初期化してしまいます。PHPに限らず、RailsやJavaのフレームワーク等、多くのWebフレームワークに発見されている脆弱性です。
セッションアダプション脆弱性を利用すると、攻撃者は長期間に渡って他人のIDを使う成りすましが可能になる場合があります。IDを盗みたい犯罪者には利用価値の高い脆弱性です。
この脆弱性は、10年以上前から問題視されている国別TLD(ccTLD)の属性ドメイン(国別Top Level Domain, co.jp, or.jpなどのドメイン)にも下位ドメインからクッキーが設定でき、サブドメインのクッキー設定が無視される(送信順序、優先順位がいい加減)、というとんでも無いクッキーの仕様と組み合わせると、大量の他人のユーザセッションIDを取得(設定)し、成りすます事ができます。
セッションアダプション問題は全てのPHP、PHP 4.4.9/PHP 5.2.8/PHP 5.3/PHP 6.0に共通する脆弱性です。
最近、影響範囲はかなり狭くなりましたが、まだまだ注意が必要な脆弱性であり、根本的な解決にはパッチと適切なセキュリティ対策が必要です。
PHP4のサポートは2008/8/8を持って終了しました。サポート終了に合わせて、最後のPHP4リリースとなる4.4.9がリリースされています。サポートが終了していますが、稼動中のPHPの半分はまだPHP4であるとる統計情報もあり、まだまだ現役です。
PHPプロジェクトのサポート終了したため、PHP 4.4.9のセキュリティ脆弱性はCVEなどでも報告されなくなりました。この為、普通にセキュリティ情報を収集していてもPHP4.4.9に対する脆弱性情報は入手できません。