do_akiさん「mysqlnd 徹底解説⁠」⁠

do_akiさんはmysqlndを解説しました。

PHPとMySQLの間のアクセスは，現在すべてlibmysqlまたはmysqlnd（MySQLNativeDriver）のどちらかを介して行われています。mysqlndで注目されている新機能には，非同期クエリやパフォーマンス統計があります。

libmysql vs mysqlnd

do_akiさんは，双方の違いを説明していきました。

• libmysqlclient：Oracleによって開発
• mysqlnd：PHP communityによって開発

したがって，当たり前ですがコンパイル方法が違います。mysqlndはPHP5.3以前では使えません。5.3からバンドルされるようになり，5.4になってmysqlndがdefaultになりました（libmysqlはオプショナルに⁠）⁠。

なぜ似たような機能をもつものが2つあるのか，という疑問に対しては，ライセンス問題の解消が主な目的であるとのことです。libmysqlはGPLv2という若干特殊なライセンスであり，同梱して別のところに配布ができないのに対し，mysqlndはPHP Licenseであり，基本的にライセンス面を気にしなくてよいです。

また，libmysqlは，他の言語でも使えるのに対し，mysqlndはPHPのみでしか使えないという点も挙げていました。互換性にも問題があり，mysqlndで使えなくなった機能があります。PHPのバージョンを上げたことによりライブラリもmysqlndに変わり，それによって正しく動かなくなることがあるので注意が必要です。

mysqlndの内部

プリペアドステートメントを使う際，mysqlnd内部の特徴として型の問題があります。今までPHPではstring型で格納されていたものが，カラムの型そのままで入るようになります（気づかずに，はまりやすい！とのこと⁠）⁠。この変更はPDOを使った場合のみで，mysqliの場合は元々binary protocolでカラムの型で取ってきます。

また，mysqlndはメモリ使用量が少なくなると言われていますが，それは次の理由があります。

• libmysqlではMySQLから返ってくるデータに対し二回変数コピーが走っているイメージ
• mysqlndは単純にデータをそのままPHPスクリプトに返す

ただ見た目上のメモリ（get_usage_memory()で取れるメモリ）は増えていたりするため，memory_limitを設定している場合はひっかかってFatalエラーになりやすくなる，という盲点があるそうです。

最後に結論として，使い方によっては便利なmysqlndですが，PDOの場合はあまり使用量が変わらなかったりするので，フルで使いたいなら現状はmysqliを使いましょうと述べていました。

徳丸浩さん「安全なPHPアプリケーションの作り方2014 ～必要最低限のセキュリティ対策はこれだ～⁠」⁠

徳丸浩さんは，安全なPHPアプリケーションのセキュリティ対策について発表しました。これまで何回も同じ題目で話してこられていますが，今日は基礎的なことにフォーカスしました。

PHP自体の脆弱性

IPA「セキュアプログラミング講座」によると，脆弱性対策として「例えばPHPを避ける」ことが挙げられています（会場笑い⁠）⁠。これは，PHP自体に脆弱性が多いという観点からのものですが，徳丸さんに言わせると，それは過去の話であるとのこと。

たしかに比較演算子などはゆるい部分もあったり，たまにすごい脆弱性が出てくるのも事実ですが，それはどの言語でもありえるのでPHP特有の問題ではありません。一番大変なのは，ほぼ毎月行われるバージョンアップについていくことで，その情報をキャッチアップして対策していくことです。

この対策に対する基本的な選択肢は，次のことを挙げました。

• PHPバージョンアップにとことん付き合う（毎月確認する）
• 影響を受ける脆弱性がある場合のみバージョンアップする
• LinuxディストリビューションのパッケージとしてPHPを導入してバッチを適用する

また，ハウジング，Iaas/VPS, Paas, Saasそれぞれの脆弱性対処のメトリクスを示しました。ハウジングで自分たちで対策を行うことは脆弱性対処の責任も負うことであるのに対し，クラウドであれば基本的には行ってくれます。ただし細かいパッチ適用など，ベンダーによっては要確認であると注意喚起しました。

アプリケーションの脆弱性を対処しよう

次に，CSRF（クロスサイトリクエストフォージェリ）を説明しました。昨年今年と巷を騒がせた片山被告の最初の事件と同様のCSRFをサイトに仕込み，犯行予告の書き込みをデモンストレーションしてみせました。また，日本で最も売れているPHP教科書でCSRF対策していないと，チクリ刺すのも忘れていません。

続いて，XSS（クロスサイトスクリプティング）の説明では，「⁠ぼくはまちちゃん！」をデモしました。

「出力をエスケープしましょう」というこれまでのアドバイスに加えて，特筆すべき注意喚起としては，「⁠JavaScriptの動的生成はやめましょう」とのことです。「⁠JavaScriptのエスケープ処理は人類には難しすぎる！ので，HTML上に値を生成して，それをgetElementBy**()などで取得したほうがよい」と言及しました。

また，最近はブラウザ側で対処してくれることが多いですが，まだIE6を使ってる人も実際存在しますし，他の脆弱性の可能性もあるので，サーバサイドで対処しておくのもまだ忘れないようにしましょうと指摘しました。

最後にSQLインジェクションを取り上げました。最近になって，MySQL＋PDOでもDB改ざんの可能であることが判明しました。これはおそらく最もよくあるパターンなので，今もまだ多くの開発者が対応しなければなりません。

具体的な対応法は，これまで同様に次のようになります。

• プレースホルダーを使いましょう
• 静的のほうがよい
• 接続時に文字エンコーディングを必ず指定する

その他，HTTPヘッダインジェクション，セッションID固定化の問題にも触れ，この後の大垣さんとのセッションへの布石も打っていました。

まとめ

アプリケーション脆弱性対策は，現在のPHPの実状に沿った現実的な対策を上記例を挙げて説明しました。プラットフォームの脆弱性を対策については，「⁠自分でビルドするのか，プラットフォームの脆弱性対策に任せるのかの判断が大切である」と述べていました。