メソッド/関数呼び出しによるコード実行問題とその対策

言語の機能としてシリアライズされた”データ”からオブジェクトを生成(PHPの場合、unserialize関数)したり、呼び出すメソッド/関数を指定できる機能(PHPの場合、call_user_func関数/call_method関数など)を使ったりすると意図しないメソッド/関数が呼ばれるケースを想定しなければなりません。

“メソッド/関数呼び出しによるコード実行問題とその対策” の続きを読む

SMSを利用した2要素認証の脆弱性

SMSを利用した2要所認証を利用しよう、と検索される方も多いのでブログを書きます。SMSを利用した2要素認証の場合、Google認証システムを利用した場合に比べ、アプリの導入が不必要で容易に導入できます。しかし、リスクが高い部分があるので注意が必要です。

参考:今すぐできる、Webサイトへの2要素認証導入

“SMSを利用した2要素認証の脆弱性” の続きを読む

今時のShellcodeとセキュア/防御的プログラミング

コンピュータセキュリティのことを考えるとShellcode(シェルコード)のことを忘れる訳にはいきません。Shellcodeとはバッファーオーバーフローを利用してコンピューターに任意コードを実行させるコードの総称です。そもそもは/bin/shなどのシェルを奪うコードが主だったので、この種のコードはShellcodeと呼ばれています。現在はシェルを奪う物だけでなく、他の操作を行う物もShellcodeと呼ばれています

Shellcodeを作る方は、山があるから登るのと同じで、Shellcodeが作れるから作る、のだと思います。

私個人はShellcodeを作ること、使うことに全く興味はないです。しかし、Shellcodeとそれを利用した攻撃は、防御の為に興味を持っています。簡単に今どきのShellcodeはどのようになっているのかまとめます。

“今時のShellcodeとセキュア/防御的プログラミング” の続きを読む

リクエストフォージェリ – SSRFとCSRF

リクエストフォージェリ(Request Forgery – リクエスト偽造)はかなり古くから知られている脆弱性です。恐らく1980年代から良く知られていたはずです。昔から知られているSSRFとCSRFの類似性を考えてみます。類似性を考えると、少し解りづらいCSRFも簡単に理解できるかも知れません。

“リクエストフォージェリ – SSRFとCSRF” の続きを読む

OTP(ワンタイムパスワード、2要素認証)とタイミング攻撃

今すぐできる、Webサイトへの2要素認証導入2要素認証のTOTPとHOTP、どちらがより安全か?で紹介したGoogleAuthenticatorですが、ソースコードを確認ところタイミング攻撃に脆弱でした。Pull Requestを後で送る予定ですが、利用される場合は脆弱性を修正してから使ってください。

“OTP(ワンタイムパスワード、2要素認証)とタイミング攻撃” の続きを読む

安全なAPI過信症候群の処方箋 – execv/SQLite3編

またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きます。安全なAPI過信症候群と名付けました。

安全なAPI過信症候群(同類にプリペアードクエリ過信症候群など):「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力バリデーションを「必要ない、できない、セキュリティ対策ではない」エスケープは「必要ない、有害である」とする場合、かなり重度の場合が多い。

このブログでは既に何度もプリペアードクエリクエリは不完全である、と指摘しています。プリペアードクエリを使っていれば安全と盲目的に信じている方向けの基礎知識を紹介します。コマンド実行APIのexecvと最も多く利用されているRDBMS、SQLite3が題材です。

現実を知れば安全とされるAPIを盲信することも危険だと解り、安全なAPI過信症候群を完治できると思います。

追記:普通のRDBMS編も作りました。SQLiteの仕様でデータ型がどうなっているか簡単に説明しました。

“安全なAPI過信症候群の処方箋 – execv/SQLite3編” の続きを読む

Rails ActriveRecordとSQLインジェクションと実際のアプリケーション

先日はActive RecordのSQLインジェクションパターンを紹介しました。今回は脆弱なコードを見つける事を試みようと思います。脆弱とは言っても攻撃可能であることは意味しません。コーディングとして脆弱であるという意味です。実際に攻撃可能であるかどうかまでは確認していません。

 

“Rails ActriveRecordとSQLインジェクションと実際のアプリケーション” の続きを読む

Heartbleed脆弱性と漏洩する情報のまとめ

Hearbleed脆弱性はSSL接続を処理するサーバーのメモリ内容を盗める脆弱性です。メモリ内には様々な機密情報が含まれています。Webサーバープロセスのメモリ内に保存されている内容は全て盗まれる可能性があります。セッションIDやユーザーのパスワードが盗める場合もあります。Heartbleed脆弱性は任意アドレスのメモリ内容をリモートから自由に読み出す脆弱性なので、サーバーのメモリ内に保存された秘密情報は、SSL秘密鍵に限らず、メモリ内容から盗めます。

影響範囲はシステム構成により異なるので、どのような条件で盗まれるのかまとめました。

“Heartbleed脆弱性と漏洩する情報のまとめ” の続きを読む

SSL暗号を無効化する仕組み – BREACH, CRIME, etc

CRIMEBREACHといったSSL暗号を無効化する攻撃を知っている方は多いと思います。しかし、その仕組みや攻撃方法は広くは理解されていないようです。Webシステムに関わる方であれば、BREACH攻撃の原理と対策を理解しておいて損はありません。BREACHや類似の攻撃は全く難しくありません。直ぐに理解できると思います。原理は簡単です!
“SSL暗号を無効化する仕組み – BREACH, CRIME, etc” の続きを読む

Sessionアダプション脆弱性の修正

やっとPHPのセッションアダプション脆弱性を修正するパッチとプルリクエストを作りました。議論は済んでいるのでパッチを検証、調整してマージするだけです。

PHPに限らず、未初期化のセッションIDを正規のセッションIDとして受け入れてしまうセッション管理機構があります。(Javaとか)

サイトで稼働している全てのアプリが正しいセッション管理(ログイン後にセッションID作り直す。ログオフで廃棄。一定時間経過後、セッションIDを再生成)を実行していれば良いのですが、共有環境や複数のアプリが使われる事が多いPHPでは特にリスクが高くなっています。

未初期化のセッションIDを受け入れてしまうセッション管理機構は脆弱だと言って良いと考えています。セキュリティのベストプラクティスには確立されたセキュリティ手法(ベストプラクティス)はそのまま使うべき、というプラクティスがあります。つまり、信頼できるフレームワークのセッション管理機構をそのまま使いなさい、がベストプラクティスという事です。しかし、フレームワークとしてURLへのセッションID埋め込みをサポートしているのに、簡単に直せるセッションアダプションを修正しないフレームワークは到底「ベストプラクティスを実装している」と言える状態ではないと考えています。

セッションアダプション脆弱性についてはPHPのWiki(英語のみ)に書いています。詳しくは以下のWikiを参照してください。

“Sessionアダプション脆弱性の修正” の続きを読む

セッションアダプションとセッションフィクセイションとセッションハイジャックの違いとは

徳丸さんがセッションアダプションをなくしても、セッションハイジャックが出来るので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などで良いので教えてください。よろしくお願いします。

 

このパッチについては、こちらをご覧ください。これは私が書いているのでおかしな英語があった場合、教えて頂けると助かります。

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

PHPのセッションアダプション脆弱性克服への道のり

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

PHPのセッション管理は非常に簡単です。セッションをsession_start()で開始して$_SESSION配列を使うだけです。便利で簡単なセッションモジュールですがセッションアダプションに脆弱であるため、一般に言われてる「ログインする時にはsession_regenerate_id()を呼ぶ」コーディングではセッションアダプションに脆弱になってしまいます。

まずは危険性と対策を紹介します。 “PHPのセッションアダプション脆弱性克服への道のり” の続きを読む

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

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

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

パッチ

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

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

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

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

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

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

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

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

phpのescapeshellcmdの余計なお世話を無くすパッチ

徳丸さんのブログでescapeshellcmdの余計なお世話の件が指摘されていたのでパッチを作りました。これmagic quoteと同じレベルの余計なお世話なのですが放置されています。個人的にはどのような関数にも全てバリデーション済みの文字列しか渡さないのでセキュリティ問題は発生しないのですが、UNIX系OSではペアとなる”と’はエスケープしない仕様に気が付いていないプログラマも多いかもしれません。

“phpのescapeshellcmdの余計なお世話を無くすパッチ” の続きを読む

Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由

Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由を詳しく解説されたブログエントリまっちゃさんのブログで知りました。 入力で特には何もしていない事は知っていたので、出力時のどこかで全体をチェックできるような仕組みになっているのでは?と思っていたのですが、ETagの値を生成するコードの正規表現で例外が発生する、という事だそうです。 “Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由” の続きを読む