出力先のシステムが同じでも、出力先が異なる、を意識する
出力先のシステムが同じでも、出力先が異なる場合はよくあります。これを意識していないとセキュリティ問題の原因になります。
もっと読む
JavaScript文字列エスケープの解説
JavaScript文字列のエスケープの解説というか補足です。
エンジニア必須の概念 – 契約による設計と信頼境界線
少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。
契約による設計（契約プログラミング）（Design by Contract – DbC）は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。
もっと読む
JavaScript文字列のエスケープ
サーバー側のプログラムでJavaScriptの文字列にデータを出力するケースはよくあります。このような場合、エスケープ処理を行うことが必須です。
JavaScript文字リテラルは次のように定義されています。（ECMAScript 5.1）
XPathクエリ（2）
XPathクエリ（1）の続きです。
現在のPHPのXPathクエリの問題はXPath 1.0である事です。通常の仕様書であれば特殊文字のある文字列の場合はエスケープ方法やエスケープAPIが定義されています。エスケープ方法が定義されていなければ「特殊文字を入力することができない」からです。エスケープ方法が無い場合は「エスケープが必要ないAPI」を用意すべきです。
しかし、XPath 1.0ではエスケープ方法もエスケープAPI、エスケープが必要ないAPIも定義されていません。このような場合、仕様を実装しているライブラリの実際の挙動を確認して利用することになります。PHPのSimpleXML、XMLXpathクラスの場合はlibxml2を利用しているので、libxml2の動作を確かめる必要があります。
XPathクエリ（1）
XPathはXML文書をクエリして要素を取り出す仕組みです。XML文書を検索して結果を返します。
SimpleXMLにはxpathメソッドが用意されています。
SimpleXMLElement::xpath
<?php
$result = $simple_xml_obj->query('my/x/path');
?>
SQL識別子のエスケープ
SQLのリテラルはエスケープが必要であることは広く認知されていると思います。しかし、識別子のエスケープはあまり広く認知されていないように思います。
PostgreSQLの場合、識別子のエスケープAPI（libpqのPQescapeIdentifier）が提供されておりPHPでもpg_escape_identifier()として利用できます。PostgreSQLの場合は”（ダブルクオート）で識別子を囲むことにより、ダブルクォート無しでは利用できない文字（例えば日本語）も識別子に利用できるようになります。
もっと読む
LDAPエスケープ – PHPのldap_escape関数
OWASP TOP10の1位のセキュリティ脅威はインジェクションです。
https://www.owasp.org/index.php/Top_10_2013-A1-Injection
SQLインジェクション、コマンドインジェクションはリファレンスとして掲載されていますが、何故かLDAPインジェクションは掲載されていません。しかし、OWASPの別の文書では簡単に解説されています。
入力バリデーションはセキュリティ対策として＊あてにする＊ものではありません
ブログを書き出すと、次々に書きたくなるので困ったものです。
徳丸さんに返信した前のエントリのリンクに「もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう」とあったので補足しておきます。
そもそも入力バリデーションは「あてにする」ような物ではありません。セキュリティ対策としては「転んだ時に役立つかも知れない杖」と捉えるべきです。役立つか役立たないかは分かりませんが、SANS/CWE TOP 25で「怪物的な緩和策」（Monster Mitigation）のNo 1として挙げられているセキュリティ対策です。
つまり、毎年多数登録されるソフトウェア脆弱性データベースであるCVEデータベースのセキュリティ問題に対して、最も効果があるセキュリティ対策である、という事です。運任せでも統計的に役立つ事が実証されているセキュリティ対策を導入しないのは効果的なセキュリティ対策であるとは言えません。
入力バリデーションは「あてにする」ような物ではありませんが、セキュリティ対策として必ずやるべき対策です。運任せなので、より幸運にも脆弱性が攻撃できない状況になるよう、ホワイトリスト方式で厳格にバリデーションするのが正しいやり方です。
入力バリデーションはセキュリティ対策の基本
徳丸さんとはホワイトリスト VS ブラックリストの議論から楽しく話をしています。私はホワイトリスト型で対処する方がよりセキュアであると考え、徳丸さんはブラックリストも変わらない。としています。考え方が反対なので楽しいのです。残念ながらあまりブログなどに時間を取りなくないのですが、わざわざ徳丸さんがブログを書いた、とツイッターで教えていただいたので簡単に返信しておきます。
http://tumblr.tokumaru.org/post/55587596019
私は「バリデーションはセキュリティ対策とは言えない」と思っているのですが、実は「世界の常識」という点に異論があるわけではなくて、話は逆なのです。「従来からバリデーションはセキュリティ対策としてとらえられてきて『世界の常識』となっているが、実はそれはおかしいのではないか?」という問題提起をしているのです。なので、「世界の常識だろ」と言われても、それでは反論になっていません。
結論からいうと入力パラメータのバリデーションは世界のセキュリティ専門家によって非常に有用なセキュリティ対策だと認められています。
ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
参考：プログラムが正しく動作するには、正しい「データ」と「コード」両方が必須。データのバリデーション（＝セキュリティ対策）がない対策はあり得ない。
Webノウハウシェア2013のスライド
5月24日（金）に開催されたWeb担当者向けのセミナーの「Webノウハウシェア2013」にBOSS-CON JAPANのPHP Security AlianceのCTOとして講演してきました。その講演のスライドです。
http://www.slideshare.net/yohgaki/boss-conphp
Javascriptを利用した内部ネットワークのスキャンが可能である事は良く知られていると思います。ここ数年セキュリティ研究者は更に企業ネットワーク内の奥深くに侵入する手法を研究しています。
企業内のシステムはインターネットに公開するシステムに比べると甘いセキュリティ対策が採用される事が多いですが、インターネットと同様のセキュリティ対策を行わないと思わぬリスクが発生します。特にSSRFの脅威は広範囲に渡ります。正しく理解しておく必要があります。
追記：PHPユーザに取って重要な事の1つを紹介しておきます。
PHP-FPMを利用する場合、php_admin_value, php_admin_flagでphp.iniを設定する方が良いでしょう。手元のFedora18のNginx+PHP-FPMでPoCをそのまま実行した所、エラーになって攻撃は成功しませんでしたが、php.iniの設定をリモートから変更できるとする情報もあります。
追記：ブログアプリ変更でリンクが無くなっていたので、SlideShareの方に公開しました。
セッションID管理は結局どうすれば良いのか？
脆弱性やセキュリティ対策について技術的な話ばかりしていたので「それで結局PHPのセッション管理どうすれば良いの？」と思われた方も多いと思います。簡単にまとめます。漏れや追記した方が良い事などがあったらご指摘ください。
PostgreSQL 9.0から使える識別子とリテラルのエスケープ
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では日本語のテーブル名やフィールド名はそのままでは使えない事に気が付いた方も多いのではないでしょうか？ もっと読む
セッションのクッキーを設定する場合のベストプラクティス
HTTPセッションは通常クッキーを利用して行います。クッキーを利用したセッションの場合、お薦めする設定は以下の通りです。
- ドメイン名は指定しない
- パスはルート(/)を指定する
- セッション管理用のクッキーはセッションクッキー（有効期間０）にする
- httponly属性を付ける
- 可能な場合は必ずsecure属性をつける
- 複数アプリケーションを利用する場合はsession.nameまたはsession_name()でセッションクッキー名で指定する （アプリケーションの固有名デフォルトで設定し、設定項目として変更できるようにする）
ホワイトリストとブラックリスト – Firewallの場合
ホワイトリストとブラックリストの議論はFirewallの利用が一般的になる過程で十分に議論され、90年代に議論され尽くした、と思っていました。しかし、解説の余地はまだまだあるようです。ネットワークFirewallによるセキュリティ対策を簡単に振り返り、セキュアコーディングの現状を考察したいと思います。
追記：このエントリはネットワークFirewallのポートフィルタリングについて議論しています。ホワイトリストで対策すべきはアプリケーション自体です。ネットワークFiewallはホワイトリスト型セキュリティで対策しますが、WAFなどのアプリケーションFirewallはブラックリスト方式で対策するのが現実的です。ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。