2019/02/09)正規表現は危険です。様々なリスクが正規表現にはあります。簡単に正規表現リスクとより安全に使う方法を紹介します。関連なぜ正規表現が危険なのか?理由は単純です。間違った正規表現を簡単に書ける当たり前ですが正規表現は、正規表現に合った文字列を検索します。これが理由で簡単に間違え易いです。少くなりましたが、正規表現マッチの最初と最後、の間違いは今でも多いです。文字列の先端/終端であったり、”\A”/”\z”が文字列の先端/終端であったりします。これを間違えると、簡単にセキュリティ用のバリデーター/フィルターとして役立たなくなります。正規表現は仕様として危険です。柔軟かつ複雑な文字列マッチ処理を行う”仕様”が危険です。この為に簡単にDoS攻撃に脆弱になります。PCREは柔軟かつ複雑な仕様によって可能になる多すぎるバックリファレンス、多すぎる再帰によるDoS攻撃を回数制限することによって防御できるようになっています。これで完璧かというとそうでもありません。その実例が次のブログです。「仕様として危険」と関連しますが正規表現は複雑な処理を行います。セキュアコーディングでは複雑な処理系にデータを送る場合、その処理系が期待する妥当なデータを送信すること、を要求しています。PCREはマルチバイト文字列のマッチを行う場合、UTF-8のみをサポートしています。文字エンコーディングが1つだけなので単純と言えるでしょう。それでも単純とは言いきれません。PCREはUTF-8文字列としてマッチさせる場合、内部的に文字エンコーディングのバリデーションを行うようになっています。このバリデーションが非常に重たい処理になっています。遅くなる、といったレベルの問題ではなく数百倍遅くなる、という場合もあります。数秒で完了可能な処理が数十分もかかってしまう場合があるのです。この為、PCREにはこのバリデーション処理を省略する機能が付いています。APIでは文字エンコーディングバリデーションを省略できます。PHPもPCREを多用しているので、Haskelのように文字エンコーディングバリデーションを省略できるようにしよう、と提案があったのですが「テストとしてLinuxのバイナリファイル全て(当然ですがUTF-8ととして妥当でないデータ)でマッチさせてみたらクラッシュするのでオプション導入はやめましょう」となりました。正規表現APIに文字列を渡す前に「文字エンコーディングのバリデーション」を行ってから文字列データを渡せば済むことです。Rubyは文字エンコーディング妥当性検証済みのデータを正規表現APIに渡すようになっています。PHPもそうすべきですが、PCRE(preg_*関数)の文字エンコーディングバリデーション機能に頼る、Oniguruma(mb_regex_*関数)にパッチを当てて不正エンコーディングを無視する、といった実装になっています。preg/mb_regexのどちらも不正文字エンコーディングでは”正しく動作できない”ので、そもそも文字エンコーディングをバリデーションしておくべきです。複雑な処理系これらにより正規表現の利用が危険になっています。複雑な問題があるなら、問題を個別に分解して対応するのがエンジニアでしょう。(と書いてセキュアコーディングを誤解する理由に思い当たりました。代表例が文字列の先端/終端を指定の間違いです。これの対策は結構簡単です。Scalaの正規表現は明示的に指定しない限り正規表現でマッチする文字列は文字列全体になります。”\d”とするだけで”\A\d\z”と同じ意味になります。間違えようがありません。仕様として危険﻿バックリファレンス/再帰の回数を制限するのは勿論ですが、それだけでは足りません。簡易な正規表現/リスクを考えた正規表現を使うことも必要ですが、リスクを回避/緩和するには入力データにおかしたデータ(=攻撃用データ)が含まれないことを保証する対策が有効です。これには正規表現APIを利用する”前”に厳格な入力バリデーションを行います。正規表現の処理は複雑です。”正規表現データ”を処理する為には、まず”正規表現”を処理できるように”正規表現”自体をコンパイル(パースして効率的に処理できる形に変換)してから利用します。このコンパイル処理にも結構なCPUリソースを利用するのでPCREなどの正規表現ライブラリはコンパイル結果をキャッシュして再利用するようになっています。いった最適化は正規表現ライブラリ任せ、で構わないでしょう。しようもない問題もあります。PCREはUnicode文字列をマッチさせる場合のバリデーションを省略し出鱈目なデータ、バイナリデータなど、を与えるとクラッシュすることが判っています。比較的最近でもOnigurumaのメモリ管理が問題となった事例もあります。メモリ問題が無かったとしても、大きすぎるデータを与えられると正規表現の実行に多大なCPU時間が必要となる状況を回避することが困難になります。「仕様として危険」と同じく、正規表現APIを利用する”前”に厳格な入力バリデーションを行うと対策になります。文字エンコーディング処理は複雑です。正規表現APIの内部で問題となり得る文字エンコーディング処理のバリデーション処理を任せるとリスクが発生します。これを避ける為には、入力データとなる文字列の”文字種”および”文字エンコーディング”を予め限定/バリデーションするとリスクを回避/緩和できます。正規表現APIを最初のバリデーターとして使わない入力データを正規表現でバリデーションしているコードは多いと思います。置換処理を除けば、”多い”というより大半の正規表現処理はバリデーション処理でしょう。正規表現の入力データとして”自由に入力データを設定することを許可”すると思いもよらない問題が発生したり、間違えたりします。”自由に入力データを設定することを許可”すると思いもよらない問題が発生するなら、”自由に入力データを設定させない”様にすれば良いです。正規表現APIを最初のバリデーターとして利用するのではなく明示的に許可した場合に限り、改行文字(\n、\r)を許可する明示的に許可した長さの入力データのみ許可する。長過る(短過ぎる、も含む)入力データを許可しない明示的に許可し文字種のみ許可する明示的に許可した文字エンコーディングのみ許可するこのような対策を行えば良いことが分かります。これらの処理を正規表現APIを利用する前に適用するのは結構面倒です。簡単に処理できなければ正規表現だけで済ませたくなります。いった場合にはライブラリ化でしょう。PHPはこれらの要件を満すライブラリになっています。バリデーターとして足りない機能はUnicodeのスクリプト(文字種)指定ができない点です。Unicodeの制御文字などもデフォルトで許可しないようになっています。Unicode文字だけでなくASCII英数字も、明示的に指定しないと利用できません。紹介エレクトロニック・サービス・イニシアチブのWebシステムのコンサルタントのブログです。PHPの開発、PHP4.x/5.xレガシーPHPセキュリティパッチサービスなどを行っています。ブログのサブタイトルを「書かない日記」としているのは、ブログを始めた時にあまり書かないつもりで始めたのでこのサブタイトルになっています。yohgaki@ohgaki.net私が記述したブログ中のコードは記載が無い場合はMITライセンスです。その他のコードは参考リンクなどのライセンス情報を参照ください。