yohgaki's blog

のんびりしていた訳ではありませんが、PHP 5.4.1のブランチが作られたので慌ててStrict Sessionパッチを改訂しました。

master
https://gist.github.com/1379668

5.4
https://gist.github.com/2224196

5.3
https://gist.github.com/2224360

以前、Gistに入れていたパッチとの違いは、

• PSモジュール（セッションセーブハンドラ）のAPIを変更しないように修正
  （これにより使っているハンドラが対策済みかどうかは見て分かるようには出来なくなりました。その代りにmemcacheなどのサードパーティのセーブハンドラのコンパイル済みバイナリとの互換性を維持しています。）
• セッションIDのコリージョン（衝突）を検出
  （三回リトライしてもコリージョンする場合はエラー。通常、三回もコリージョンすることはまずあり得ません。）

となります。

PSモジュールを書く方（ユーザセーブハンドラ含む）はセッションをOPENする場合にセッションIDが初期化済みか、チェックする必要があります。

と、ここまで書いてパッチに多少問題がある事に気が付きました。自動生成する場合はコリージョンを検出していますが、session_regenerate_id()で生成する場合はコリージョンをチェックしていません。session_regenerate_id()を呼んだ時もチェックしないと片手落ちなので近いうちに修正します。

パッチを書いていてsession_write_close()してsession_start()をした場合、おかしくなることに気が付きました。困っている人が居るか、バグDBを検索するとやはり数人からバグレポートされていました。この件は別途に対応する事にします。

パッチを使ってみてくださる方、大募集です。ZTS、Non-ZTSの両方でUNITテストは実行していますが、Webサーバでテストしていません。動いたら、Twiterなどで良いので教えてください。よろしくお願いします。

このパッチについては、こちらをご覧ください。これは私が書いているのでおかしな英語があった場合、教えて頂けると助かります。

https://wiki.php.net/rfc/strict_sessions

廣川類さんが執筆された「PHP徹底構築」を頂きました。3/29日発売らしくアマゾンでも予約受付中の出来たてホヤホヤの本です。書籍イメージも無かったので自分の携帯で撮った写真を載せておきます。

最新版のPHP 5.4にも対応しています。先程届いたばかりなので読むのはこれからですが、内容を簡単に紹介します。

...

• 第一章 攻撃を防ぐセキュリティの確保
• 第二章 再利用・開発効率化の為のオブジェクトとクラス
  Traitsにも対応
• 第三章 一連の処理を管理するセッションの仕組み
• 第四章 成りすましを防ぐ認証の仕組み
  OpenID, OAuthの解説もあり
• 第五章デザイン・処理の並列開発を可能にするテンプレート
• 第六章 柔軟かつ厳密にデータを記述できるXML
• 第七章 複数の文字セットやモバイル端末に対応する日本語処理
• 第八章 開発効率化・性能改善のためのテスト/デバッグとチューニング
• 第九章 性能を大幅に改善するキャッシュの仕組み
• 第十章 PDF/画像を動的に生成する
• 第十一章 フレームワークで開発を効率化する
• 第十二章 クラウドを支えるWeb API
  Yahoo, Amazon, Twitter, Mixi, Facebok, Hatena, GoogleのAPIが紹介されている

PHPの文法やコードの書き方は一通り覚えた。次に進もう、という方にお勧めだと思います。

OSC愛媛2012の「PHP5.4とはどんなPHPなのか？」の資料を公開します。ポイントは以下の通り。

• PHP 5.4は基本的にはベターPHP5.3
• 互換性問題もあるが、一般に致命的な問題はない
• 全般にPHP5.4は速い
• 移行を考えている方は早い方が良い（使える期間が長くなる）
• ディストリビューションのPHPを使う、という選択もある（RHEL6 PHP5.3, Ubuntu LTS PHP5.4?)

プラットフォームの選択には様々な事情がありますが、Traitsはコードを効率良く再利用するには便利な機能です。さっと移行してしまうのも良いでしょう。

ところで、Traitsの例としてアクセサの実装例を紹介しています。

https://gist.github.com/1379592

しかし、次のPHPではC#風のアクセサ文法がサポートされる可能性があります。

https://wiki.php.net/rfc/propertygetsetsyntax

こちらの方が色々便利です。利用する場合は、このような文法が実装される可能性があることを理解した上で使うと良いと思います。

PHPのソースコードのリポジトリがSubversionからGitに移行しました。

https://wiki.php.net/vcs/gitfaq

個人的には、これで色々楽になります。

第二回 岡山PHP勉強会のスライドです。

遅くなりました。多少追記したい部分があったのですが、取り敢えず公開します。

少し前にPHPのechoはカンマとドット、どちらの方が速い？というエントリを書きました。

http://blog.ohgaki.net/echo-comma-vs-dot

この時は長めの細切れな文字列を連結しています。カンマの方が2割ほど速い結果でした。古いPHPでは短く単純な文字列の場合もで速かった、と記憶していました。手元のPHP5.3の性能が気になったのでabで簡単に試してみました。

...

<?php echo 'aaaaaaaaaaaaaaaaaaa', 'bbbbbbbbbbbbbbbbbbb', PHP_EOL ?>

Requests per second:    4409.19 [#/sec] (mean)

<?php echo 'aaaaaaaaaaaaaaaaaaa'. 'bbbbbbbbbbbbbbbbbbb'. PHP_EOL ?>

Requests per second:    3712.72 [#/sec] (mean)

このケースでもおよそ2割ほどカンマの方が速い結果となりました。

追記： ソースコードからはほぼ同じ速度になってもおかしくないかも、と思える部分があったのでもう少しだけテストしてみました。同じPC上でabとApacheを動作させていたのですが、繰り返し実行してみると予想以上にかなり結果にばらつきがありました。正確に記録をとって比較していないので感覚的にですが、1割くらい速いような感じでした。

以下のように更に短く単純な文字列にしてみると

<?php echo 'a','b',PHP_EOL ?>

ほぼ同じかもしかするとドットで連結した方が速いかも、と思える結果でした。

PHPのベンチマークをよく取っている方なら細かく正確なベンチマークをあまり意味の無いことを良くご存知だと思います。単機能、単純なベンチマークはマイナーバージョンが違うだけでもかなり異なる事が多く、実際に自分の環境で速くなるかは分からないからです。（もともとベンチマークとはそういう物ですけどね）

これらの結果から推測すると、出力をキャッシュしていないアプリならカンマに換えるだけで計測できるくらいの差が出ることが多いと考えられます。しかし、かならず有意なほどの速度差がでる、とは限らないので態々カンマをドットに書き換えるような作業はあまりお薦めできません。

少し長い文字列を利用した場合のabコマンドの出力結果

[yohgaki@dev public_html]$ ab -c 100 -n 10000 http://yohgaki/echo.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking yohgaki (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache/2.2.21
Server Hostname:        yohgaki
Server Port:            80

Document Path:          /echo.php
Document Length:        39 bytes

Concurrency Level:      100
Time taken for tests:   2.268 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2320000 bytes
HTML transferred:       390000 bytes
Requests per second:    4409.19 [#/sec] (mean)
Time per request:       22.680 [ms] (mean)
Time per request:       0.227 [ms] (mean, across all concurrent requests)
Transfer rate:          998.96 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       4
Processing:     3   22   4.6     21      42
Waiting:        3   22   4.6     21      42
Total:          7   23   4.6     22      42

Percentage of the requests served within a certain time (ms)
50%     22
66%     24
75%     26
80%     27
90%     28
95%     30
98%     33
99%     37
100%     42 (longest request)

[yohgaki@dev public_html]$ ab -c 100 -n 10000 http://yohgaki/echo.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking yohgaki (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache/2.2.21
Server Hostname:        yohgaki
Server Port:            80

Document Path:          /echo.php
Document Length:        39 bytes

Concurrency Level:      100
Time taken for tests:   2.693 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2320232 bytes
HTML transferred:       390039 bytes
Requests per second:    3712.72 [#/sec] (mean)
Time per request:       26.934 [ms] (mean)
Time per request:       0.269 [ms] (mean, across all concurrent requests)
Transfer rate:          841.25 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       4
Processing:    15   27   6.5     24      59
Waiting:       15   26   6.4     24      59
Total:         15   27   6.6     24      62

Percentage of the requests served within a certain time (ms)
50%     24
66%     29
75%     30
80%     31
90%     36
95%     41
98%     46
99%     50
100%     62 (longest request)
[yohgaki@dev public_html]$

Git HubがMass Assignment脆弱性に脆弱で他のレポジトリが見れる状態だったらしい。問題は既に修正されています。

この脆弱性はRailsに限った事ではないし、古くからPHPを使っているユーザにとってはある意味懐かしい脆弱性でもあると思ったのでエントリを書いてみました。

...

Mass Assignment脆弱性はRuby on Rails Security Guidesにも記載されている脆弱性でActiveRecordの値をハッシュで一度に設定できる機能の脆弱性です。具体的には以下のようなコードが問題となります。

userががハッシュとして渡されていてその中の変数がプロパティとして設定される、という便利な機能です。

Userオブジェクトがadminプロパティを持っている場合

などと user.adminがtrueとなってしまう様に設定すると普通のユーザが管理者権限を持ってしまうと、といった感じでセキュリティ問題となります。対策は簡単です。

としてプロパティを保護するように指定するだけです。

古くからのPHPユーザにはregister_globalsが有効だった頃の脆弱性と全く同じ、と懐かしく思った方も多いかも知れません。今時、register_globals=onで運用しているシステムは非常に少ないと思います。もうこの脆弱性はPHPユーザには関係ない、と思うかも知れませんがそうはいきません。

このMass Assignmentと呼ばれる脆弱性はRailsの限った脆弱性では有りません。オブジェクトのプロパティを一度に変更できるような物は脆弱になる可能性があります。ActiveRecordのようなORM全般に見られる脆弱性なのでPHPでORMやオブジェクトのプロパティを一度に変更できるような仕組みを使う場合もMass Assignment脆弱性に注意が必要です。

この脆弱性に気づく事はそれほど難しくないと思います。便利な機能にはリスクがあることが多いので、使う前にどんなリスクがあるのかな？と少し考えてみると落とし穴を避けることができると思います。

追記：オブジェクトのプロパティを配列などから一度にアサインするような場合にセキュリティ問題が起きるのですが、おかしな説明だったので多少修正。基本的に配列やハッシュなどから一度に何かを変更できるような物にはMass Assignment脆弱性の問題が発生する可能性があるので注意が必要です。

リンク: http://www.php.net/archive/2012.php#id2012-03-01-1

PHP 5.4がリリースされました。

詳細はソースに添付されているUPGRADINGとNEWS、マニュアルのマイグレーションガイドから参照できます。

...

注目の新機能

• Trait
• 配列の省略記法 　$array = [1, 2, 3]; $array = ['a'=>1, 'b'=>2, 'c'=>3];
• 配列を返す関数の添字へ直接アクセス　foo()[0] などと利用可能
• オブジェクト生成時のメンバーアクセス　(new foo)->method(), (new foo)->property
• タイプヒントにcallableが追加　function(callable $func)などと利用可能
• CLI Server

個人的にはCLI Serverは非常に便利だと思います。PHPのWebアプリを少し試したい、といった場合にWebサーバを別途に用意しなくてもPHPだけで試す事ができます。しかもかなり高性能です。CLIのインタラクティブモード（php -a）にページャが指定できるようにもなりました。地味ですが便利な機能だと思います。

注目の仕様変更

• ショートオープンタグ"<?"が常に利用可能
• default_charsetはUTF-8がデフォルトhtmlentities/htmlspecialcharsのデフォルトがUTF-8に変更
• 文字列の取り扱いに整合性（$str[0][0], str('abc', 'xyz),などの動作が変わる)
• htmlentitiesの動作が厳格に（いろいろ変わっています。UPGRADINGを参照）
• ZendマルチバイトサーポートがコンパイルオプションからINIオプションへ（zend.multibyte）
• スクリプトエンコーディング（zend.script_encoding、declare(encoding="encname")）
• レガシー機能（マジッククオート、Zendエンジン１互換性、古いセッションモジュールとの互換性、セーフモードなど）の削除
• E_ALLにE_STRICTが追加
• ext/sqliteがPECLへ（SQLite3はそのまま）
• $_SERVER['REQUEST_TIME_FLOAT']が追加

このブログでも紹介しましたが、文字エンコーディングの取り扱いが変わっています。

関数や式の戻り値が変ってしまう場合もあるので以前のPHPからのアップグレードには注意が必要です。

PHP5.4の性能

便利そうな機能が増えると性能も気になります。PHP5.4の性能は全般的に以前のPHPより向上しています。PHPのCIシステムのベンチマークでは全般的な性能向上が分かります。

http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20120203-5.3.10-5.4.0RC7.html

アプリケーションレベルではバイトコードキャッシュが無い状態で１割程度の性能向上も期待できそうです。

まとめ

ロードマップによるとPHP 5.4のリリース後１年でPHP 5.3はEOL、その一年後にはセキュリティパッチのリリースも停止される予定です。慌ててマイグレーションの準備をする必要はありませんが、計画的にマイグレーションをすすめる必要があります。 PHP 5.4対応はこれからですが、このような用途にPROVE for PHPは適しています。

多くのスクリプト、アプリケーションはそのまま動作すると思います。しかし、マイナーバージョンアップなので思わぬ所で問題が発生しないように注意してください。

追記

NEWSファイルの記述が誤っており、default_charsetでなくhtmlentities/htmlspecialcharsのデフォルト文字エンコーディングが変更されている。リポジトリのNEWSファイルは修正されている。

昨日、echo 'abc','xyz'  （カンマ） と echo 'abc'.'xyz' （ドット） とどちらが速い？と言う話になったので簡単な実験をしてみました。

PHPのソースコードを見るとどちらも有利な点と不利な点があります。随分前に試した時も一般にカンマの方が速いと思える結果でしたがPHP5.3ではどうなのか試してみました。

...

コード

<?php
$text = '
Prevent possible crash when joining to a scalar function
Prevent transitory data corruption of GIN indexes after a crash
Prevent data corruption on TOAST columns when copying data
Fix failures during hot standby startup
Correct another "variable not found in subplan target list" bug
Fix bug with sorting on aggregate expressions in windowing functions
Multiple bug fixes for pg_upgrade
Change Foreign Key creation order to better support self-referential keys**
Multiple bug fixes to CREATE EXTENSION
Ensure that function return type and data returned from PL/perl agree
Ensure that PL/perl strings are always UTF-8
Assorted bug fixes for various Extensions
Updates to the time zone database, particularly to CST6
Changes marked with ** above require additional, post-update steps in order to fix all described issues. See the release notes for each version for a full list of changes with details of the fixes and steps.
One-click installer, including Windows packages';

$ary = split(' ', $text);
if (!empty($_GET['c'])) {
 $scr = 'echo \''.join('\',\'', $ary).'\';';
} else {
 $scr = 'echo \''.join('\'.\'', $ary).'\';';
}
echo $scr;
for ($i=0; $i<100; $i++) {
 eval($scr);
}

速度差が分かりやすいように100回出力を繰り返しています。これをabで実行してみました。

このケースの場合、

ドット
Requests per second:    459.25 [#/sec] (mean)

カンマ
Requests per second:    582.24 [#/sec] (mean)

となり、カンマの方がおよそ27％ほど速い結果となりました。

試していませんがechoで出力する文字列が短く、文字列連結が少ない場合、連結のオーバーヘッドが小さいのでここまでの違いは出ないか、もしかすると速くなるケースもあると思います。ただ、恐らく一般のアプリケーションはドットで連結してから出力するより、カンマで連結なしで出力した方が速くなるケースの方が多いと思われます。

CMSなどで実験すると分かりやすいのですが、流石に書き換えが結構大変。。。

どなたか実験された方がいらしたら教えてください。

abの実行結果：　ドット

[yohgaki@dev ~]$ ab -c 100 -n 10000 http://192.168.100.51/echo.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.100.51 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache/2.2.15
Server Hostname:        192.168.100.51
Server Port:            80

Document Path:          /echo.php
Document Length:        84947 bytes

Concurrency Level:      100
Time taken for tests:   21.774 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      851290000 bytes
HTML transferred:       849470000 bytes
Requests per second:    459.25 [#/sec] (mean)
Time per request:       217.745 [ms] (mean)
Time per request:       2.177 [ms] (mean, across all concurrent requests)
Transfer rate:          38179.50 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   0.6      0       5
Processing:     8  217 113.1    212    1033
Waiting:        1   64  79.0     13     218
Total:          8  217 113.1    213    1033

Percentage of the requests served within a certain time (ms)
50%    213
66%    227
75%    250
80%    271
90%    364
95%    439
98%    533
99%    599
100%   1033 (longest request)

abの実行結果： カンマ

[yohgaki@dev ~]$ ab -c 100 -n 10000 http://192.168.100.51/echo.php?c=1
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.100.51 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache/2.2.15
Server Hostname:        192.168.100.51
Server Port:            80

Document Path:          /echo.php?c=1
Document Length:        84947 bytes

Concurrency Level:      100
Time taken for tests:   17.175 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      851290000 bytes
HTML transferred:       849470000 bytes
Requests per second:    582.24 [#/sec] (mean)
Time per request:       171.751 [ms] (mean)
Time per request:       1.718 [ms] (mean, across all concurrent requests)
Transfer rate:          48403.74 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   0.9      0       7
Processing:     6  171 140.9    145    1388
Waiting:        1   17  20.6      6     375
Total:          6  172 141.0    146    1388

Percentage of the requests served within a certain time (ms)
50%    146
66%    175
75%    205
80%    233
90%    340
95%    444
98%    595
99%    705
100%   1388 (longest request)


HHKが壊れてしばらく普通のJIS配列キーボードを使っていたのですが、我慢ができなくなりLinux PC用にJIS配列Apple KeyboardのUSB版（フルサイズのApple Keyboard）を購入しました。

Macbookと同じ配列のワイヤレスの場合、長時間の入力には向かない、とAppleサイトの製品レビューにはあったのでUSB版を購入しました。

...

LinuxとLinux上のVMwareでWindowsを利用しています。Linux/Windowsで一番問題になるかな、と思ったのは漢字キーです。

BootcampにインストールしたWindowsの場合、漢字キーの代わりにCapsLockキーを利用します。AppleのドライバをインストールしていないWindowsでもCapsLockキーで漢字入力の切り替えがでました。取り敢えずはドライバ無しでも特に困ることは無いようです。

Apple Keyboardがどのようなキーコードを送っているかLinux上のxevコマンドで確認しました。

KeyPress event, serial 33, synthetic NO, window 0x5400001,
root 0x1ae, subw 0x0, time 79424903, (-126,548), root:(2567,594),
state 0x10, keycode 66 (keysym 0xff30, Eisu_toggle), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

英数キー(Eisu_toggle)が押された事になっている事がわかります。

通常のJIS配列キーボードで漢字（全角半角）キーを押した場合、

KeyRelease event, serial 33, synthetic NO, window 0x5400001,
root 0x1ae, subw 0x0, time 77693326, (-126,549), root:(2567,595),
state 0x10, keycode 49 (keysym 0xff2a, Zenkaku_Hankaku), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

全角半角キー（Zenkaku_Hankaku）が押された事になっています。

Windowsの場合、英数キーでも漢字キーでも日本語入力モードに切り替わるのでBootcampのWindowsと同じ使い勝手でWindowsを使う事ができます。（ただし、CapsLockキーがMacBookやワイヤレスキーボードの場合は左下、フルサイズのUSBの場合は右下、と位置が異なりますが）

Linuxの場合、漢字キーを押してもSHIFT+SPACEを押しても日本語入力モードになるでこのままでもあまり困りませんが同じキー操作で入力モード方式を変更できる方が便利です。X Windowsは~/.xmodmaprcファイルでキーボードのバインティングを自由に変更できるので以下のようにカスタマイズしました。（システムによっては~/.xmodmaprcではなく~/.Xmodmap, ~/.xmodmapの場合もあります）

設定を試すにはxmodmapコマンドで設定ファイルを読み込みます。

xmodmap .xmodmaprc

!で始まる行はコメントです。古い設定はHHKが壊れた時に通常のJIS配列キーボードを代用していた時の設定です。全角半角のESCにESCを漢字キーに、CapsLockをCTRLにして使っていた時の設定です。

[yohgaki@dev ~]$ cat .xmodmaprc
!remove Lock = Caps_Lock
!keysym Caps_Lock = Control_L
!add Control = Control_L
!keycode 9 = Zenkaku_Hankaku
!keycode 49 = Escape

remove Lock = Caps_Lock
keycode 66 = Zenkaku_Hankaku

恐らく多くのLinux環境でApple Keyboardを使うには最後の2行を足すだけで十分でしょう。Apple KeyboardのCapsLockキーを押した場合、英数キーを押した場合と同じなります。Shiftキーを押しながらCapsLockを押すとCapsLockのキーコードが送られるのですが、CapsLockキーが生きている状態だとCapsLockだけ押してもShift+CapsLockを押したような状態になるので無効にしました。

参考までに私のJIS配列キーボードに設定しているLinuxではApple Keyboardがどのようなキーコードを送っていたか列挙しておきます。

• 英数：なし
• かな： なし
• Contorol: 左Control
• 左Command： keycode 133 (keysym 0xffeb, Super_L)
• 右Command： keycode 134 (keysym 0xffec, Super_R)
• F13: なし
• F14： PrintScreen
• F15: なし
• F16: Pause
• F17からF19： なし
• Clear: NumLock
• Fn： なし

個人的にはKVM用にScrollLockキーが無いと困るのですが、これはそのうち調べる事にします。

追記：

入力モードを切り替えるだけなら入力メソッドの設定を変える方法もあります。例えば、私はiBusをGnomeで使っているのでメニューバーのiBusアイコンを右クリックして設定メニューのキーボードショートカットで変更することもできます。

追記2：

KVM経由の入力からxevでキーコードを見ているので、KVMが無い環境だと違った結果になるかも知れません。http://support.apple.com/kb/HT1216 を見るとScrollLockの送り方も書いてあるのですがWindows環境ではドライバで対応しているのではないか？と思います。KVMには実際にキーコードが送られないとどうしようもありません。CoregaのPC４KVMCAというKVMですがホットキーが切り替え可能でした。F12に割り当てて全て以前通りに利用できるようになりました。

追記3：

Windowsの場合、Caps Lockで英数モードと漢字モードを切り替えることができるのですがIME（入力メソッド）をオフにすることができません。ドライバを入れるなどして対応しないとWindows常用するには難があります。

第2回岡山PHP勉強会の参加募集が始まりました。

http://atnd.org/events/24637

前回はすぐ満席になったのでお早めに。

二回目のPHP 5.4 Advent Calender用のエントリです。

今回はPHP 5.4より後のPHP（5.5かな？）で利用可能になると思われるAccessorの仕様について紹介します。まずはAccessorのおさらいから。

...

PHP 5.3まで

class foo {
  private $var;
  function getVar() { return $this->var; }
}

などと書いてプライベートプロパティなどにアクセスするのがAccessorです。アクセサの良い部分はアクセスを制限できることです。この例の$this->varはリードオンリープロパティと同じ効果があります。

しかし、クラス、プロパティが沢山ある場合にこんな風に書くのは面倒ですし、機械的な作業の繰り返しになります。

PHP 5.4

PHP 5.4からはTraitsが使えるようになるため、繰り返し書かなくてもよくなります。

https://gist.github.com/1379592

<?php
// Example code how to eliminate getter and setter methods
// with traits introduced from PHP 5.4

trait Accessors {
  public function __get($name) {
    if ($this->r_property[$name])
      return $this->$name;
    else
      trigger_error("Access to read protected property");
  }

  public function __set($name, $value) {
    if ($this->w_property[$name])
      $this->$name = $value;
    else
      trigger_error("Access to write protected property");
  }
}

class OrderLine {
  use Accessors;

  private $r_property = array('price'=>1, 'amount'=>1);
  private $w_property = array('price'=>0, 'amount'=>1);

  protected $price;
  private $amount;
  private $tax = 1.15; // property without getter/setter
 
  public function getTotal() {
    return $this->price * $this->amount * $this->tax;
  }
}

$line = new OrderLine;
$line->price = 20;
$line->amount = 3;
echo "Total cost: ".$line->getTotal();
?>

こんな感じです。これでも十分便利なのですが、Rubyにはリードオンリープロパティがあったり、C#には汎用的なアクセサの構文があります。

PHP 5.5以降

まだ構文が検討されている段階なので最終的にどうなるか分かりませんが、C#に近い感じのアクセサが実装される予定です。

class Foo
{
   protected $name { 
     get { return $this->name; }
     set { $this->name = $value; }
   }
   // ...
}

プロパティ名の後にブロックが定義できるようになり、get/setの処理が定義できるようになります。

単純なリードオンリープロパティに比べて、時間を秒に変換したり、価格を税率に合わせて税込価格にしたり、といった処理ができるのでとても便利です。書き込み時にも同様に処理が記述できます。get/setの処理がプロパティに近い場所で定義されるのでコードも読みやすくなります。

以下はそのパッチです。

https://bugs.php.net/patch-display.php?bug_id=49526&patch=accessor_v2.diff&revision=latest

以上、簡単ですがPHP 5.4とそれ以降のPHPでアクセサがどのように変わるのか紹介しました。

リンク: http://www.provephp.com/ja/

PROVE for PHP Version 1.1.0を公開しました。特に重要な変更はログデータ構造の変更と各種オーバーライド機能の調整です。

今までext3/ext4ファイルシステムの場合、ディスク容量を使い切る前にパフォーマンスが低下してしまい大きなデータを保存できませんでした。データ構造を見直す事により大きなデータでも安定して動作するようになっています。

...

新しいPROVEは数百GBのディスクでも使い切る事ができます。しかし、カーネルが古い場合はファイルシステムの管理領域のデータは使用済みと表示されません。PROVEは非常に多くのファイルを作成するため、多くの管理領域が必要となります。記録するアプリケーションの種類にもよりますが、kernel 2.6でext3/ext4の場合は25%ほどを使用した場合はディスク全体を使い切っています。btrfs/reiser4の場合はもう少し効率が良く、50%弱を使用した頃にディスク全体を使い切ります。

同じシステムでkernelだけを3.1に切り替えて空き容量を確認するとシステム管理者用にリザーブされた領域を除いてディスクを使い切っている事を確認できまます。

カーネルが誤った情報を表示してしまうのでアプリケーションで何とかするのは難しいですが、書き込みに失敗した場合はディスクフルである、とのエラーメッセージを表示できるようにするよう検討中です。

PROVEについてご意見・ご希望は私のツイッターアカウントかPROVE公式アカウント

https://twitter.com/#!/provephp

へお願いします。

まだまだいろいろ足りない機能などがありますが、順次追加していきます。これが必要！との声を頂けるとそちらが優先される場合もございます。お気軽にフィードバックを頂けるようお願いします。

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では日本語のテーブル名やフィールド名はそのままでは使えない事に気が付いた方も多いのではないでしょうか？

...

日本語や予約語の識別子が古いPostgreSQL（7.xでも）使えます。PostgreSQL９．０以前でも"(ダブルクオート)を利用して予約語や日本語テーブル名・フィールド名を持つデータベースを作る事はできました。PostgreSQLは正しい文字エンコーディングで適切なエスケープ処理を行えば安全にどのようなテーブル名・フィールド名でも利用できます。例えば、識別子の間にスペースがあっても構いません。

yohgaki@[local] test=# CREATE TABLE "日本語 table" (name text);
CREATE TABLE
時間: 380.505 ms
yohgaki@[local] test=# \d "日本語 table"
テーブル "public.日本語 table"
 カラム | 型  | 修飾語 
-----------+------+-----------
 name      | text |

これはPostgreSQL 8.4で実行した例です。このように比較的古いPostgreSQLも機能的には、どのようなテーブル・フィールド名でも使えるようになっていました。

PostgreSQL 9.0のlibpq（PostgreSQLクライアント用のライブラリ）からテーブル名・フィールド名をエスケープできる PQescapeIdentifierとリテラル（フィールドのパラメータ）をエスケープできるPQescapeLiteral関数が追加されました。 クエリパラメータの方はPQescapeStringConnというエスケープ関数が以前から利用可能でしたが、識別子のエスケープ関数はPostgreSQL 9.0で初めて追加されました。

エスケープのAPIを提供するということは「エスケープが必要である」とユーザに明示する意味もあります。あるべきAPIがやっと実装されたというべきかも知れません。

PQescapeIdentifier()とpg_escape_identifier()

PostgreSQL 9.0からはテーブル・フィールド名をエスケープするPQescapeIdentifier関数が追加されています。PQescapeIdentifier関数は文字列を識別子用にエスケープした上、ダブルクオートで囲んだ文字列を返します。

日本語\\ \"テーブル"

は次のようにエスケープされる

"日本語\ ""テーブル"

文字列がダブルクオートで囲まれ、エスケープが必要な文字(")がダブルクオートでエスケープされている事がわかります。文字エンコーディンのチェックも行っています。この関数さえ利用していればダブルクオートで囲まれ、正しくエスケープ処理された文字列が返って来ます。正しくエスケープされているのでSQL文に埋め込んでも安全です。

データベース管理アプリを作った事がある方ならよくご存知と思いますが、プリペアードクエリはSQLインジェクション対策に役立ちません。しかし、このPQescapeIdentifierを使えば確実に安全なクエリをデータベースに送信できます。

PQescapeLiteralとpg_escape_literal

PQescapeLiteralはPQescapeStringConnに代わるクエリパラメータのエスケープ関数です。動作はPQescapeStringConnと大きくは異なりませんが、確実なパラメータ処理を行う為に最初に"E"を追加しエスケープされた文字列を’（シングルクオート）で囲みます。

以下はPQescapeLiteralを利用したPHPのpg_escape_literal関数の実行例です。

[yohgaki@dev php-src]$ ./php -r 'var_dump(pg_connect("host=127.0.0.1 dbname=test"), 
     pg_escape_literal("日本語 テキスト"));'
resource(4) of type (pgsql link)
string(26) " E'日本語 テキスト'"

データベースアクセス抽象化レイヤーには文字列をエスケープしてシングルクオートで囲む、quote()メソッドが実装されている事がありますが、それらの関数と同様の動作を行います。

C言語でプログラミングしていればPQescapeStringConnの方が便利である事も多いのですが、文字列の取り扱い（連結）が容易なスクリプト系の言語ではPQescapeLiteralの方が便利が良いです。

名前がEscape Literalとなっているのは良い命名だと思います。プリペアードクエリを使わずにSQL文やその一部を作る場合は、数値、日付、文字列、全てのパラメータ（リテラル）をエスケープ処理してから送信すべきだからです。この名前であれば初心者にありがちな「数値なのでエスケープ処理をしない」といった誤りを防止できると思います。

PHPのpg_escape_identifier()とpg_escape_literal()

PQescapeIdentifierとPQescapeLiteralはPostgreSQL 9.0以降のlibpqで利用できますが、PHPのpgsqlモジュールは9.0未満のlibpqとコンパイルした場合も利用できるようになっています。

PHPのpg_escape_identifier()とpg_escape_literal()は便利そうだ！と思った方。申し訳ないです。私が関数を実装していなかったので次にリリースされるPHP 5.4.0にも入っていません。もしかするとPHP 5.4.1には入るかも知れませんが、どうなるかはまだ分かりません。

どうしても使ってみたい方はPHPのsubversionレポジトリからpgsqlモジュールのソースコードをダウンロード＆コンパイルして使ってください。

よく誤解されるので念の為に書いておきます。もともと私はプリペアードクエリを使うな、と言っている訳ではありません。プリペアードクエリが使える場合はどんどん使えば良いと言っています。パフォーマンスにはうるさいので効率が良いプリペアードクエリの利用を薦めるのは当然です。

しかし、プリペアードクエリの使用が解決策になっていない場合が多くあります。趣味でシステム開発をしているならともかく既存のコードは会社の資産であり、様々な要素から検討した結果としてプリペアードクエリを使わないコードを採用することもよくあります。ROIを最大化するのが会社ですから当然です。このような場合にプリペアードクエリを使え、特定のORMを使え、特定の抽象化レイヤーを使え、NoSQLを使え、といっても何のソリューションにもなりません。

私も好んで使ってるプリペアードクエリですがセキュリティ対策とはしては、これだけでは不完全です。識別子のエスケープの例からも明白なように、プリペアードクエリは万能ではありません。プリペアードクエリは完全なセキュリティ対策を行う為に開発された物ではないので、完全でなくても文句は言えません。正しくSQLデータベースを利用するにはエスケープ処理を正しく知ることが最も重要です。セキュリティ対策として不完全なプリペアードクエリの利用が最も重要では無いことは、不完全であることからも明らかです。（出力のセキュリティ対策についてはこのブログにも書いているのでそちらをどうぞ）

今回はセキュリティ対策の為のエントリではないですがまとめです。

データベースに限らず全ての出力先のエスケープ処理を正しく理解する事が出力セキュリティ対策における最も重要です。エスケープ方法を知ること＝出力先への正しい出力（安全な出力）知ること、です。なかなか浸透しないので繰り返し書く事になっているのは残念ですが、この事を理解して実践すれば、SQLインジェクションに限らず、出力時にセキュリティホールを作ることを減らす事ができます。

最後にエスケープ方法を知ればほとんどの出力先に対する正しい出力（安全な出力）方法を知ることができます。しかし、それが全てではありません。これについては既に書いた記事もありますが、またそのうちこのブログか技術評論社さんの記事として改めて書くことにします。

昨日は第一回の岡山PHP勉強会お疲れ様でした。参加枠を何度か拡大しても60名の満席でした。初回ということでプログラマ目線からのセキュリティ対策の基本を解説させていただきました。セキュリティってわかりづらい、何をすれば良いのかわからない、という声はよく耳にします。短い時間でしたが考え方の基本は概ね説明できたと思います。

重要なことは口頭で説明したので資料だけみてもよくわからないとは思いますが、勉強会の資料を公開します。なにかございましたらツイッターなどで問い合わせて下さい。ツイッターには岡山PHP勉強会のハッシュタグ (#okaphp) を付けると他の方にも分かりやすいと思います。

次回の岡山PHP勉強会は2月だそうです。

追記：Integrityの訳はネットを検索してきた訳語の「統合性」を使っていましたが、違和感があったので調べてみました。JISでは「完全性」と訳されているので正しい用語に修正しておきました。

PHP Advent Calender用のエントリです。

PHPのセッション管理は非常に簡単です。セッションをsession_start()で開始して$_SESSION配列を使うだけです。便利で簡単なセッションモジュールですがセッションアダプションに脆弱であるため、一般に言われてる「ログインする時にはsession_regenerate_id()を呼ぶ」コーディングではセッションアダプションに脆弱になってしまいます。

まずは危険性と対策を紹介します。

...

セッションアダプションの危険性

セッションアダプションとは外部などから設定されたセッションIDを受け入れ初期化する脆弱性です。一番分かりやすい例はTrans SIDを有効にして

http://example.com/index.php?PHPSESSID=1234567890

とアクセスするとセッションIDが"1234567890”として初期化されます。他のページからのリンクでも初期化される（php.iniでRefererを設定して制限も可能）ので、本来秘密であるべきセッションIDを攻撃者が知ることになります。Trans SIDを利用している場合、session_regenerate_id()を呼べば確実に新しいセッションIDが設定されるのでセッションアダプションによってセッションIDの固定化が起こる事はありません。

セッション管理にクッキーを利用している場合は違います。例えば、アプリケーションapp1がhttp://example.com/app1/ にインストールされていてセッション管理用のクッキーのパスが/app1/に設定されている場合、何らかの方法で/にセッション管理用のクッキーを設定すると、/app1/ではなく/に設定されたクッキーが有効になります。session_regenerate_id()でパス /app1/ に対して何度新しいクッキーを設定しようとしても/に設定されたクッキーが送信されます。

PHPのデフォルトはdomainに対してクッキーを設定しませんが、domainに対してクッキーを設定するとそちらを優先してしまうブラウザ（IE）があります。例えば、www.example.co.jpの場合、何らかの方法でwww.example.co.jp、example.co.jp、co.jpなどにセッション管理用のクッキーを設定できればそれが優先されてしまいます。

co.jpにはクッキーは設定できないのでは？と思った方も居るでしょう。しかし、IPアドレスが返ってくればco.jpにもクッキーが設定できてしまいます。この仕様を利用すれば同僚のブラウザのセッションを簡単に盗む事ができます。PCのhostファイルを編集し、co.jpにIPアドレスを割り当てた上でグラウザに攻撃用のクッキーを設定するだけです。明示的にクッキーを削除するかクッキーの有効期限が切れるまで憐れな同僚はセッションが漏れた状態になります。

セッションアダプションに脆弱なセッション管理では比較的安全とされているクッキーベースのセッション管理の場合、Webアプリセキュリティの要であるセッションを盗む事が可能となるのです。

対策

session_regenerate_id()だけではセッションアダプション脆弱性を利用したセッションの固定化攻撃を防ぐ事はできません。既に対策にはついてはブログに書いているのでこちらを参照してください。

http://blog.ohgaki.net/how-to-make-php-session-strict-by-php-script

セッションアダプション克服への道のり

セッションアダプション対策はまだリリースされているPHPには取り込まれていませんが、もうすぐsubversionレポジトリにコミットする事ができます。

パッチ: https://gist.github.com/1379668

WikiのRFC： https://wiki.php.net/rfc/strict_sessions

セッションアダプション対策への道のりは非常に長いものでした。その概略を紹介します。

2005年夏

• Stefan Esser氏がPHP 5.1用にStrict SessionパッチをMLに投稿。
• ちょうどPHP 5.1.0のリリース前だったので取り込まれると思っていた。
• MLのスレッドは全ては見ていなかったので推測ですが、セッションアダプション脆弱性とブラウザの仕様が理解されていなかったのだと思われる。

セッションアダプションが致命的な脆弱性であることは今も昔も変わりません。6年以上前の事になりますがセッションアダプションは当時でも危険と認識されている問題でした。（少なくともセキュリティ専門家には）

2005年秋

• Stefan氏のパッチの一部が取り込まれる。（後に役に立たない実装だと判明）
• 対策済みと考えていた為「Webアプリセキュリティ対策入門」にもユーザスクリプトによる対策は記載しない。。。

コミットログの差分を斜め読みしていたため、完全にパッチが取り込まれたと勘違いしていました。

2006年春

• Stefan氏のパッチが完全に取り込まれておらず、役に立たない実装だと気づく。
• PHPのsecurity用のメールにStefan氏のパッチが取り込まれていない事に対して適用すべきとメールを送るが、開発者の理解をえられず適用されない。

2006年11月

• PHP 5.2.0リリース。依然としてパッチは取り込まれない。

2007年初め頃(?)

• PHP 5.2用にパッチが無いのは困るので5.2にポート。
• 桝形さんがPHP4用にパッチをバックポート。
• http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession

2007年夏

• PHPプロジェクトメンバーのセキュリティ認識に辟易していたStefan Esser氏がMonth of PHP Bugsプロジェクトを開始。
• 私は日本語に翻訳。 http://blog.ohgaki.net/MoPB/

2008〜2009年頃

• PHP 4のメンテナンス終了のアナウンス。
• そろそろセッションアダプション脆弱性への理解も深まったかと思い、securityのメールアドレスへ厳格なセッション管理をするようにメール。
• しかし、理解を得られず。。。

2011年秋

• PHP 5.4.0のリリースに合わせ厳格なセッション管理を行わない事はセキュリティ問題だとPHP開発者のMLに送信する。
• 遂にセッションアダプションの致命性が理解されたのか、今までと違い必要ない、無用である、現状の機能で十分、ユーザが悪い、とする反論は一切なし。
• 現在、パッチは議論中のステータスで反論もない状態で年内中にはtrunkにコミット、PHP 5.4.1とPHP 5.3.10（何時になるかな）には取り込まれる見込み。

セッションアダプションが致命的な脆弱性であることは少しブラウザのクッキーで実験してみれば分かることだと思うのですが、6年を越す歳月が必要でした。

これは酷い！と思った方も居るかも知れませんがこういう事は他のプロジェクトでもよく起きています。商用製品でも10年前から知られていた脆弱性がやっと直った、などと時々ニュースになっている事を記憶されている方も居ると思います。10年かかった訳ではないのでまだ良い方でしょう。

まとめ

• セッションアダプションは致命的な脆弱性
• セッションアダプション対策はユーザスクリプトでも可能
• プログラミング能力が高いプログラマでもセキュリティ脆弱性の評価を適切にできない場合がある
• セキュリティに対して意識が高い開発者の意見は素直に受け入れるべき

PHPプロジェクトがStrict Sessionパッチを素直に受け入れられなかった理由の1つは、一部の開発者が「セッションアダプションなんてたいした脆弱性ではない」と間違った主張を以前からしていた事に原因があるのではないか、と思っています。

「サニタイズで十分」「プリペアードクエリを使えば安全」といった認識と同様、周りの人にこれで十分、と言っていた人はなかなか意見を変えません。それが間違った意見や合理的ではない意見であったとしても変えない事があります。

この様な状況に陥ると正しいセキュリティ対策が採用されるまでに非常に長い時間がかかってしまいます。そうならないよう「あ、こっちの方が良いかも」と思ったら昔の意見は封印するのが最も良いと思います。

リンク: http://www.php.net/manual/en/language.types.array.php

PHP 5.4 Advent Calender 2011用のエントリです。（まだ空きがあるので是非どうぞ）

このエントリを書いているのは11/23です。初めの方から重いネタだと後の方が苦労する（？）ので軽い話です。

現時点ではPHP Manualの配列のページには記載されていませんが、配列の定義が簡略化されます。まず現状の配列の定義方法は

<?php
$a = array('foo'=>123, 'bar'=>456, 789);
var_dump($a);

こんな感じですね。これを実行すると

$ ../php-src-5.4/php arr.php 
 array(3) {
 ["foo"]=>
 int(123)
 ["bar"]=>
 int(456)
 [0]=>
 int(789)
 }

このような出力になります。array()と定義するのは面倒だ、との声は昔からあったのですが遂に[]で配列が定義できるようになりました。つまりこう書けるようになります。

...

<?php
$a = ['foo'=>123, 'bar'=>456, 789];
var_dump($a);

こんな風に配列を定義するならarray()でも構わないのですが、関数のパラメータなどに配列を直接渡す場合は今ひとつしっくりこない形になります。例えば、pg_query_params()関数はクエリのパラメータを配列で渡すのですが今まではこうなります。

$res = pg_query_params($db, 'SELECT * FROM tbl 
　　WHERE age >= $1 and gender = $2', array(20, 'm'));

これを

$res = pg_query_params($db, 'SELECT * FROM tbl 
　　WHERE age >= $1 and gender = $2', [20, 'm']); 

と書けるようになります。

細かい仕様変更ですが「なぜ配列定義が[]でできないの？」という声はずっと以前からありました。しかし、「PHPはPeople Hate Perlの略だ」と言われる所以からか「同じ事をするために複数の構文は要らない」とのポリシーで実装されませんでした。

「記号のような構文も要らない」とのポリシーで"<?="と同じ動作する"<?php="は実装されていません。これは私もパッチ付きで提案しました。1行パッチなのでたいした物ではないですが、"<?="があるのに"<?php="が無いのはおかしい、と思う人は他にもいて何度も提案されました。結局、5.4でも採用されていませんが、代わりに"<?="が何時でも使えるようになりました。これでテンプレートなどの中で気軽に"<?="が使えます。

話があさっての方向に行ってしまいましたが配列の落とし穴も紹介します。

PHP 5.4の配列オペレータ[]は文字列のオフセットにアクセスする方法として統一的に動作するようになりました。一時期は文字列オフセットには{}を使うべき、という頃もあったのですが[]でアクセスする方法が標準になります。この変更で従来とは異なる動作になってしまう場合があります。

<?php
$s = 'abc';

if (isset($s[0][0])) {
 echo 'Value is set!';
} else {
 echo 'Value is NOT set!';
}

PHP 5.4の場合

Value is set!

PHP 5.3の場合

Value is NOT set!

と逆の結果になります。これはPHP 5.4からは$s[0]は文字列の一文字目"a"となり$s[0]の"a"の更に一文字目の$a[0][0]も"a"になるからです。配列オペレータで文字列にアクセスした場合の動作に整合性を持たせた結果こうなりました。

先ほどの例では分りづらいですが配列の中の要素の更にその中の要素が空であるかチェックするようなコードが動作しなくなります。PEARライブラリの中では結構これが多用（？）されているらしくPEARの中の人がクレームをつけていました。詳しくは次のバグレポートを見てください。このブログのエントリを書いている今、議論が行われているので何か変更があるかも知れません。

https://bugs.php.net/bug.php?id=60362

言語として整合性が取れたことは良いことですが、思わぬところに落とし穴もあるので注意が必要です。

追記：

https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323002696

どうもNoticeエラーが出るようになりそうです！エラーがないと分りづらいのである方が良いと思います。

ちなみにPROVE for PHPがPHP 5.4に対応すれば、仕様変更がアプリケーションに影響するか、どこで違いが発生したのか即座にわかります。このエントリが公開される頃には、、、まだ公開できていないと思いますが、PHP 5.4リリースを機会に是非PROVEを試してみてください。

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インジェクション対策では「エスケープ」を最初に解説しています。何が正しいのか、考え方の基本として正しいものはどう反論しても正しいので無駄な努力はやめた方が良いと思います。

追記 安全なSQLの呼び出し方（全40ページ、714KB）

この文書ではまずリテラルのエスケープ方法から解説し、3.3のまとめの図では正しく、エスケープで組み立てるしか無い場合はそちらを優先し、次にプログラムクエリが使える環境ではプリペアードクエリなどを使うような図になっています。RailsでもPHPのフレームワークでも同じですがquoteメソッドを使う場合、実際にはエスケープしています。エスケープを正しく理解していないとこれらの実装が正しいのかプログラマが判断できないので適切な解説だと思います。残念なのはPostgreSQLのエスケープ手法が解説されていない点です。今のPostgreSQLはSQL標準に則り、'(シングルクオート）は'（シングルクオート）でエスケープします。libpqにはリテラルを正しくかつ完全に処理できるようエスケープするPQescapeLiteralが追加されています。(PHPではpg_escape_literalとして利用できるようになります） これでエスケープすると E'文字列' という形でエスケープを行い、SQL標準のエスケープである事が明示されます。おかしな使い方でSJISテキストを使っても誤作動することが無いようになっています。APIをサポートするプラットフォームがまだ少ないからこれは仕方がない部分でしょう。あって当然だった識別子のエスケープも解説されていないのは残念ですね。一般論として識別子のエスケープについては解説があった方がよいでしょう。プリペアードクエリを使っていてもエスケープが必要なケースです。紹介しないと完全な解説にはなりません。

同じ事はサニタイズに対する批判でも起きています。入力サニタイズがセキュリティ対策の切り札のように言われていた頃、私はホワイトリスト方式に入力のバリデーションこそが正しいセキュリティ対策で、ブラックリスト方式のサニタイズは不完全で誤った対策である、と言っていました。いろいろ反論もありましたが現在では「入力はバリデーションすべき」に反論する人はほぼ居ません。出力対策はエスケープが基本である、という持論に反対された方も多いですね。しかし、出力対策はエスケープが基本であるとすることに反論するようでは、分かってない人と思われるようになる日も遠くはないでしょう。

しかし、ネガティブなコメントには具体的な誤りの指摘や反論が皆無ですね。はてブの文化なのでしょうか？はてなのサービスは悪いものではないように思いますが、今ひとつメジャー感が出てこないのはこういう部分に原因があるのかも知れないですね。

PHP 5.3.9RC2とPHP5.4.0RC2がリリースされました。

ところで、公式WikiのリリーススケジュールによるとPHP 5.3.9のEOLはPHP 5.4.0のリリース後半年後に予定されています。

https://wiki.php.net/rfc/releaseprocess

1年後にはセキュリティパッチの提供も停止の予定です。私は期間が短すぎると思いますが、、、 皆さん、マイグレーションの準備をしましょう。

...

Hello!

You are receiving this email because your project has been selected to
take part in an effort by the PHP QA Team to make sure that your project
still works with PHP versions to-be-released. With this we hope to make
sure that you are either aware of things that might break, or to make
sure we don't introduce any strange regressions.

Two release candidates where released today. PHP 5.3.9RC2 and PHP
5.4.0RC2. They can be downloaded from:

http://qa.php.net/

The Windows binaries are available at

http://windows.php.net/qa/

PHP 5.3.9 is our upcoming stable release. Please test your code and
report any regression bugs.

PHP 5.4.0 will be our next upcoming major release. It includes a lot of
new features. Please test your code carefully against the new version to
hlep us releasing the stable PHP version.

For a list of new features and bugfixes that you can target in your testing, please
refer to the NEWS file:

For PHP 5.3.9RC2:

http://svn.php.net/viewvc/php/php-src/tags/php_5_3_9RC2/NEWS?view=markup

For PHP 5.4.0RC2:

http://svn.php.net/viewvc/php/php-src/tags/php_5_4_0RC2/NEWS?view=markup

The next release candidate will be released on December 8.

Regards,
Johannes, Stas and David

HTTPセッションは通常クッキーを利用して行います。クッキーを利用したセッションの場合、お薦めする設定は以下の通りです。

1. ドメイン名は指定しない
2. パスはルート(/)を指定する
3. セッション管理用のクッキーはセッションクッキー（有効期間０）にする
4. httponly属性を付ける
5. 可能な場合は必ずsecure属性をつける
6. 複数アプリケーションを利用する場合はsession.nameまたはsession_name()でセッションクッキー名で指定する　（アプリケーションの固有名デフォルトで設定し、設定項目として変更できるようにする）

...

３まではPHPデフォルト設定です。４から６までは自分で設定しなければなりません。PHPの場合、すべてphp.iniで指定できます。session_set_cookie_params()でセッション開始前に指定すればスクリプト中から変更できます。

void session_set_cookie_params ( int $lifetime [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]] )

１のドメイン名はわざわざ指定する意味はありません。デフォルト通り指定しない方が良いです。完全ではありませんが、ドメインを指定しない方が問題が少ないので指定しないようにします。

２のパスですが、アプリの中にはURIパスを検出してパスを設定してクッキーを送るようにしている物もあります。ルート（/）とサブディレクトリ（/app1/など）にクッキーが設定されている場合、ルートの方が優先されるので安全面を考えるとルートの方が良いです。

３は常識として知っておくべき知識です。クッキーの有効期限が０の場合、普通のブラウザはクッキーをメモリにみ保存します。つまりブラウザを終了させるとクッキーが消えます。セッション管理には必ず有効期限０を指定すべきです。

４のhttponlyはデフォルト有効でも良いような気がしますが、フレームワークでCSRF対策に使っている場合もあるかも知れません。しかし、 PHPアプリでJavascriptとセッションIDを使ったCSRF対策を行っているものは少数派だと思います。4は基本有効にする、という考え方で良 いと思います。

５はSSLをサポートしたサイトのみですが、最近のgoogleのように全てSSLにする場合は必須です。SSLしか使わないのであれば必ず有効にします。

６の代わりにクッキーにパスを設定するアプリもありますが、パスを設定するのではなく、セッション名を設定した方が良いです。

次はやってはならないことです。

1. 有効期限の長いセッションを再ログイン用に使う
2. Trans SIDを不要なのに有効にする

１はありがちな事です。有効期限の長いセッションによい事はありません。例えば、公共のPCや友人のPCを使った時にブラウザを閉じてもまだログインした状態が続くのは良くありません。自動ログインを有効にする場合は別の使い捨ての認証用クッキー（再認証用のトークン）を用い、ログインする場合に自動ログインするか、しないか選択できるようにしてユーザが制御できるようにします。ユーザが明示的にログオフした場合は再認証トークンも必ず無効にします。

２のTrans SID(URLの書き換えによるセッション）を絶対に利用してはならない、とは言いませんが特別な理由がない限り有効にしてはなりません。ページやURLをメールなどで送信するとセッションIDが漏洩します。

最後にセッションIDは少なくとも定期的にsession_regenerate_id()で更新すべきです。ログインした時の更新は必須です。

1. ログインした時
2. ログアウトした時　（これは必須ではないが念の為）
3. 一定時間経過した時　（数分から数時間の間隔で更新）

Piece Framework にはリクエストのたびにセッションIDを更新する、という素晴らしい機能も付いています。万が一セッションIDが何らかの理由で漏洩しても、ユーザがアクセスさえしていればセッションIDが更新されているのでセッションを盗まれる事はありません。Trans SIDを利用していても比較的安全に利用できます。

PHPの設定を例に紹介しましたが、他のプラットフォームでも基本的には同じです。

リンク: http://php.net/manual/en/features.commandline.webserver.php

PHP 5.4からCLIのphpコマンドにビルトインWebサーバ機能が追加されています。

ツイッターでWebrick（RubyのビルトインというかRuby製のWebサーバ）＋素のRailsページはjRubyで44reqs/sec、cRubyで98reqs/secでした、とのツイートを見かけて、PHPのビルトインWebサーバはどの程度かな？と思って手元のマシンで実行してみました。

...

abコマンドを使ってローカルホストのnull.phpという空のPHPファイルにアクセスしました。

[yohgaki@dev ~]$ ./sapi/cli/php -S localhost:8008 > /dev/null 2>&1
[yohgaki@dev ~]$ ab -n 10000 http://localhost:8008/null.php

結果はこちらです。

Requests per second:    4437.26 [#/sec] (mean)

追記１： 同時接続数130くらいまではスケールするようです。 -c 130 (当時130接続）、-n 100000(10万）で試すと5500reqs/secでした。ただしマルチプロセス・マルチスレッドではないので複数コアがあっても1コアしか使いません。nginxなどと組み合わせると複数コアCPUでは数倍の性能が見込めると思われます。

追記２： 念の為に書いておきます。プロダクションサーバ用に使わないでください。Watch Dog(プロセスを監視して死んだら再起動させるプログラム）がないとPHPのクラッシュバグでDoS攻撃が可能になります。

環境も違うし、Railsの方はRubyコードを実行しているので比較になりませんが、テストコードを動かすには十分過ぎる速度です。実行したのはCore2Quad Q6600という比較的古いCPUのマシンです。

model name    : Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz

以下はabコマンドを実行したときのログです。

[yohgaki@dev ~]$ ab -n 10000 http://localhost:8008/null.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        
Server Hostname:        localhost
Server Port:            8008

Document Path:          /null.php
Document Length:        1 bytes

Concurrency Level:      1
Time taken for tests:   2.254 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1190000 bytes
HTML transferred:       10000 bytes
Requests per second:    4437.26 [#/sec] (mean)
Time per request:       0.225 [ms] (mean)
Time per request:       0.225 [ms] (mean, across all concurrent requests)
Transfer rate:          515.66 [Kbytes/sec] received

Connection Times (ms)
 min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       1
Processing:     0    0   0.1      0       3
Waiting:        0    0   0.0      0       2
Total:          0    0   0.1      0       3

Percentage of the requests served within a certain time (ms)
 50%      0
 66%      0
 75%      0
 80%      0
 90%      0
 95%      0
 98%      0
 99%      0
 100%      3 (longest request)
[yohgaki@dev ~]$

パッチのテストのお願いです。

PHPerの長年の悩みの種であるセッションアダプションを修正するパッチをPHPに取り込めそうです。PHPのsubversionレポジトリのtrunkまたはPHP 5.4で利用できます。テストが終わったらPHPのレポジトリにコミットする予定です。（テスト期間は2011/11/22まで）

パッチ

• https://gist.github.com/1379668

少し古いですがパッチの解説

• http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession

セッションアダプション関連のブログエントリ

• http://blog.ohgaki.net/how-to-make-php-session-strict-by-php-script
• http://blog.ohgaki.net/php-session-adoption-1

パッチに何か問題があったらご連絡頂けると助かります。問題なかったよ、も大歓迎です。

ツイッターの方がレスポンスは良いです。

• https://twitter.com/#!/yohgaki

メールご連絡頂いても構いません。ブログのコメントととして送信する場合はエラーメッセージを無視して送信してください。モデレーションが必要なコメントとして送信できます。

思い起こせばセッションアダプション脆弱性の修正は最初の提案から６年以上経っています。セッションアダプションとブラウザの仕様に関する理解を得られず今まで修正されてきませんでした。しかし、今回は修正できそうです。SQLインジェクション対策や入力のバリデーション処理もそうですが、正しいものは正しい。主張し続ければ時間はかかっても必ず正しい方が認められるのが世の中です。

今度こそPHPのアキレス腱であるセッションアダプション脆弱性を修正しましょう！

テストが可能な方は是非テストして頂けるよう、よろしくお願いします！

リンク: http://www.provephp.com/

私の会社で開発・販売しているPROVE for PHPを更新し、PDOオブジェクトに対応したPROVE for PHP 1.0.3の配布を開始しました。PDOオブジェクトに対応したので幅広いアプリケーションで利用できます。PROVEは非商用の個人利用の場合、無償で利用できます。問題などございましたらツイッターやメールなどでフィードバックを頂けると助かります。

http://www.provephp.com/ja/download

PROVE for PHPとはPHPの動作を詳細に記録・比較し、PHPとPHPアプリのバージョンアップが安全に行えるか簡単にチェックできるツールです。開発中のリグレッションテストツールとして利用できます。

近日中にこのブログでもいろいろな使い方を紹介したいと思っています。

追記： RHEL5系（CentOS5など）で利用できるPHP53パッケージ用RPMのダウンロードも開始しました。

PHP5.4からtraitが利用できるようになる事をご存知の方も多いと思います。

traitはコードの水平再利用を可能にする仕様拡張です。Rubyのmixinのような機能と言えば分り易いかも知れません。

誰でもtraitを利用したくなるようなコードをinternals@php.netのMLで見かけたので紹介しよう、と思って書いたのですがコピペしたコードをしっかり読んでなくておかしな所があった事を @sotarok さんに教えてもらいました。

元のコードは色々問題があるので書き直しました。こうやればアクセサーを沢山書く必要が無くなります。

...

https://gist.github.com/1379592 （読みやすいコードはこちらをどうぞ）

<?php
trait Accessors{
 public function __get($name){
  if ($this->r_property[$name])
   return $this->$name;
  else
   trigger_error("Access to read protected property");
 }
 
 public function __set($name, $value){
  if ($this->w_property[$name])
   $this->$name = $value;
  else 
   trigger_error("Access to write protected property");
  }
}

class OrderLine{
 use Accessors;

 private $r_property = array('price'=>1, 'amount'=>1);
 private $w_property = array('price'=>1, 'amount'=>1);
 
 protected $price;
 private $amount;
 
 public function getTotal(){
  return $this->price * $this->amount;
 }
}

$line = new OrderLine;

$line->price = 20;
$line->amount = 3;

echo "Total cost: ".$line->getTotal();
?>

これをPHP 5.4で実行すると

Total cost: 60

と表示されます。

niigataの強敵現れる？！という事ではなく、個人的な好みとしてはread only属性が在ったほう便利だと思います。

注）niigataとは読めるけど書けないプロパティを作る、という昨年のPHPカンファレンスで発表されたPHPの拡張パッチです。多くの日本人は新潟を読めるけど、正しく書けない、という現実にちなんでつけられた名前だそうです。

さすがにniigataじゃ受け入れてもらえないだろうから普通の名前を考えるとしたら何が良いかな？

リンク: https://github.com/yohgaki/bit

誕生日のメッセージを送ってくださった皆様ありがとうございました！

今日は誕生日ということで多少は趣味のOSSに時間を割いてもバチは当たらないだろう、という事で簡単なPHPモジュールを書きました。PHP勉強会＠東京に参加してPHPerバイナリアンの方の発表に触発された事がこのモジュールを書いた動機です。BitモジュールはバイナリアンPHPerの為のモジュールです。

https://github.com/yohgaki/bit

関数は今のところ４つだけあります。

• string byte_get(string) - バイナリをHEX文字列に変換
• string byte_set(string) - HEX文字列をバイナリに変換
• string bit_get(string) - バイナリを0と1の文字列に変換
• string bit_set(string) - 0と1の文字列をバイナリに変換

PHPではバイナリを取り扱う事が面倒だったのですがこのモジュールを使えば比較的簡単にバイナリを修正する事ができます。

初めはバイナリを配列にして返そうか、とも思ったのですが効率が悪いので単純に文字列に変換することにしました。こんな機能が欲しい！こう修正して欲しい！という方はご連絡ください。対応できるかも知れません。

ちなみに現状でもPHPスクリプトだけでバイナリを取り扱えるライブラリがあります。

http://openpear.org/package/IO_Bit

さらにZlibバイナリが扱えてしまう物まであります。

http://openpear.org/package/IO_Zlib

そしてSWFファイルを修正できてしまう物も。

http://openpear.org/package/IO_SWF

これらは@yoya さんが書かれたパッケージだそうです。凄すぎです。バイナリを操作する必要がある方はこちらも是非ご利用ください。

リバースプロキシの背後にあるPHP用に$_SERVER['REMOTE_ADDR']をX-Real-IPやX-Forwarded-Forヘッダに設定されたIPアドレスに書き換えるRealIPを書きました。

https://github.com/yohgaki/realip

少しGoogleで検索しても見つからなかったので作ったのですが、既にありそうな気がします。

PHPスクリプトで書き換えても良いのですが、アプリをバージョンアップした時に忘れる可能性があります。プロキシ・Webサーバで何とかする方法もありますが、プロキシ・Webサーバの仕様に合わせた設定が必要だったり、と不便な所もありモジュールの方が便利なので書きました。同じ事をするには他の方法がありますが、必要な方はどうぞ。

多分、PHP5.2でもコンパイルできると思います。コンパイル出来なかったら教えてください。

PHPのスクリプトを使ってアダプティブなPHPセッションをアダプティブにしない方法を紹介します。

このブログで紹介していたかどうか覚えていないですが、セッションアダプション対策としてsession_regenerate_id()が導入された時に議論・紹介されているので知っている方も多いと思います。（というより、PHPerの常識ですよね？）

まずはセッションアダプションの原理と対策の復習をしておきます。

...

• 原理： 未初期化のセッションIDを受け入れる
• 対策： 初期化済みセッションIDのみ受け入れる

session_regenerate_id()は新しいセッションIDを生成して新しいセッションクッキーを作成して、セッションデータを保存するようになっています。session_regenerate_id()を呼んだだけでは、なんらかの方法で複数のセッションクッキーがドメイン・パスに設定されている場合、セッションクッキーが更新できない場合があります。この場合、PHPモジュールは同じセッションクッキーで初期化してしまいます。

ユーザ（スクリプト）側でセッションIDが初期化済みであるかどうか確認する事は簡単です。session_regenerate_id()を呼んだ後に、セッション配列（$_SESSION）に何らかの目印を埋め込んでおけば十分です。例えば、こんな感じです。

session_destory();
session_regenerate_id();
$_SESSION['vaild_id'] = session_id();

このようにセッションクッキーが新しくなるように設定してセッションを利用する前に

if ($_SESSION['valid_id'] !== session_id()) {
die('Invalid use of session ID');
}

などと処理します。簡単ですね。念の為に何故これで大丈夫なのか解説しておきます。

上記の手順でセッションIDを設定し、セッション配列を確認すると、外部からセッションIDが与えられたり（URLリライターの利用など）した場合、セッションが破棄されます。セッションIDが再生成された後、セッション配列にPHPで初期化済みである目印としてセッションIDを保存しています。実際にセッションを利用する際に目印が正しいかチェックすると、アダプティブでない厳格なセッション管理が行えます。

私がWebアプリセキュリティ対策入門を書いていた頃はPHP本体でセッションアダプション対策が行われる（行われた）、と考えていたので本の中では紹介しませんでした。セッションモジュールに最初からsession_regenerate_id関数が無かったので、この様な対策を行っているアプリは無かったですし、ユーザ側の対策では対策に漏れが出る事は火を見るより明らかです。既に提案されていた厳格なセッション管理パッチがPHP本体に採用されるのは当然だ、と思っていました。

ユーザ（スクリプト）側でのセッションアダプション対策は既に紹介した通り比較的簡単です。しかし、簡単であってもユーザ（スクリプト）側での対策には問題もあります。

• ユーザ側での対策なので実装されていない可能性がある
• ユーザ側での対策なので実装したつもりでも正しく実装されてない可能性がある
• 他の環境（Java, Ruby, Python,etc）ではセッションアダプション対策が行われているのでWeb開発経験者でも間違える可能性が高い。
• 初めてPHPでWebアプリ開発を行う場合、間違える可能性は更に高い。
• 対策を行っていないアプリが結構あると推測される。

PHPのセッションモジュールでセッションアダプ対策を実装していた方が簡単なだけでなく確実です。セッションモジュールで対策されていればセッションアダプション対策にsession_regenerate_id()を呼ぶ必要さえありません。

最近のPHPアプリの動向を詳しく調べていないので推測ですが、このエントリで紹介された対策を現在でも行っていないアプリが多数存在すると思われます。

PHP開発者はセッションアダプションの問題はユーザ側の問題である、としていますがセッションモジュールを少し改良するだけでアダプション脆弱性問題を全て解決できます。ユーザ側での対策には限界があるのでプラットフォームで対応すべきだと私は考えています。セッションモジュールの改良に副作用もありません。PHPのセッションモジュールのアダプション脆弱性が修正された場合でも、ここで紹介した対策を実装していても何の問題もありません。（一部のアプリに影響する事は知っていますが、特殊なアプリです。一般的なアプリが犠牲になるより特殊なアプリの方で対策すべきでしょう）

セッションアダプション脆弱性を修正すると、セッションを盗まれるリスクの代わりにDoSのリスクが発生します。しかし、これは私が時々紹介している「全てのドメインとパスに設定されているセッションクッキーを削除する」対策を行えばかなりリスクは軽減できます。特定ユーザに対するDoSのリスクがあるとは言っても、セッションを盗まれるリスクの2択でどちらを選ぶか？迷う人は居ないと思います。

最近のフレームワークを利用して開発している方は多分大丈夫だと思いますが、最近のフレームワークを使って開発している方もそうでない方も、セッションIDの管理がどのような実装になっているか確認すると良いと思います。

PHP 5.4 RC1が公開されています。PHP 5.4のリリースが近いです。PHP 5.3の--enable-zend-multibyeの問題でバグレポートをした関係でinternals MLでメールのやり取りをして分った事とその他をまとめておきます。主にSJISを使う場合の注意点です。間違い・勘違いもあるかも知れないので気が付いたらコメントを下さい。

• PHP 5.4はデフォルトの内部エンコーディングがISO-8859-1になる
• SJISでコードを書く場合はzend.script_encoding=SJISを書く
• SJISでコードを書く場合は内部エンコーディングをSJIS(mbstring.internal_encoding=SJIS)に設定する
• SJISで出力する場合はmbstring.http_output=SJIS (output_handler=mb_output_handlerなどが必要）を設定する
• SJISでページを書いている場合、SJISが入力になるのでmbstring.http_input=SJISを設定する
• Zend Multibyteサポートがコンパイルオプションからランタイムオプション（zend.multibyte=On）になる
• Zend Multibyteサポートにはmbstringが必須
• mbstringがモジュールとしてビルドされている場合でもZend Multibyteサポートを有効にできる
• declare(encoding=...)でスクリプト中からスクリプトのエンコーディングが指定できる

php  -c php.ini-development -d zend.multibyte=1 SJIS_script.phpとしてSJISが含まれるスクリプト（例えば、echo "表")を実行するとSJISの文字が?に変換されてしまいます。正しく処理するには-d mbstring.internal_encoding=UTF-8などを追加し

php  -c php.ini-development -d zend.multibyte=1 -d mbstring.internal_encoding=utf-8 SJIS_script.php

などとしなければなりません。

全般的にマルチバイト文字エンコーディングのサポートが改良されていますが、以前と多少異なる部分があるので注意が必要です。

久しぶりにブログを更新すると色々書きたくなるものですね。ということでまだこのブログでは紹介したことがないDOMベースXSSのオープンソースツール、DOMinatorを紹介します。最近の商用ツールも類似の機能をサポートしています。

http://code.google.com/p/dominator/

DOMベースXSS： JavascriptはDOMを利用してHTMLを動的に変更できます。この機能を利用するとブラウザ側のJavascriptで動的に変化するWebサイトを構築できます。HTMLなどを修正するとデータにユーザが入力が含まれているとプログラマが意図しないJavascriptが実行できます。

要はクライアントサイドのJavascriptインジェクション攻撃の事です。

Javascriptは非常に柔軟な言語で便利な反面、セキュリティチェックが非常に難しい言語でもあります。DOMinatorはJavascriptの柔軟性を上手く利用して、DOMベースのXSSを検出します。Javascriptの入出力を監視し、DOMベースXSSが可能である箇所を見つけ出します。百聞は一見に如かず。デモ動画を見ればDominatorを使ったDOMベースXSSチェックがどのように便利であるのか分かります。

http://www.youtube.com/watch?v=f_It469LUFM

（動画に音声はありません。説明はTEXTエディタに書いてあるのでHDにして最大画面にして見てください）

どうですか？ソースコードを読んで解析するより何倍、いえ何十倍も楽にDOMベースのXSSを検出できました。

簡単そうに見えますが、使いこなすには色々コツと知識が必要です。既に情報が古くなっていますが

http://code.google.com/p/domxsswiki/

の

http://code.google.com/p/domxsswiki/wiki/LocationSources

などを利用してJavascriptインジェクションが可能か調べると、サイトが脆弱であるか分かります。あまり使いこなし方が分からなくても有用なツールです。Javascriptで動的なサイトを構築している方、特にユーザがコントロールできる情報使いJavascriptでページを操作している方は一度DOMinatorを使ってみると良いでしょう。

ところで、PROVE for PHPのマイナーバージョンアップをしました。PDOなどの内部オブジェクトの対応はまだですが、Webコンソールを改善しました。（まだまだ改善が必要で、どんどん改善します）PROVEもDOMinatorに似ていると言えば似ていると言えます。PHPの内部動作を詳細に記録し、差分を取ることでPHPやアプリが正しく動作している事が確認できます。サイトにはVMwareイメージもあるので試してみてください。バグを見つけたら教えてください！

PHPのセッションモジュールはセッションアダプションに脆弱なのですが、開発者の理解が得られず何年間も放置されています。

セッションアダプション脆弱性： 未初期化のセッションIDを受け入れてセッションを確立する脆弱性。

PHPのセッションIDはデフォルトでドメイン指定無し、パスは/に設定されています。専用サイトならこれであまり困ることは無いのですが、複数のアプリケーションやユーザが利用するようなサイトでは問題になります。

例えば、Chromeはパスよりドメインが優先されるのでドメインを利用したセッションIDの固定化などが起きます。IEではドメインよりパスが優先されるのでパスを利用したセッションIDの固定化などが起きます。

session_regenerate_id()を使えばOK、と考えている人も多いようですが既に設定済みのクッキーのうちどれが優先されてしまうか？が問題であるためsession_regenerate_id()を利用してもセッションIDは変わりません。優先されないクッキーを設定しても意味がないからです。

対策としては、すべてのドメイン、パスのセッションIDと同じクッキー名のクッキーを削除（空のクッキーを設定すると削除）する事ですがあまり多くの人がやっているとは思えません。根本的な解決策は「厳格なセッション管理」を行うことです。未初期化のセッションIDは受け入れないようにすれば完璧です。

セッションIDの固定化が可能な状況では、セッションアダプションに脆弱な場合はセッションを盗まれますが、厳格なセッション管理ならセッションIDを毎回振り直そうとする事になり、セッションは盗まれません。つまり、セッションが盗まれる代わりに「ログインできない」というDoS攻撃になります。セッションを盗まれるより、DoSの方が比べる必要がないくらいマシです。「ログインできない！」というユーザが居たら「ブラウザのクッキーを削除してください」と対応すれば良いだけです。

数年前にそろそろ直したら？とsecurity@php.netにメールしたのですが、開発者の問題だと勘違いしていて修正されませんでした。今日、またphp-internal@list.php.net internals@lists.php.net に再度メールをしておきました。さて、今回はどうなることでしょう？

まだまだ完成度を高める必要がありますが、PHPのリグレッションテストツールのPROVE for PHPのダウンロードを開始しました。

http://www.provephp.com/

PHPのテストスイートの設定を忘れていてPDOオブジェクトのサポートできてない事に直前に気がついたのでPDOには対応していません。これは出来るだけ早急に対応します。

Dokuwikiなどでは普通に使えます。VMwareイメージも用意しているので試してみてください。

非常用の個人利用は無料です。商用利用はご購入ください。開発に役立ちます！

PROVE for PHP 0.4.0をリリースしました。

• IOをプラグイン化（将来PostgreSQLなどに対応）
• prove_seek_function_call()を追加
• ハードリンクによるコピーに対応（高速化）
• prove_rename_function()の無効化（PHP 5.3のZend Engineの仕様変更により関数名変更はメモリエラーが発生するため）
• ログフォーマットを更新。バージョン情報を追加。

もともとIO部分はプラグイン化するつもりだったのですが、ファイルに最適化し過ぎていた部分があったため大幅にリファクタリングしました。機能追加よりも今後の機能拡張を容易にするための変更がメインです。内部構造をかなり変更したのでバグが残っているかも知れません。もし見つけたら教えて頂けると助かります。

昨年のPHPカンファレンスで紹介したPORVE for PHP 開発版の公開を始めました。PROVE for PHPはこんなテストが出来ます。

• PHPをアップデートしてアプリに影響が無い事を検証する
• PHPアプリをアップデートしても以前と同じように動作する事を検証する

使い方もとても簡単です。

• テストケースの作成はブラウザからアプリを利用するだけ
• ロードバランサを用いて実運用サーバからのテストケースも作成可能
• テストの実行はプログラムを実行するだけ
• 違いが在った場所はプログラムの何処か確実＆簡単に判明

http://www.provephp.com/

...

現状

• CUIとコマンドツールでの管理のみ
• GUI（Web、GTK）は順次整備予定

PROVEを利用すればPHPのセキュリティパッチがリリースされた場合に、アプリケーションの動作チェックにかかる時間は数時間もあれば十分です。PHPのバグや仕様変更で動作が変わった場所（ソースコード中の関数）は一目で分かります。

PHPアプリケーションのマイナーバージョンアップやセキュリティフィックスが思わぬ副作用をもたらさないか、チェックするのも簡単です。

PHPアプリケーションの開発時にはBDD（振る舞い駆動開発）のツールとしても利用可能です。以前に記録したログと新しい機能を開発した後のログを比較して、思ったとおりの動作になっているか、簡単に確認できます。

PHP 5.3用のPROVEは個人利用であれば無料で利用できます。

オープンソースを期待された方済みません。弊社は小さな会社なので、大きな会社のようにオープンソースにしてメンテナンスなどで儲けるビジネスモデルは無理です。。将来の課題とさせてください。

PROVEの購入は基本的にパートナー企業から購入できるようになります。しかし、一定数のユーザは弊社から直接販売致します。まだ開発版ですが購入したい方は大歓迎です。開発版購入者だけの特典もご用意しています。私か弊社に直接ご連絡下さい。

ウェブサイトにはPROVE for PHPの紹介と簡単なデモ動画も用意しています。是非ご覧ください。

http://www.provephp.com/

Gitを使っていて初めてエラーらしいエラーに合いました。検索してもコレという物がヒットしなかったので書きます。

error: unable to index file aaa

fatal: updating files failed

[yohgaki@dev git-test]$ git init .
Initialized empty Git repository in /home/yohgaki/tmp/git-test/.git/
[yohgaki@dev git-test]$ touch aaa
[yohgaki@dev git-test]$ git add aaa
[yohgaki@dev git-test]$ git commit -m 'add' .
[master (root-commit) ff6f5d2] add
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 aaa
[yohgaki@dev git-test]$ rm aaa
rm: remove 通常の空ファイル `aaa'? y
[yohgaki@dev git-test]$ mkdir aaa
[yohgaki@dev git-test]$ touch aaa/bbb
[yohgaki@dev git-test]$ git add aaa/
[yohgaki@dev git-test]$ git commit -m 'add dir' .
error: unable to index file aaa
fatal: updating files failed

[yohgaki@dev git-test]$ git commit -m 'add dir' .
error: unable to index file aaa
fatal: updating files failed
[yohgaki@dev git-test]$ cd aaa/
[yohgaki@dev aaa]$ git commit -m 'commit dir' .
[master 5b63843] commit dir
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename aaa => aaa/bbb (100%)
[yohgaki@dev aaa]$ cd ..
[yohgaki@dev git-test]$ git branch
* master
 

徳丸さんのブログでescapeshellcmdの余計なお世話の件が指摘されていたのでパッチを作りました。これmagic quoteと同じレベルの余計なお世話なのですが放置されています。個人的にはどのような関数にも全てバリデーション済みの文字列しか渡さないのでセキュリティ問題は発生しないのですが、UNIX系OSではペアとなる"と'はエスケープしない仕様に気が付いていないプログラマも多いかもしれません。

...

取り敢えず、UNIX系OSでもescapeshellcmd関数にオプションを渡すことによりエスケープの動作を調整できるようなパッチを書きました。

一応セキュリティチームに投げておきますが、修正されるとしてもPHP 5.3だけでしょう。PHP 5.4以降になる可能性も高いです。どうしても今必要な方は自分でパッチを組み込んで使ってください。

追記：何も考えず30分ほどで作ったので定数名が変ですね。。。もしリリース版に取り込むとしても定数名は変更される可能性が高いのでこのままにしておきます。

使い方

• escapeshellcmd($str, ESCAPE_SHELL_CMD_ALL); // 全部エスケープ
• escapeshellcmd($str, ESCAPE_SHELL_CMD_END); // 先頭と終端以外はエスケープ
• escapeshellcmd($str, ESCAPE_SHELL_CMD_PAIR); // ペア以外はエスケープ（デフォルト）

第二引数のフラグを渡さないとデフォルトの動作をします。Windows系の動作は触っていないのでフラグを渡しても渡さなくても問答無用でエスケープします。(ESCAPE_SHELL_CMD_ALLと同じ）

パッチ

diff --git a/ext/standard/basic_functions.c b/ext/standard/basic_functions.c
index f7c82dd..5f269bf 100644
--- a/ext/standard/basic_functions.c
+++ b/ext/standard/basic_functions.c
@@ -3609,6 +3609,7 @@ PHP_MINIT_FUNCTION(basic) /* {{{ */
REGISTER_INI_ENTRIES();

register_phpinfo_constants(INIT_FUNC_ARGS_PASSTHRU);
+    register_exec_constants(INIT_FUNC_ARGS_PASSTHRU);
register_html_constants(INIT_FUNC_ARGS_PASSTHRU);
register_string_constants(INIT_FUNC_ARGS_PASSTHRU);

diff --git a/ext/standard/exec.c b/ext/standard/exec.c
index 713a8a0..a538390 100644
--- a/ext/standard/exec.c
+++ b/ext/standard/exec.c
@@ -51,6 +51,17 @@
#include <unistd.h>
#endif

+/* {{{ register_exec_constants
+ *  */
+void register_exec_constants(INIT_FUNC_ARGS)
+{
+    REGISTER_LONG_CONSTANT("ESCAPE_SHELL_CMD_PAIR", ESCAPE_SHELL_CMD_PAIR, CONST_PERSISTENT|CONST_CS);
+    REGISTER_LONG_CONSTANT("ESCAPE_SHELL_CMD_END", ESCAPE_SHELL_CMD_END, CONST_PERSISTENT|CONST_CS);
+    REGISTER_LONG_CONSTANT("ESCAPE_SHELL_CMD_ALL", ESCAPE_SHELL_CMD_ALL, CONST_PERSISTENT|CONST_CS);
+}
+/* }}} */
+
+
/* {{{ php_exec
* If type==0, only last line of output is returned (exec)
* If type==1, all lines will be printed and last lined returned (system)
@@ -276,7 +287,7 @@ PHP_FUNCTION(passthru)

*NOT* safe for binary strings
*/
-PHPAPI char *php_escape_shell_cmd(char *str)
+PHPAPI char *php_escape_shell_cmd_ex(char *str, int flag)
{
register int x, y, l = strlen(str);
char *cmd;
@@ -304,14 +315,26 @@ PHPAPI char *php_escape_shell_cmd(char *str)
#ifndef PHP_WIN32
case '"':
case '\'':
-                if (!p && (p = memchr(str + x + 1, str[x], l - x - 1))) {
-                    /* noop */
-                } else if (p && *p == str[x]) {
-                    p = NULL;
-                } else {
+                if (flag == ESCAPE_SHELL_CMD_ALL) {
cmd[y++] = '\\';
+                    cmd[y++] = str[x];
+                } else if (flag == ESCAPE_SHELL_CMD_END) {
+                    if (x == 0 || x == l - 1) {
+                        cmd[y++] = str[x];
+                    } else {
+                        cmd[y++] = '\\';
+                        cmd[y++] = str[x];
+                    }
+                } else { /* ESCPAE_SHELL_CMD_PAIR */
+                    if (!p && (p = memchr(str + x + 1, str[x], l - x - 1))) {
+                        /* noop */
+                    } else if (p && *p == str[x]) {
+                        p = NULL;
+                    } else {
+                        cmd[y++] = '\\';
+                    }
+                    cmd[y++] = str[x];
}
-                cmd[y++] = str[x];
break;
#else
/* % is Windows specific for enviromental variables, ^%PATH% will
@@ -363,6 +386,10 @@ PHPAPI char *php_escape_shell_cmd(char *str)

return cmd;
}
+PHPAPI char *php_escape_shell_cmd(char *str)
+{
+    return php_escape_shell_cmd_ex(str, ESCAPE_SHELL_CMD_PAIR);
+}
/* }}} */

/* {{{ php_escape_shell_arg
@@ -435,14 +462,15 @@ PHP_FUNCTION(escapeshellcmd)
{
char *command;
int command_len;
+       long flag = ESCAPE_SHELL_CMD_PAIR;
char *cmd = NULL;

-    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &command, &command_len) == FAILURE) {
+    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s|l", &command, &command_len, &flag) == FAILURE) {
return;
}

if (command_len) {
-        cmd = php_escape_shell_cmd(command);
+        cmd = php_escape_shell_cmd_ex(command, flag);
RETVAL_STRING(cmd, 0);
} else {
RETVAL_EMPTY_STRING();
diff --git a/ext/standard/exec.h b/ext/standard/exec.h
index 18ba008..b39a90e 100644
--- a/ext/standard/exec.h
+++ b/ext/standard/exec.h
@@ -21,6 +21,10 @@
#ifndef EXEC_H
#define EXEC_H

+#define ESCAPE_SHELL_CMD_PAIR  0
+#define ESCAPE_SHELL_CMD_END   1
+#define ESCAPE_SHELL_CMD_ALL   2
+
PHP_FUNCTION(system);
PHP_FUNCTION(exec);
PHP_FUNCTION(escapeshellcmd);



perl - 短縮URLを一行で展開する

という記事があったのでPHPでやるとどうかなと作ってみた。（と言うほどの物ではありませんけど）本当に一行にするには無理があったのでの実際には2行です。他に良い方法があるかな？

$ php -r '$h=get_headers($argv[1], 1);echo $h["Location"];' http://j.mp/dankogai

専用関数があるので面白くもなんともありませんね。

リンク: http://openseminar.localnetwork.jp/osjp2011_hiroshima

JPUG四国支部、オープンセミナー実行委員会主催のオープンセミナー2011@広島が2011/1/22(土)に開催されます。UST中継も予定されていまるので遠方の方もご覧いただけます。

http://openseminar.localnetwork.jp/osjp2011_hiroshima

...

イベント名：オープンセミナー2011@広島

主催：PostgreSQLユーザ会中国支部、オープンセミナー2011@広島 実行委員会
共催：ローカルネットワーク
後援：広島大学情報メディア教育研究センター

場所：広島大学 総合科学部K棟2階 K202講義室
アクセス：http://www.hiroshima-u.ac.jp/add_html/access/ja/saijyo4.html
(公共交通機関をご利用の場合「広大西口」バス停からが近いです。駐車場あり。自家用車もOK)

日時：2011/1/22(土) 13:00開始
費用：無料

オープンセミナーとは2003年より中四国地域で開催されているIT技術者向けの無料セミナー
です。ボランティアによって企画・運営されている非営利セミナーです。現在は香川県、岡山
県、徳島県、広島県、愛媛県で開催されています。現在のオープンセミナーは各地域での実行
委員により実行されています。オープンセミナーはスポンサーと地域のボランティアによって
成り立っています。

このメールは転送自由です。オープンセミナー2011@広島の告知にご協力頂けると幸いです。
皆様のご協力とご来場をお待ちしております。

最新のイベント情報は以下をご確認ください。
http://openseminar.localnetwork.jp/doku.php?id=osjp2011_hiroshima

オープンセミナーについて
http://openseminar.localnetwork.jp/

Ustreamについて
当日Usteramによる放送を予定しています。詳しくは、
http://openseminar.localnetwork.jp/doku.php?id=osjp2011_hiroshima
をご覧ください。

参加登録はこちらからお願いします。
http://atnd.org/events/10581

セミナーには登録無しでも参加できますが、できれば登録をお願いします。
*懇親会参加希望の方は必ず「懇親会参加」と記入して登録をお願いします。*
懇親会費は4000円を予定しています。

-------------------------------
プログラム

12:55 - 13:00
ご挨拶

13:00 - 13:50
題名：iPhone with Ruby
講師：吉田　和弘（よしだ　かずひろ）
所属：株式会社ミッタシステム/日本Rubyの会
概要：iPhoneアプリ開発においてRubyやRuby on Railsを用いる方法をいくつか
      紹介します。

14:00 - 14:40
題名：PHPの実行・開発環境
講師：大垣　靖男（おおがき　やすお）
所属：エレクトロニック・サービス・イニシアチブ有限会社／日本PHPユーザ会／PHP技術者認定機構
概要：PHPの実行環境、開発環境には色々な環境がありその幾つかを紹介します。

14:50 - 15:10
ライトニングトーク（募集中）

15:20 - 16:30
題名：開発者として知っておきたいWindows Phone 7とInternet Explorer 9
講師：田中達彦 （たなか たつひこ）
所属：マイクロソフト株式会社 UX & クライアントプラットフォーム推進部
役職：デベロッパーエバンジェリスト
概要：開発者にとって、新しいデバイスやテクノロジはわくわくするものです。
      前半50分は既存のスマートフォンの枠を超えるWindows Phone 7の概要と
      アプリケーションの開発方法について、後半20分はInternet Explorer 9
      を活用するためのWebサイトの開発方法を説明します。

16:40 - 17:30
題名：PostgreSQLで知るオープンソースデータベースの今
講師：石井　達夫（いしい　たつお）
所属：SRA OSS Inc. 日本支社／日本PostgreSQLユーザ会
概要：ITシステムの中でも中心的な役割を果たしているデータベースと、それを
      とりまく状況を、代表的なオープンソースデータベースPostgreSQLを中心
      に、KVS(Key Value Store)などとの違いも含めてわかりやすく解説します。


問い合わせ先：
     大垣 靖男 yohgaki@ohgaki.net （オープンセミナー実行委員 広島担当）

私がインタビューアーと執筆を担当させて頂いたRasmusさんへのインタビュー記事は好評だったようです。

http://gihyo.jp/news/interview/2010/rasmus

この記事の中で「美しいツールは美しい問題を解決するためには非常に効果的かも知れませんが，多くの場合は必要がありません。さまざまなルールを作り，フレームワークを使い，モデルやビューを使って解決できない問題があるのです。」の部分は解説が無いと理解できないかも知れません。Rasmusさんなら私と同じようにこう思っているハズという補足なので外している可能性もありますが、この部分の意図を補足します。

...

Rasmusさんもパフォーマンスについてはかなりうるさい方です。RasmusさんがYahooの為に働き出した頃「statシステムコールが多すぎて遅くなる」と文句を言っていた事を良く覚えています。私が普段常用しているLinuxの場合、statシステムコールはカーネルレベルでキャッシュ（ディレクトリエントリがキャッシュ）されていました。ディレクトリに書き込まなければ非常に速く処理できます。Linuxでは15年くらい前には実装済みだったと思いますが、FreeBSDは比較的最近になるまでディレクトリエントリのキャッシングは実装されていませんでした。これがどのくらいパフォーマンスに影響を及ぼすか、パフォーマンスにうるさい方なら良くご存知だと思います。

PHPのinclude/require文は現在のパスを/（ルート）から検証します。つまり、/some/dir/under/very/deep/dir/in/the/system というディレクトリのファイルをインクルードすると10回のstatシステムコールが呼ばれる事になります。この問題を解決するためにRasmusさんはPHPの内部でキャッシュする仕組みを実装しました。

開発者に優しい高機能な開発環境と性能はトレードオフの関係がある場合が多いです。非常に高いパフォーマンスを求められるシステムでは様々な「無駄」を省く必要があります。F1に乗用車のような装備が必要とされていないのと同じです。開発者に優しいフレームワークは乗り心地のよい市販乗用車のような物です。様々な安全装備や快適性の為の機能が提供されています。

Webアプリはステートレスであるため、一つ一つの処理は小さく完結する物になっています。セッション管理で状態を管理しているとは言っても「リクエストがあったらレスポンスを返す」ただそれだけを行うのがWebアプリです。「リクエスト」に対して「レスポンス」を返すだけが仕事のWebアプリに、モデルやビューは無用とは言いませんが、高性能なWebアプリを作るには「無駄」なのです。最近のPCなら単純なリクエストを受け付けて、レスポンスを返すだけなら毎秒1万リクエストでも処理できますが、モデルやビューと言った仕組みを使うだけで桁違いに遅くなります。大規模なシステムであれば多少の開発コストの増加はサーバの効率的な利用で簡単にペイできます。

Web企業の多くが開発コスト、開発速度、安全性、メンテナンス性、性能を天秤に掛けて様々なアプローチで問題を解決しています。開発者を十分に教育できる企業であるなら、一般的なWebアプリフレームワークを使う意味はあまり多くありません。一般的なWebフレームワークと開発環境は開発コストとメンテナンス性に重点を置いているからです。Googleで一番多いプロジェクトはC++のプロジェクトだそうです。なぜC++のプロジェクトが多いのか？その理由は聞く必要もないでしょう。

PHPに限った事ではありませんがMVCフレームワークを使わないクイック、ダーティーな方法で実装すれば10倍、20倍、100 倍速くなる。このような場合はどちらを選択すべきなのか？は状況によって違います。1台のサーバでお釣りがくるようなホームページと、最適化していれば1000台のサーバで済むサービスに1万台、2万台、10万台のサーバを導入する必要があるサービスとでは必要とされる条件がまったく異なります。

クライアントサイドでの処理も増え複雑化してきているWebアプリですが、サーバ側だけ見ると15年前とあまり変わりません。

リクエストが来たら、レスポンスを返す

これがWebアプリのサーバサイドの仕事です。この簡単な仕事を”超"効率良くこなすにはどうすべきか？MVCフレームワークで綺麗にモデル化したアプリケーションが正解ではない環境がリアルな世界にはあるということです。

PHPカンファレンス2010ではビジネスデイにリグレッションテストツールのPROVE for PHPを紹介させて頂きました。その講演の資料です。Keynoteで話しながら説明するように作っていたので、PDFで見ても大丈夫なように少し改変しています。

http://blog.ohgaki.net/media/users/yohgaki/PHPCON2010PROVE4PHP.pdf

商用ですがビジネスモデルは決まっていません。今のところパーソナルユースは無償で利用できるようにする方向性でビジネスモデルを考えています。

このプレゼンの中では解説していませんが、厄介なのがSESSIONモジュールのデータの取り扱いです。セッションモジュールのセッションセーブハンドラは直接I/Oを行っているのでラッパーを書けません。幸いセッションセーブハンドラはモジュール構造を持っているので、少し無理やりですがPROVEが定義した関数を呼び出すようにしてTRACEとVALIDATIONモードが正しく動作するようにしています。

まだまだ作り足りない部分が多いのでリリースは先になりますが、アップグレード時の動作チェックが劇的に楽になります。

私の環境では、PAGER='lv' としていたのでMac OSXのターミナルでgit diff とかするとANSIエスケープシーケンスが正しく処理されない。GIT_PARGER環境変数を以下のように修正した。

export GIT_PAGER='/opt/local/bin/lv -c'

これはMacportsのlv（マルチバイト文字も正しく表示できるテキストビューアー）ですが、普通のlessを使っている人は

export GIT_PAGER='/usr/bin/less -R'

でカラー表示になると思います。

OSX標準のApache/PHPでPostgreSQLやMySQLを使えるようにしても良いのですが、いろいろカスタマイズしたい場合はMacPortsの方が便利だったりします。インストール手順が古かったりするブログもあったので（手順が抜けているかも知れませんが）最初から書きます。

...

MacPortsのインストール

MacPortsをインストールにはXcode (OSXの開発環境）が必要です。DVDに付属しているXcodeより、Webサイトから最新版のXcodeをダウンロードした方が良いでしょう。

http://developer.apple.com/technologies/tools/xcode.html

MacPortsはパッケージまたはソースからインストールできます。

http://www.macports.org/install.php

ソースからインストール必要性はあまりないので、「Mac OS X Package (.pkg) Installer」のセクションから自分の環境（Snow Leopard, Leopard, Tiger）に合ったパッケージをインストールすれば準備完了です。

Portsパッケージのインストール

MacPortsのパッケージはportコマンドでソースからインストールします。今回はApache2, PHP5, PostgreSQL 8.4, mysql 5をインストールします。

sudo port install apache2 php5-* postgresql84 mysql5

執筆時点でのPHP5パッケージはPHP 5.3でした。PHP 5.2を利用したい場合はphp52-*を利用します。このコマンドを実行するとphp-gtkなどのGUIアプリケーションもビルド&インストールします。非常に沢山のパッケージをインストールしてしまうので、少なくしたい場合はphp-gtk、php-qt、php-cairoなどのパッケージを含めないようにします。

PHPモジュールは複数ロードできますが、Zendエンジンのモジュールは一度に一つしかロードできないので注意してください。
例： php-apc, php-apd, php-eaccelerator, php-xdebugなど

apacheの起動

Apacheを自動起動したい場合は以下のコマンドを実行します。

sudo launchctl load -w /Library/LaunchDaemons/ org.macports.apache2.plist

Apacheを起動・停止するエイリアスを定義しておくと便利です。

alias mysqlstart='sudo /opt/local/bin/apachectl start'
alias mysqlstop='/opt/local/bin/apachectl stop'

postgresqlの起動

まずデータベースを初期化しなければならないので初期化します。私は/var/pgsqlをデータディレクトリにしました。

sudo mkdir /var/pgsql && chown yohgaki:yohgaki /var/pgsql

データベースをutf8エンコーディングで初期化します。MacportsのPostgreSQLのコマンドはバージョン毎に分けてインストールされています。

/opt/local/lib/postgresql84/bin/initdb -E utf8 --no-locale .

MySQLを自動的に起動したい場合は、以下のコマンドを実行します。

/Library/LaunchDaemons/org.macports.postgresql84-server.plist

以下のエイリアスを登録していると便利です。

pgsqlstart='/opt/local/lib/postgresql84/bin/pg_ctl start -D /var/pgsql -l /var/pgsql/pgsql.log'
pgsqlstop='/opt/local/lib/postgresql84/bin/pg_ctl stop -D /var/pgsql -m fast'
psql='/opt/local/lib/postgresql84/bin/psql'

mysqlの起動

MySQLを自動的に起動したい場合は、以下のコマンドを実行します。

sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

以下のエイリアスを登録していると便利です。

alias mysqlstart='sudo /opt/local/bin/mysqld_safe5 &'
alias mysqlstop='/opt/local/bin/mysqladmin5 -u root -p shutdown'

リンク: http://www.momonga-linux.org/archive/Momonga-users.ja/msg00597.html

遅ればせながらMomonga Linux 7リリースの紹介です。

ホームページ：
http://www.momonga-linux.org/

ダウンロード：
http://dist.momonga-linux.org/pub/momonga/7/Momonga/

絶対に目を通すべきFAQ： 
http://developer.momonga-linux.org/wiki/?Momonga+Linux+7+FAQ

...

Momonga Linuxは使っているだけでは楽しくありません。自分でビルドして楽しむものです。私は4coreのPC上のchroot環境でビルドしています。多少古いですがOmoiKondara HOWTOも必読です。

http://www.momonga-linux.org/docs/OmoiKondara-HOWTO/ja/index.html

時間が無い方はもっと簡単なこちらをどうぞ。

http://developer.momonga-linux.org/wiki/?OmoiKondaraQuickStart

Momonga Linuxはライセンスがフリーで無い物は含まれていません。例えば、筆者はnVidiaのVGAカードを使っていますが専用ドライバは標準では含まれません。これらを簡単にインストールする「Momonga Nonfree Package Builder」が用意されています。

http://developer.momonga-linux.org/wiki/?How+to+use+Momonga+Nonfree+Package+Builder

これまでの Momonga Linux では、これらのパッケージをインストールしたい場合、ユーザの皆様に以下のページを参考にしてOmoiKondara を自力で動かしてもらうようにしていました。

OmoiKondaraQuickStart

この作業をやった方であればお分かりの通り、計算機、ネットワーク、時間、手間、知識などといった様々なリソースを必要とし、お手元の Momonga Linux を実用的で快適な環境へとセットアップする上でひとつの障害でした。

これを利用すると簡単にNonfree Packageのビルドが出来ます。手っ取り早くMomonga Linux 7を最適化するにはこれを利用すると良いでしょう。

以下はリリースノートからの抜粋です。

Mac OSX 10.6のPHPはPHP5.3なのでPHP5.2をビルドしてインストールしたい、と思っている方も多いと思います。Macportsが入っていれば、

sudo port install php52 php52-web

のような感じでPHP5.2をインストールできます。Portsじゃなくてソースから、そしてPECLなど他のモジュールもロードするのではなくスタティックに組み込みたい！という場合もあるでしょう。いちいちモジュールディレクトリを作ってphp.iniでロールするのは面倒ですから当然です。

...

しかし、PHP 5.2.14 のソースに付属するbuildconfを実行すると以下のようなエラーが発生します。

yohgaki@yohgaki-macbook-2$ rm configure && ./buildconf --force
Forcing buildconf
buildconf: checking installation...
buildconf: autoconf version 2.65 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
Running vcsclean for you.
To avoid this, install autoconf-2.13.
Can't figure out your VCS, not cleaning.
rebuilding configure
ext/pdo_dblib/config.m4:55: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
../../lib/autoconf/general.m4:1998: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2019: AC_CACHE_CHECK is expanded from...
aclocal.m4:2741: PHP_CHECK_PDO_INCLUDES is expanded from...
ext/pdo_firebird/config.m4:43: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_mysql/config.m4:135: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_oci/config.m4:231: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_odbc/config.m4:42: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_pgsql/config.m4:109: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_sqlite/config.m4:14: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/sqlite/config.m4:50: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
rebuilding main/php_config.h.in
autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for `config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a template without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.
ext/pdo_dblib/config.m4:55: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
../../lib/autoconf/general.m4:1998: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2019: AC_CACHE_CHECK is expanded from...
aclocal.m4:2741: PHP_CHECK_PDO_INCLUDES is expanded from...
ext/pdo_firebird/config.m4:43: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_mysql/config.m4:135: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_oci/config.m4:231: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_odbc/config.m4:42: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_pgsql/config.m4:109: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_sqlite/config.m4:14: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/sqlite/config.m4:50: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached

エラーメッセージにめげずにconfigureスクリプトを実行すると

yohgaki@yohgaki-macbook-2$ ./configure
cat: confdefs.h: No such file or directory
./configure: line 387: ac_fn_c_try_run: command not found
./configure: line 403: 5: Bad file descriptor
./configure: line 404: 6: Bad file descriptor
cat: confdefs.h: No such file or directory
./configure: line 443: ac_fn_c_try_run: command not found
cat: confdefs.h: No such file or directory
./configure: line 443: ac_fn_c_try_run: command not found
cat: confdefs.h: No such file or directory
./configure: line 443: ac_fn_c_try_run: command not found
cat: confdefs.h: No such file or directory
./configure: line 443: ac_fn_c_try_run: command not found
cat: confdefs.h: No such file or directory
./configure: line 443: ac_fn_c_try_run: command not found
cat: confdefs.h: No such file or directory
./configure: line 443: ac_fn_c_try_run: command not found
cat: confdefs.h: No such file or directory
./configure: line 443: ac_fn_c_try_run: command not found
cat: confdefs.h: No such file or directory
./configure: line 443: ac_fn_c_try_run: command not found
./configure: line 466: 5: Bad file descriptor
./configure: line 467: 6: Bad file descriptor
./configure: line 469: 5: Bad file descriptor
./configure: line 470: 6: Bad file descriptor
cat: confdefs.h: No such file or directory

全く動作しません。原因は明らかにautoconfが新しすぎる事にあるので古いautoconfが必要です。PHPではautoconf 2.13という古いバージョンが推奨されています。

yohgaki@yohgaki-macbook-2$ which autoconf213
/opt/local/bin/autoconf213

Macportsがautoconf 2.13を勝手にインストールしてくれているのでこれを使います。

yohgaki@yohgaki-macbook-2$ rm configure && PHP_AUTOCONF=autoconf213 ./buildconf --force
Forcing buildconf
rebuilding configure
rebuilding main/php_config.h.in
autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for `config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a template without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.
ext/pdo_dblib/config.m4:55: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
../../lib/autoconf/general.m4:1998: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2019: AC_CACHE_CHECK is expanded from...
aclocal.m4:2741: PHP_CHECK_PDO_INCLUDES is expanded from...
ext/pdo_firebird/config.m4:43: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_mysql/config.m4:135: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_oci/config.m4:231: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_odbc/config.m4:42: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_pgsql/config.m4:109: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_sqlite/config.m4:14: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached
ext/sqlite/config.m4:50: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached

今度もエラーが起きていますが、./configureは動作します。私が必要とするモジュールではエラーは発生しないのですが、PDO周りでエラーが発生するかも知れないです。

Mac上でEmacsを使うと言っても、コードを見るくらいでAquaemacsを使っています。Aquaemacs 2.0以上からはタブも使えてかなり便利です。今は2.1を使っています。PHP、RubyはEclipseやNetBeansを使っています。

Aquaemacsでコーディングはしていなかったので今まで困らなかったのですが、PHP本体のコーディングとビルドをMac上で出来るようにしました。Cのコードは普通はEmacsで書いているので、AquaemacsでCのコードをコーディングしようと思ったら「バックスラッシュ(\)が円記号(¥)になる」現象で困ってしまいました。

...

普通はOption+¥ で \ （0x5C）が入力できるのですが、AquaemacsではOptionキーがメタキーになっているので入力できないようです。コマンドキーとオプションキーを入れ替えてみましたが

;; command key as meta key
(setq ns-command-modifier 'meta)
;; option + yen(jis keyboard) => backslash
(setq ns-alternate-modifier 'option)

これもダメでした。これで動作する環境も在るようですがOSX 10.6ではNGなのかも知れません。結局、

http://sourceforge.jp/projects/macemacsjp/lists/archive/users/2006-June/001125.html

に記載されている

(define-key global-map [?円記号] [?\\])
(define-key global-map [?\C-円記号] [?\C-\\])
(define-key global-map [?\M-円記号] [?\M-\\])
(define-key global-map [?\C-\M-円記号] [?\C-\M-\\])

を~/.eamcsに記入して解決しました。"円記号"の部分をUnicode(UTF-8)の"¥"で置き換えてください。Aquaemacsで書けば勝手にUnicodeの"¥"になるはずです。上手くいかない場合はエンコーディングが違うのかも知れません。~/.emacsに

(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(prefer-coding-system 'utf-8)

を追加してみてください。UTF-8でファイルを読み書きできるはずです。

Aquaemacsを再起動すれば普通に"¥"キーを押せばASCIIの"\"(0x5C) が入力されるようになります。快適です。

DLLハイジャックが可能なアプリケーションは多数見つかっています。

http://www.corelan.be:8800/index.php/2010/08/25/dll-hijacking-kb-2269637-the-unofficial-list/

しかし、対策はあまり取られていません。
いちいち対策するのは面倒なのでKB2264107のFIX ITでネットワーク共有、WebDAVからのロードを無効にする方がよいでしょう。

ユーザができる対策はこちら
http://support.microsoft.com/kb/2264107
https://www.microsoft.com/technet/security/advisory/2269637.mspx#EGF

開発者ができる対策はこちら
http://msdn.microsoft.com/en-us/library/ff919712%28v=VS.85%29.aspx

Xperiaを購入したのでOSXを無料でテザリングする方法探してやってみました。流石にテザリングソフトを購入した方が簡単ですが、一旦環境を作ってしまえば使うのはそれほど手間ではありません。

Wikiに手順をまとめておいたので興味がある方はどうぞ。

必要な物は、Android SDK, Azilink（Android側のVPNアプリ）, OpenBlick（Mac OSX用のVPN GUI - openvpnだけでも何とかなるがこれが無いとネットワーク設定が面倒）です。詳しくはWikiを見てください。

制限事項

• ping はできない(UDP pingでエミュレーションしているため）
• USB接続(Wifi, Bluethooth接続は無理)
• 自己責任。パケホーダイなら最大約1万3千円のようですが、スマートフォンの最大金額（約6000円）を超えるかもしれません。自己責任で使用してください

速度は計測していませんが、それほど遅くないような気がします。

同じような手順でLinuxでもテザリングできます。OpenVPNやルーティングテーブルを手動で調整するだけです。

しばらくXperiaを使ってみた感想は、普通にスマートフォンとして使うには良いのではないか、と思いました。時々アプリが落ちたりするのは愛嬌でしょう。iPhoneよりも無料アプリが充実しているので、Androidならとりあえず無料アプリでほとんど何とかなると思います。

弄りたおそうと思ってXperiaを購入した訳ではないので私は特に困りはしませんが、弄り倒したい人にはrootが取れないのは痛いです。テザリングもrootが取れるならWifiのアクセスポイントとしてAndroid携帯を設定する方法が一番便利だと思います。

XperiaがマルチタッチにH/W的に対応していないのは訴訟リスクの回避だとは思いますが、「これをマルチタッチにして実装すれば..」と思える操作がいくつかあります。H/Wだけは対応しておけば良かったのにと思います。

電池の持ちですが、直ぐに自動的にアイドルタスクを終了させるアプリを入れたせいか困る程は消耗しないです。あまり使いすぎると１日は持ちませんが、USBで一応充電できるのでPCと一緒に使っている人なら特に問題とはならないと思います。

追記：
USENのスピードテストでは岡山大学の構内で1.6Mbpsから3.1 Mbps程でした。

リンク: http://www.es-i.jp/seminar/

iPhone/iPad/iPodアプリ開発のブートキャンプと言える「実践iPhoneアプリケーション開発講座」を6月に岡山&高松でオープンウィンドさんと私の会社で開催します。今回はちょっと高い有料セミナーです。

有料なだけあって至れり尽くせりで、セミナーテキスト500ページ、複数のハンズオンセッションで実際にiPhoneの開発を体験できるセミナーになっています。開発環境からObjective-Cの解説、開発フレームワークの解説からデバッグ手法、実際のアプリ構築を行う4日間の集中講座です。iPhoneアプリ開発にはMacが必須ですが、Macが初めての方でも無理なく受講できる講座になっています。

今売れすぎて手に入らないiPadやiPod touchのアプリはiPhoneアプリと同じ開発手法で開発できます。

個人的には、iPadを使ったスマートな営業支援システム（タッチパネルとワイヤレスキーボード）などは非常に面白いのではと思っています。PCを買うより安く、機能が限定されている分安全で、しかも使い易い、GPSも装備されているので管理者も実績などを管理し易く(される方は大変?)、ある意味最強(?)のSFA端末になるのではないかと思っています。

セミナー会場は岡山駅と高松駅の直ぐ近くです。

岡山会場：　ままかりフォーラム　　 6/1(火) - 6/4(金)

高松会場：　サンポート高松　　6/15(火）- 6/18(金)

http://www.es-i.jp/seminar/

募集を開始したばかりです。5/1までに申し込みされた方は早期申し込み割引5000円です。募集定員は16名です。受講をご希望の方はお早めに登録してください。

毎年恒例のオープンセミナーのお知らせです。Rubyの松本さん、PGClusterの三谷さんをはじめ聴きごたえのある講師が揃いました。お昼はお弁当を持ってくるか注文する方が良いです。懇親会は70名になっていますが、既に予約が多すぎたので50から70名に増やしたばかりです。申し込みはお早めにどうぞ。

申し込み用のページ
http://kokucheese.com/event/index/1834/

セミナー告知ページ
http://openseminar.okaya.ma/

...

オープンセミナー2010＠岡山

オープンセミナーはオープンソースとインターネットをテーマにした
無料セミナーです。
このセミナーの企画と運営はオープンソースのユーザコミュニティの
ボランティアで行われています。昨年は香川県高松市、徳島県徳島市、
岡山県総社市、広島県広島市で開催された実績があります。
首都圏ではこのようなオープンソースユーザコミュニティが主催する
セミナーや勉強会は数多くありますが、地方ではまだまだ少ないのが
現状です。すばらしい講師陣である事は講師名で検索して頂くと直ぐに
分ります。コミュティ主催のセミナーに参加が初めての方もお気軽に
お越し下さい。

■名称： オープンセミナー2010＠岡山

■参加費： 無料

■開催日時：2010年5月15日（土） 11:00から17:00（12:25から13:25は昼食兼LT大会）

■開催場所：岡山県立大学 学部共通棟（南）8206室
http://www.oka-pu.ac.jp/
岡山県立大学　キャンパス平面図
http://www.oka-pu.ac.jp/information/campusmap.html

■アクセス：電車または車でお越し下さい。（無料駐車場あり）
http://www.oka-pu.ac.jp/information/access.html
電車の場合は、以下のURLから、
出発駅： 岡山,到着駅： 服部で検索してください。
http://mydia.jr-odekake.net/search/mobile.cgi

■主催: オープンセミナー2010@岡山　実行委員会

■共催： 岡山Javaユーザ会
日本PostgreSQLユーザ会 http://www.postgresql.jp/
瀬戸内Linuxユーザ会（STLUG）
四国BSDユーザ会（S*BUG）

■後援： 岡山県
オープンソースカンファレンス実行委員会
岡山県立大学
総社市

■協賛：　　技術評論社
翔泳社
NetBeans 日本語コミュニティ (http://ja.netbeans.org)

随時募集中です！

■昼食会：　お弁当費用1000円（事前にお申し込みください）

■懇親会： ダイニングスタイル　ろく (http://www.count-up.net/6/index.html）
費用5000円（事前にお申し込みください。）
５０人を超えると立食形式となります。

注意事項
当日、大学の食堂は12:00-13:00利用できます。メニューが限られているので
弁当を持参されるのも良いと思います。

----------------------------------------------------------------------
■午前の部　ミニセミナー（11:10～12:25）

11:10～11:25
○次世代モバイルインフラの予復習
講師：荒井 剛（岡山県立大学）

11:30～11:45
○次期リリース Debian 6.0(コード名: Squeeze)を見る
講師：のがたじゅん(Debian JP Project)

11:50～12:05
○GC生誕50周年を祝って
講師：中村 成洋

12:10～12:25
○オープンソースで飯が食えるようになるまで
～受託と基幹が大好きな会社での話～
講師：西 宏和（Magento-JP Users Group）

■昼食会兼LT大会（12:25～13:25）
○ひらさん（オープンラボ岡山）

○安達さん（岡山大学）

○芝さん（岡山県立大学）

○赤木さん（岡山大学）

○中矢さん（香川大学）

○三輪さん（オープンラボ岡山）

○きよくらさん（Okayama IT Egineers Community）

残り2～3枠あります。随時募集中です。

■午後の部（13:30～17:00）

13:30～14:20
○Rubyが拓く未来
講師：まつもと ゆきひろ（プログラミング言語「Ruby」の開発者）

14:30～15:00
○スクラム、要求開発、リーンをめぐる冒険
講師：前川　哲次（すくすくスクラム瀬戸内／要求開発アライアンス）

15:10～15:40
○AndroidとBeagleBoard ～アプリからGPIOを制御する～
講師：瀬戸　直喜（日本Androidの会四国支部）

15:50～16:40
○未定
講師：調整中（日本PostgreSQLユーザ会）

■講師陣のプロフィール等は公式サイト（http://openseminar.okaya.ma/）を
ご覧ください。

----------------------------------------------------------------------

■セミナーおよび懇親会参加申し込み方法
以下の参加申し込みページより申し込みをお願いいたします。
http://kokucheese.com/event/index/1834/

遅くなって申し訳ないです。昨年末に公開していたつもりでしたが公開設定していませんでした。

PostgreSQLユーザのためのSQLインジェクション対策

このプレゼンを行った後にPythonはCVEが公開されて、最新版では修正されています。

ご意見などございましたら御気軽にコメント、メールをください。

広島で中四国で行われている地域コミュニティが合同で行っているオープンセミナーが11/28（土曜）開催されます。

http://www.postgresql.jp/events/5e835cf630aa30fc30f330bb30df30ca30fc-1/view

ご都合が良い方は是非参加ください。

来る11月28日（土）に（株）SRA西日本会議室（Pルーム）にて
JPUG中国支部主催のオープンセミナーを開催します。
今回はオープンラボ岡山の協力を得、RubyやAndroidの話題も盛り込んでいます。
また、東京から桑村潤氏、石井達夫氏にお越しいただきますので、
興味のある方は是非ご参加ください。

セミナー、懇親会に参加を希望される方は、人数把握のため、三谷(mitani@sraw.co.jp)までメールでお申し込みください。

１．日時：2009年11月28日（土）13時から17時
（開場受付 12:30〜、懇親会 18:00-20:00）
２．場所：（株）SRA西日本　会議室（Pルーム）
広島市南区稲荷町 2-16　広島稲荷町第一生命ビル 10F
http://www.sraw.co.jp/map_hiroshima.html
３．定員：30名
４．会費：無料（懇親会は別途費用）
５．プログラム
13:00-13:25 三谷さん：PostgreSQLのClustering最新動向
13:30-13:55 吉田さん：RubyとPostgreSQLの全文検索　
14:00-14:25 英吉さん：Android Marketの理想と現実
14:30-14:55 大垣さん：SQLインジェクション
15:00-15:50 桑村さん：PL/Proxy,PgBouncerの紹介
16:00-16:50 石井さん：pgpool-II最新情報

OSC Tokyo Fallでは多くの方にプレゼンテーション（SQLインジェクション"ゼロ"のPostgreSQL利用法 - 今更聞けないSQLインジェク ションの現実と対策）を聞いて頂きありがとうございました。気に入って頂けた方も多かったようで何よりです。

何人もの方から「プレゼンファイルは公開するのか？」「プレゼンファイルを公開してほしい」聞いています。

もう直ぐ開催するOSC高知で同じプレゼンを行います。ネタばれプレゼンするのも恥ずかしいのでOSC高知の後にプレゼンファイルは公開します。

11/14(土)
http://www.ospn.jp/osc2009-kochi/

中国／関西からだと高速バスが便利かも。
岡山からは10時前には着くようです。
http://www.jr-shikoku.co.jp/bus/businfo/ryoma_ex/okayama.asp

北や難波から朝でると昼くらいには現地に着きます。
http://www.jr-shikoku.co.jp/bus/businfo/kochi_ex/index.asp

四国や近県の方（関西、中国の方）はOSC高知に是非お越し下さい！

明日のOSC東京Fallでは「SQLインジェクション"ゼロ"のPostgreSQL利用法 - 今更聞けないSQLインジェク ションの現実と対策」と題したセッションを日本PostgreSQLユーザ会の講師として話をさせて頂きます。

SQLインジェクションはとうの昔に枯れた話題と思われていますが、古くても今の問題です。何年か前、日本PostgreSQLユーザ会のセミナーで手作業でのブラインドSQLインジェクションのデモをした事がありますが今回はツールを使ったデモもあります。書いている間に当初作ろうと思っていたプレゼンとは異なる物なってしまいました。多少紹介から期待する内容とは異なっているかも知れません。既にSQLインジェクションについては十分知っている方でも、それなりに(?)楽しめる内容になっていると思います。おかげ様で満員だそうですが、飛び込みでも少しは入れるのかな？

45分なのに60枚もスライドがある上、デモもあります。かなりハイペースで話すことになります。ネットで直ぐに見つかるような基本的な事はあまり書かなかったのですが、無いようで書くとSQLインジェクションについて色々在る物です。多少スライドは飛ばす事になります。

ほぼ同じ内容でOSC高知でも話をさせて頂く予定です。
来たくても来れなかった方は是非高知でお会いしましょう。

この本は今年のPHPカンファレンスで景品として頂いた本です。

CakePHPと言えば「CakeMatsuriTokyo2009」が10/30, 10/31に開催されます。興味がある方、CakePHPによるWeb開発にさらに磨きをかけたい方は参加されてはどうでしょうか?

...

この本はオンラインマニュアル等で簡単に入手できる情報は省略されています。CackePHPは全く初めて、という方はWebサイトのオンラインマニュアルやチュートリアルなどをさっと読んでから読むと良いでしょう。

この本はPHPとPHPによるWeb開発には経験があるけどCakePHPによる開発はこれから、という方にはお勧めの本です。他のフレームワークを使っているけど、最近元気なCakePHPによる開発はどんな感じなのか知りたい方にもお勧めです。

アマゾンの書評では初心者向けの記述が無い事を不満に思った方もいますが、インターネット時代の技術書の形の一つとして「簡単に調べられる事は解説しない」はあって良いのではないかと思っています。PHP経験者でこれからCakePHPを使用した本格的なWebアプリを作る、でもCakePHPはまだ知らない、という読者には非常に良い本だと考えています。

本格的にSubversionからGitへの移行を行った際に作ったGit+SSHサーバの手順をWikiに書きました。この手順を実行すると

• SSHの公開鍵を持っているユーザにのみリポジトリへのアクセスを許可
• 複数あるリポジトリへのアクセス許可を個別に設定
• グループを設定して「読み込み」「書き込み」の権限を管理

ができるようになります。

詳しくはWikiのgit sshサーバの構築をご覧下さい。

Subversionの頃はWebDAV+SSL+Basic認証だったので以前と比べればかなり認証の安全性は増したと言えます。

PHP 5.2.11用のStrict Session Patchを公開しました。

http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession

これが無いとセッション管理が面倒です。 どう面倒なのかは既に何度も書いているので省略します。(本当は面倒なだけではないのですが.. ）最新リリースの追随がいつも遅れているので、もし作った方は送って頂けると助かります。

もし問題を発見した場合は教えて下さい。直します。

このパッチを使っているサイト例はこのブログです :)