SSL暗号を無効化する仕組み – BREACH, CRIME, etc
CRIMEやBREACHといったSSL暗号を無効化する攻撃を知っている方は多いと思います。しかし、その仕組みや攻撃方法は広くは理解されていないようです。Webシステムに関わる方であれば、BREACH攻撃の原理と対策を理解しておいて損はありません。BREACHや類似の攻撃は全く難しくありません。直ぐに理解できると思います。原理は簡単です！
もっと読む
SSLでの圧縮の利用は禁止
他人のブログのコメントに書いて、自分のブログに書かないのも良くないので一応ここにも書いておきます。
「SSLでの圧縮の利用は禁止した方が安全」です。
Sessionアダプション脆弱性の修正
やっとPHPのセッションアダプション脆弱性を修正するパッチとプルリクエストを作りました。議論は済んでいるのでパッチを検証、調整してマージするだけです。
PHPに限らず、未初期化のセッションIDを正規のセッションIDとして受け入れてしまうセッション管理機構があります。（Javaとか）
サイトで稼働している全てのアプリが正しいセッション管理（ログイン後にセッションID作り直す。ログオフで廃棄。一定時間経過後、セッションIDを再生成）を実行していれば良いのですが、共有環境や複数のアプリが使われる事が多いPHPでは特にリスクが高くなっています。
未初期化のセッションIDを受け入れてしまうセッション管理機構は脆弱だと言って良いと考えています。セキュリティのベストプラクティスには確立されたセキュリティ手法（ベストプラクティス）はそのまま使うべき、というプラクティスがあります。つまり、信頼できるフレームワークのセッション管理機構をそのまま使いなさい、がベストプラクティスという事です。しかし、フレームワークとしてURLへのセッションID埋め込みをサポートしているのに、簡単に直せるセッションアダプションを修正しないフレームワークは到底「ベストプラクティスを実装している」と言える状態ではないと考えています。
セッションアダプション脆弱性についてはPHPのWiki（英語のみ）に書いています。詳しくは以下のWikiを参照してください。
セッションアダプションとセッションフィクセイションとセッションハイジャックの違いとは
徳丸さんがセッションアダプションをなくしても、セッションハイジャックが出来るのでsession_regenerate_id(true) （trueを付けると古いセッションデータは削除される）をしなければならないという記事を書かれています。
セッションアダプションがなくてもセッションフィクセイション攻撃は可能
http://tumblr.tokumaru.org/post/37676352092/session-adoption-and-session-fixation
まず結論を書きます。徳丸さんが「セッションフィクセイション攻撃は可能」と言われているのは間違いです。正しくは「セッションハイジャックが可能」です。
この議論は別々の異なる脆弱性を一緒にした議論で正しい議論とは言えません。セッションアダプション、セッションフィクセイション、セッションハイジャックとはどのような脆弱性なのか整理して議論する必要があります。
PHPのStrict Sessionパッチ
のんびりしていた訳ではありませんが、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などで良いので教えてください。よろしくお願いします。
このパッチについては、こちらをご覧ください。これは私が書いているのでおかしな英語があった場合、教えて頂けると助かります。
Git Hubの脆弱性とMass Asssignment
Git HubがMass Assignment脆弱性に脆弱で他のレポジトリが見れる状態だったらしい。問題は既に修正されています。
この脆弱性はRailsに限った事ではないし、古くからPHPを使っているユーザにとってはある意味懐かしい脆弱性でもあると思ったのでエントリを書いてみました。
PHPのセッションアダプション脆弱性克服への道のり
PHP Advent Calender用のエントリです。
PHPのセッション管理は非常に簡単です。セッションをsession_start()で開始して$_SESSION配列を使うだけです。便利で簡単なセッションモジュールですがセッションアダプションに脆弱であるため、一般に言われてる「ログインする時にはsession_regenerate_id()を呼ぶ」コーディングではセッションアダプションに脆弱になってしまいます。
まずは危険性と対策を紹介します。 もっと読む
PHPのSession Adoptionを修正するパッチ
パッチのテストのお願いです。
PHPerの長年の悩みの種であるセッションアダプションを修正するパッチをPHPに取り込めそうです。PHPのsubversionレポジトリのtrunkまたはPHP 5.4で利用できます。テストが終わったらPHPのレポジトリにコミットする予定です。（テスト期間は2011/11/22まで）
パッチ
少し古いですがパッチの解説
セッションアダプション関連のブログエントリ
- http://blog.ohgaki.net/how-to-make-php-session-strict-by-php-script
- http://blog.ohgaki.net/php-session-adoption-1
パッチに何か問題があったらご連絡頂けると助かります。問題なかったよ、も大歓迎です。
ツイッターの方がレスポンスは良いです。
メールご連絡頂いても構いません。ブログのコメントととして送信する場合はエラーメッセージを無視して送信してください。モデレーションが必要なコメントとして送信できます。
思い起こせばセッションアダプション脆弱性の修正は最初の提案から６年以上経っています。セッションアダプションとブラウザの仕様に関する理解を得られず今まで修正されてきませんでした。しかし、今回は修正できそうです。SQLインジェクション対策や入力のバリデーション処理もそうですが、正しいものは正しい。主張し続ければ時間はかかっても必ず正しい方が認められるのが世の中です。
今度こそPHPのアキレス腱であるセッションアダプション脆弱性を修正しましょう！
テストが可能な方は是非テストして頂けるよう、よろしくお願いします！
phpのescapeshellcmdの余計なお世話を無くすパッチ
徳丸さんのブログでescapeshellcmdの余計なお世話の件が指摘されていたのでパッチを作りました。これmagic quoteと同じレベルの余計なお世話なのですが放置されています。個人的にはどのような関数にも全てバリデーション済みの文字列しか渡さないのでセキュリティ問題は発生しないのですが、UNIX系OSではペアとなる”と’はエスケープしない仕様に気が付いていないプログラマも多いかもしれません。
Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由
Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由を詳しく解説されたブログエントリをまっちゃさんのブログで知りました。 入力で特には何もしていない事は知っていたので、出力時のどこかで全体をチェックできるような仕組みになっているのでは？と思っていたのですが、ETagの値を生成するコードの正規表現で例外が発生する、という事だそうです。 もっと読む
PHP:既知のセキュリティ脆弱性 – Session Adoption
追記：より新しい情報については間違いだらけのHTTPセッション管理とその対策をどうぞ。
PHPには広く知られているにも関わらず放置されている既知のセキュリティ脆弱性が幾つかあります。その一つがセッションモジュールのセッションアダプション(Session Adoption)脆弱性です。この脆弱性は現在広く利用されているWebアプリケーションの安全性に、非常に大きな影響を与える脆弱性です。
セッションアダプション脆弱性とはセッション固定化攻撃を可能とする脆弱性の一種です。セッションアダプションに脆弱なセッション管理システムは、ユーザ(ブラウザ)が送信してきた未初期化のセッションIDを受け入れ、セッションを初期化してしまいます。PHPに限らず、RailsやJavaのフレームワーク等、多くのWebフレームワークに発見されている脆弱性です。
セッションアダプション脆弱性を利用すると、攻撃者は長期間に渡って他人のIDを使う成りすましが可能になる場合があります。IDを盗みたい犯罪者には利用価値の高い脆弱性です。
この脆弱性は、10年以上前から問題視されている国別TLD(ccTLD)の属性ドメイン(国別Top Level Domain, co.jp, or.jpなどのドメイン)にも下位ドメインからクッキーが設定でき、サブドメインのクッキー設定が無視される(送信順序、優先順位がいい加減)、というとんでも無いクッキーの仕様と組み合わせると、大量の他人のユーザセッションIDを取得(設定)し、成りすます事ができます。
セッションアダプション問題は全てのPHP、PHP 4.4.9/PHP 5.2.8/PHP 5.3/PHP 6.0に共通する脆弱性です。
最近、影響範囲はかなり狭くなりましたが、まだまだ注意が必要な脆弱性であり、根本的な解決にはパッチと適切なセキュリティ対策が必要です。
エンティティ化された文字による任意コード実行
小泉さんが発見され昨年末に公開された脆弱性です。詳しくはアドバイザリをご覧いただくとして概要を解説します。
CVE
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-5557
アドバイザリ
[Full-disclosure] CVE-2008-5557 – PHP mbstring buffer overflow vulnerability
かなり特殊な設定といえる状況で問題となるようですが、ちょうどgihyo.jpで文字エンコーディングに関連したセキュリティ問題を解説しているので紹介します。
http://gihyo.jp/dev/serial/01/php-security/0019
http://gihyo.jp/dev/serial/01/php-security/0020
現行版のPHPに任意メモリ参照バグ – 攻撃コード付き
随分前から共有型Webホスティングサービスでは安全性を確保できないので、安全性を重視するサイト(ECなど)は最低限でも仮想ホスト型の共有サービスを利用すべきである、と言っています。
今回のエントリはPHPをApacheモジュールで共有型ホスティングサービスを利用しているユーザに影響します。SSLを利用している場合は秘密鍵を盗まれます。このバグはPHP 5.2.8でも修正されていません。当然ですがPHP 4.4.9でも修正されていません。
もっと読む
PHPのSessionモジュールの脆弱性
たまたま目に止まったブログがあるので紹介します。
PHP:session_set_save_handlerリファレンスマニュアルのサンプルにパス・トラバーサル脆弱性
http://www.tokumaru.org/d/20080818.html#p01
[php]session_set_save_handlerのパストラバーサルで任意コマンドの実行が可能
http://www.tokumaru.org/d/20080819.html#p01
この危険性はStrict Sessionパッチが作られた頃にも議論されていました。このパッチを摘要するとセッションアダプション脆弱性も修正します。もし、互換性なので要件で厳格なSession管理ができない場合でもセッションIDに利用可能な文字は安全な文字のみに限定されるのでパストラバーサルなどの問題は発生しません。
話は横道にそれますが、セッションアダプションの問題については、PHP 4.4.9リリース前にPHP Security Response Teamと議論しました。リリースノートを見れば解りますが、残念ながら良い結果ではありませんでした。いくつかの脆弱性をレポートしましたが、その内の一部の脆弱性のみに対応しただけです。これについては時間が出来次第エントリを書きます。
話を戻しますが、セッションモジュールの問題は随分前（何年も前）に議論されており、開発者のスタンスとしては「ユーザ側の問題」「ファイルストレージがあるのに態々自分作って自分の足を打つようなユーザが問題」「RDBMSをストレージに使ってエスケープしないでSQLインジェクションされるのと同じ」といった結論になってしまったと記憶しています。
セッションアダプションの問題を解決すれば、パストラバーサルの問題もSQLインジェクション問題も解決するのですが…
セッションアダプション脆弱性はリスクが不当に低く評価され過ぎです。PHPを利用されている方全てにStrict Sessionパッチをお勧めします。
PHP 4.4.8用のStrict Sessionパッチ
桝形さんから
http://blog.ohgaki.net/php-5-2-strict-session
で公開したパッチのPHP4.4.8版を送っていただきました。私のWikiにも添付ファイルとして掲載させていただきました。
http://d.hatena.ne.jp/masugata/20080714#p2
に掲載されているパッチと同じパッチです。
私は全てのPHPユーザがStrict Sessionパッチ適用すべきと考えています。詳しくはWikiをご覧ください。
http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession
桝形さん、パッチありがとうございました。