PostgreSQL 9.0から使える識別子とリテラルのエスケープ

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

エスケープ処理が必要なのにエスケープ用のAPIが無い状態は良くありません。エスケープしないために動かないのはまだ良い方です。エスケープが必要なのにエ スケープをしなくても動いてしまい、セキュリティ上の問題となる場合もあります。全てのアプリケーション・ライブラリはエスケープが必要なデータに対するAPIを持っておくべき です。今回はPostgreSQL 9.0から追加されたエスケープ関数を紹介します。

PostgreSQL使い始めて最初の頃に気づくのはuserなどの予約語がフィールド名に使えない事かも知れません。例えば、

と失敗してしまいます。これはuserがPostgreSQLの予約語であるためSQL文の識別子として使用できないからです。MS Accessからデータベースに入った方には識別子に日本語を使う場合も多いので、PostgreSQLでは日本語のテーブル名やフィールド名はそのままでは使えない事に気が付いた方も多いのではないでしょうか? “PostgreSQL 9.0から使える識別子とリテラルのエスケープ” の続きを読む

gihyo.jp セキュリティ対策が確実に実施されない2つの理由

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をサポートするプラットフォームがまだ少ないからこれは仕方がない部分でしょう。あって当然だった識別子のエスケープも解説されていないのは残念ですね。一般論として識別子のエスケープについては解説があった方がよいでしょう。プリペアードクエリを使っていてもエスケープが必要なケースです。紹介しないと完全な解説にはなりません。

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

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

PHP5.3.9RC2とPHP5.4.0RC2リリース

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

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

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

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

“PHP5.3.9RC2とPHP5.4.0RC2リリース” の続きを読む

セッションのクッキーを設定する場合のベストプラクティス

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

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

“セッションのクッキーを設定する場合のベストプラクティス” の続きを読む

PHP 5.4のビルトインWebサーバの性能

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

ツイッターでWebrick(RubyのビルトインというかRuby製のWebサーバ)+素のRailsページはjRubyで44reqs/sec、cRubyで98reqs/secでした、とのツイートを見かけて、PHPのビルトインWebサーバはどの程度かな?と思って手元のマシンで実行してみました。 “PHP 5.4のビルトインWebサーバの性能” の続きを読む

PHPのSession Adoptionを修正するパッチ

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

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

パッチ

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

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

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

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

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

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

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

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

PROVE for PHP 1.0.3を公開

私の会社で開発・販売している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のダウンロードも開始しました。

PHP 5.4から利用できるtraitの利用例

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

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

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

元のコードは色々問題があるので書き直しました。こうやればアクセサーを沢山書く必要が無くなります。 “PHP 5.4から利用できるtraitの利用例” の続きを読む

Bit module for PHP

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

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

https://github.com/yohgaki/bit

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

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

RealIP Module for PHP

リバースプロキシの背後にある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のスクリプトを使ってアダプティブなPHPセッションをアダプティブにしない方法を紹介します。

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

まずはセッションアダプションの原理と対策の復習をしておきます。 “PHPセッションアダプションをスクリプト側で修正する方法” の続きを読む

PHP 5.4の文字エンコーディング設定

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の検出ツール

久しぶりにブログを更新すると色々書きたくなるものですね。ということでまだこのブログでは紹介したことがない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のSession Adoption脆弱性

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 に再度メールをしておきました。さて、今回はどうなることでしょう?

PROVE for PHP Ver 1.0

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

http://www.provephp.com/

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

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

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