正規表現でのメールアドレスチェックは見直すべき – ReDoS

前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS(十分短い文字列で指数関数的に実行時間が増加する)が可能なことが判りました。

結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。(特にRubyユーザー)

追記:影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイトルが「正規表現でのメールアドレスチェックは見直すべき 」になっています。

“正規表現でのメールアドレスチェックは見直すべき – ReDoS” の続きを読む

StackExchangeが攻撃されたReDoSの効果

StackExchangeがReDoS攻撃に遭いサイトがダウンした原因をStackExchangeのブログで紹介していました。

PHPへの影響があるか試してみました。結論を書くと、脆弱な正規表現を使っていて攻撃者が入力をコントロールできる場合、簡単に攻撃できるようです。PCRE、Onigurumaの両方で試してみましたがどちらも脆弱でした。

参考:正規表現でのメールアドレスチェックは見直すべき – ReDoS Onigurumaでは破滅的なReDoSが可能です。以前からメールアドレスのチェックに利用する正規表現には注意喚起していましが、どの程度浸透していたのだろうか?

“StackExchangeが攻撃されたReDoSの効果” の続きを読む

mbstring正規表現デフォルト文字エンコーディングは”EUC-JP”だった

デフォルト文字エンコーディング設定の仕様変更はPHP 5.6リリースの際に私が行った変更ですが、ブログで紹介していなかったような気がするので紹介します。PHP 5.5以下のmbstring正規表現デフォルト文字エンコーディングは”EUC-JP”でした。

一応、RFCには

  • all functions that take encoding option use php.internal_encoding as default (e.g. htmlentities/mb_strlen/mb_regex/etc)

と書いているのですが、これだけではmb_eregなどのデフォルト文字エンコーディングが変わっている事に気が付かない方も多い(気が付かない方が多い?)と思います。

“mbstring正規表現デフォルト文字エンコーディングは”EUC-JP”だった” の続きを読む

なぜRubyと違い、PHPの正規表現で^$の利用は致命的な問題ではないのか?

Rubyデフォルトの正規表現では^は行の先頭、$は改行を含む行末にマッチします。PHPのPCREとmbregexでは^はデータの先頭、$は改行を含む行末にマッチします。

この仕様の違いはデータのバリデーションに大きく影響します。

参考: PHPer向け、Ruby/Railsの落とし穴 の続きの解説になります。こちらのエントリもどうぞ。

 

“なぜRubyと違い、PHPの正規表現で^$の利用は致命的な問題ではないのか?” の続きを読む