PHPへのメールヘッダーインジェクション
メールヘッダーインジェクションによる攻撃は一昔前に流行った攻撃です。最近ではあまり聞きませんが、PHPのmail/mb_send_mail関数はメールヘッダーインジェクションに対して十分に安全でしょうか？
実は十分に安全と言える対策は最近になって追加しました。１つは随分前に、もう１つは最近修正しています。それらの修正を紹介します。
正規表現でのメールアドレスチェックは見直すべき – ReDoS
前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS（十分短い文字列で指数関数的に実行時間が増加する）が可能なことが判りました。
結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。（特にRubyユーザー）
追記：影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイトルが「正規表現でのメールアドレスチェックは見直すべき 」になっています。
StackExchangeが攻撃されたReDoSの効果
StackExchangeがReDoS攻撃に遭いサイトがダウンした原因をStackExchangeのブログで紹介していました。
PHPへの影響があるか試してみました。結論を書くと、脆弱な正規表現を使っていて攻撃者が入力をコントロールできる場合、簡単に攻撃できるようです。PCRE、Onigurumaの両方で試してみましたがどちらも脆弱でした。
参考：正規表現でのメールアドレスチェックは見直すべき – ReDoS Onigurumaでは破滅的なReDoSが可能です。以前からメールアドレスのチェックに利用する正規表現には注意喚起していましが、どの程度浸透していたのだろうか？
正規表現を使ったDoS – ReDoS
いつかは忘れるくらい前に正規表現のアルゴリズム自体を利用してDoS攻撃を行うReDoSが発表されていました。今まであまり気にしていなかったのですが、検索しても日本語のページが出てこないようでした。詳しく知るためのリンクなどを紹介します。
メソッド／関数呼び出しによるコード実行問題とその対策
言語の機能としてシリアライズされた”データ”からオブジェクトを生成（PHPの場合、unserialize関数）したり、呼び出すメソッド／関数を指定できる機能（PHPの場合、call_user_func関数／call_method関数など）を使ったりすると意図しないメソッド／関数が呼ばれるケースを想定しなければなりません。
SMSを利用した2要素認証の脆弱性
SMSを利用した2要所認証を利用しよう、と検索される方も多いのでブログを書きます。SMSを利用した2要素認証の場合、Google認証システムを利用した場合に比べ、アプリの導入が不必要で容易に導入できます。しかし、リスクが高い部分があるので注意が必要です。
攻撃者がどうやって脆弱性を見つけ攻撃するのか、仕組みを知れば対策も解る
「攻撃者がどうやって脆弱性を見つけ攻撃するのか」これは比較的よくセキュリティ対策で解説されていることだと思います。本質を理解し、対策を考えます。
今時のShellcodeとセキュア／防御的プログラミング
コンピュータセキュリティのことを考えるとShellcode（シェルコード）のことを忘れる訳にはいきません。Shellcodeとはバッファーオーバーフローを利用してコンピューターに任意コードを実行させるコードの総称です。そもそもは/bin/shなどのシェルを奪うコードが主だったので、この種のコードはShellcodeと呼ばれています。現在はシェルを奪う物だけでなく、他の操作を行う物もShellcodeと呼ばれています
Shellcodeを作る方は、山があるから登るのと同じで、Shellcodeが作れるから作る、のだと思います。
私個人はShellcodeを作ること、使うことに全く興味はないです。しかし、Shellcodeとそれを利用した攻撃は、防御の為に興味を持っています。簡単に今どきのShellcodeはどのようになっているのかまとめます。
リクエストフォージェリ – SSRFとCSRF
リクエストフォージェリ（Request Forgery – リクエスト偽造）はかなり古くから知られている脆弱性です。恐らく1980年代から良く知られていたはずです。昔から知られているSSRFとCSRFの類似性を考えてみます。類似性を考えると、少し解りづらいCSRFも簡単に理解できるかも知れません。
OTP（ワンタイムパスワード、2要素認証）とタイミング攻撃
今すぐできる、Webサイトへの2要素認証導入と2要素認証のTOTPとHOTP、どちらがより安全か？で紹介したGoogleAuthenticatorですが、ソースコードを確認ところタイミング攻撃に脆弱でした。Pull Requestを後で送る予定ですが、利用される場合は脆弱性を修正してから使ってください。
安全なAPI過信症候群の処方箋 – execv/SQLite3編
またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きます。安全なAPI過信症候群と名付けました。
安全なAPI過信症候群（同類にプリペアードクエリ過信症候群など）：「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力バリデーションを「必要ない、できない、セキュリティ対策ではない」エスケープは「必要ない、有害である」とする場合、かなり重度の場合が多い。
このブログでは既に何度もプリペアードクエリクエリは不完全である、と指摘しています。プリペアードクエリを使っていれば安全と盲目的に信じている方向けの基礎知識を紹介します。コマンド実行APIのexecvと最も多く利用されているRDBMS、SQLite3が題材です。
現実を知れば安全とされるAPIを盲信することも危険だと解り、安全なAPI過信症候群を完治できると思います。
WordPress MailPoet (wysija-newsletters) Unauthenticated file Uploadの原因と対策
今時、ファイルアップロードに脆弱であることは珍しいので WordPress MailPoet (wysija-newsletters) Unauthenticated file Upload として知られている脆弱性を調べてみました。 もっと読む
Rails ActriveRecordとSQLインジェクションと実際のアプリケーション
先日はActive RecordのSQLインジェクションパターンを紹介しました。今回は脆弱なコードを見つける事を試みようと思います。脆弱とは言っても攻撃可能であることは意味しません。コーディングとして脆弱であるという意味です。実際に攻撃可能であるかどうかまでは確認していません。
Heartbleed脆弱性と漏洩する情報のまとめ
Hearbleed脆弱性はSSL接続を処理するサーバーのメモリ内容を盗める脆弱性です。メモリ内には様々な機密情報が含まれています。Webサーバープロセスのメモリ内に保存されている内容は全て盗まれる可能性があります。セッションIDやユーザーのパスワードが盗める場合もあります。Heartbleed脆弱性は任意アドレスのメモリ内容をリモートから自由に読み出す脆弱性なので、サーバーのメモリ内に保存された秘密情報は、SSL秘密鍵に限らず、メモリ内容から盗めます。
影響範囲はシステム構成により異なるので、どのような条件で盗まれるのかまとめました。