echo:comma vs dot

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

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

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