不必要な制御文字への対処 - pixiv inside
こんにちは、晴れて2020新卒になったmipsparcです。最近は趣味の鉄道技術系同人誌の新版が出来上がって喜んでいます。 本記事では、入力値には必ずと言っていいほど混入する不必要な制御文字への対処方法をご紹介します。ユーザーに文字列を入力してもらうことのあるすべてのサービスで活用できる話かと思います。 不要な制御文字が入ることで生じる問題 前提として、この記事は制御文字類が必ずしも邪魔と言いたいわけではありません。 制御文字は多言語対応(特に右から左方向に記述する言語)などで重要なときもありますが、今回は問題が発生しうるケースのお話をします。 「腐向け」 「メリークリスマス」 「ゾンビ」 なんの変哲もない3つのイラストタグですが、どれも不可視の制御文字が混入しています。 $ php -r "var_dump(json_encode('腐向け'));" string(26) ""\u2
Blog｜その正規表現の書き方で大丈夫？ ReDoS 攻撃の怖さと対策方法
ReDoS とは、Regular expression Denial of Service の略称で脆弱な正規表現を利用することで起こる DoS のひとつです。 正規表現は利用者からの入力値の検証など色々な場面で利用されていますが、正規表現の記述は難しく、誤った記述をしてしまうと ReDoS の影響を受ける恐れがあります。 本記事では ReDoS の概要から対策方法まで解説していきます。 ReDoS とは メールアドレスや電話番号の入力が正しい形式になっているかどうかを確認するために正規表現を使うことがあると思います。 複雑な形式をマッチさせる正規表現を正しく書くことは難しく、書き方によっては処理に時間がかかることがあります。 ReDoS は、正規表現が使われている部分において、正規表現エンジンに対して処理時間が多くかかる入力を与えることでサービス停止が起こる脆弱性です。 Freezing
Email Address Regular Expression That 99.99% Works.
Just copy and paste the email regex below for the language of your choice. Feeling hardcore (or crazy, you decide)? Read the official RFC 5322, or you can check out this Email Validation Summary. Note there is no perfect email regex, hence the 99.99%. General Email Regex (RFC 5322 Official Standard) (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\
PHPでは正規表現コンパイル結果のキャッシュが暗黙に行われている - hnwの日記
筆者がPHPをさわり始めたころ、「PerlのコレはPHPではどうやるんだろう？」と思うことが頻繁にありました。一部の疑問については解説を見つけたり自分でソースコードを読んだりして解決したものの、考えるのをやめてしまったものもあります。その一つが正規表現コンパイル結果の保存に関するもので、最近まで完全に忘れていました。 正規表現のコンパイルというのは与えられた正規表現を解釈して実行しやすいデータ構造に変換する作業のことを指します。具体的にはDFA（決定性有限オートマトン）を構成するか、正規表現エンジン内部で用いられるVM命令列に変換するかといった処理になります。これらは複雑な処理ですので、性能の観点で言えば同じ正規表現に対するコンパイル処理はできるだけ繰り返したくありません。 Perlの場合、/foobar/ のようなスタティックな正規表現のコンパイルは1回しか行われません。一方で、正規表現
正規表現でのメールアドレスチェックは見直すべき – ReDoS
(Last Updated On: 2018年8月13日)前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS（十分短い文字列で指数関数的に実行時間が増加する）が可能なことが判りました。 結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。（特にRubyユーザー） 追記：影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイト
mbstring正規表現デフォルト文字エンコーディングは”EUC-JP”だった
(Last Updated On: 2018年8月13日)デフォルト文字エンコーディング設定の仕様変更は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などのデフォルト文字エンコーディングが変わっている事に気が付かない方も多い（気が付かない方が多い？）と思います。 PHP 5.6のデフォルト文字エンコーディング設定 PHP 5.5以
正規表現インジェクション
(Last Updated On: 2018年8月13日)一文字でも意味がある文字があるとインジェクション攻撃が可能な場合が多いです。正規表現も例外ではありません。 正規表現インジェクションとは 正規表現に対する攻撃にはReDoS攻撃（検索対象の文字列を使って攻撃）がありますが、正規表現自体を使ってインジェクション攻撃が可能です。ヌル文字インジェクションと組み合わせて攻撃も可能です。 正規表現インジェクションで攻撃可能なパターンは正規表現の一部が変更可能で、検索可能な文字列を制限している場合です。 正規表現インジェクションのパターン 以下のようなログファイルがあるとします。 14:14:15 bob[14] Login from IP 10.10.10.123 14:14:30 tom[14] Login from IP 10.10.20.234 14:15:27 bob[34] Upda
正規表現を使ったDoS – ReDoS
(Last Updated On: 2018年8月8日)いつかは忘れるくらい前に正規表現のアルゴリズム自体を利用してDoS攻撃を行うReDoSが発表されていました。今まであまり気にしていなかったのですが、検索しても日本語のページが出てこないようでした。詳しく知るためのリンクなどを紹介します。 少し検索して出て来た日本語ページはHPのページでしたが、たまたまインデックスされていたページがヒットしたようでした。また記載されている情報は不十分でした。（ページ下のコピーライトからFortifyの情報のようです） 日本語のページで良いものは無いようなので、ReDoSの英語ページ／PDFを紹介します。 Wikipedia OWASP CHECKMARX 2015 (PDF) CHECKMARX 2009 (PDF) 3つ目のCHECKMARXのPDFは解りやすいと思います。OWASPのページはCHE
PHPの正規表現こう書くといいよ
if(preg_match('/^(?!(?:(?:\x22?\x5C[\x00-\x7E]\x22?)|(?:\x22?[^\x5C\x22]\x22?)){255,})(?!(?:(?: \x22?\x5C[\x00-\x7E]\x22?)|(?:\x22?[^\x5C\x22]\x22?)){65,}@)(?:(?:[\x21\x23-\x27\x2A\x2B\x2D\x2 F-\x39\x3D\x3F\x5E-\x7E]+)|(?:\x22(?:[\x01-\x08\x0B\x0C\x0E-\x1F\x21\x23-\x5B\x5D-\x7F]|(?:\x5C [\x00-\x7F]))*\x22))(?:\.(?:(?:[\x21\x23-\x27\x2A\x2B\x2D\x2F-\x39\x3D\x3F\x5E-\x7E]+)|(?:\x22( ?:[\x01-\x08\x0B
JVNVU#92987253: Henry Spencer の正規表現 (regex) ライブラリにバッファオーバーフローの脆弱性
JVNVU#92987253 Henry Spencer の正規表現 (regex) ライブラリにバッファオーバーフローの脆弱性 Henry Spencer が作成した正規表現 (regex) ライブラリは、ヒープベースのバッファオーバーフローの影響を受ける可能性があります。
u (PCRE_UTF8) オプションをつけないと \h、\s、\v で想定しない文字を破壊するおそれがある - Qiita
u (PCRE_UTF8) オプションをつけないと \h、\s、\v で想定しない文字を破壊するおそれがあるPHPUnicode PCRE 関数のエスケープシーケンスのうち、\h (水平方向の空白文字)、\s (空白文字)、\v (垂直方向の空白文字) を使う場合、UTF-8 のオプション (u)をつけないと、preg_replace などで不要な文字を削除する際に想定しない文字を破壊するおそれがあります。 次のコードはひらがなの「だ」(U+3060) が破壊される様子を示したものです。「だ」の3番目のバイト (0xA0) がノーブレークスペース (U+00A0) と誤検出されてしまいます。 <?php $str = "だ"; var_dump( "\xE3\x81\xA0" === $str, "\xE3\x81" === preg_replace("/\h/", "", $str),
正規表現を解析して可視化してくれるサイトが凄すぎる件
ある正規表現に対して、特定の文字列がマッチするかどうかをチェックするツールやサイトは沢山ありますが、正規表現そのものが何を意味しているのか、どんな文字列を期待しているのかを解析・解読・説明してくれるツールやサイトってなかなか見ない気がします。 他人の書いた正規表現を見て、「ん？」ってなったことはありませんか？ 例えばこれ。 1 ^[a-zA-Z0-9-_.]@([a-zA-Z0-9_-]+\.)+[a-zA-Z]{2,4}$ これくらいなら分かりますが、複雑になってくるとつらい… いつかはマスターしたいけど…今は楽したい。 そう思ってググってみると…ありました！ それがこちら。 Regexper http://www.regexper.com/ 正規表現を入力して Display をクリックすると、その正規表現が表す内容を図にして表示してくれます。 例えば先程の正規表現は、当記事の一番上の
なぜRubyと違い、PHPの正規表現で^$の利用は致命的な問題ではないのか？
(Last Updated On: 2018年8月13日)Rubyデフォルトの正規表現では^は行の先頭、$は改行を含む行末にマッチします。PHPのPCREとmbregexでは^はデータの先頭、$は改行を含む行末にマッチします。 この仕様の違いはデータのバリデーションに大きく影響します。 参考： PHPer向け、Ruby/Railsの落とし穴 の続きの解説になります。こちらのエントリもどうぞ。 なぜ^と$が行の先頭と行の末尾にマッチするのか？ そもそも正規表現はテキスト検索を行うステートマシーンとして設計されました。通常テキストには改行があります。特定の行に一致するかどうかテストするように設計するのが自然です。この為、正規表現の^と$は行の先頭と末尾にマッチするように設計されたと考えられます。 正規表現をバリデーションに利用することは可能です。しかし、そもそもは正規表現に一致する「テキスト」
正規表現リテラルのes3からes5の間での変化 - ぶれすとつーる
何度目かの聖書(JavaScript: The Good Parts)の輪読会をしてたときに、RegExpの章を担当してくれた子が、「正規表現リテラルから生成される正規表現オブジェクトは内容が同じなら参照も同じになります！」って説明してくれて、「あれ、そうだっけ」って思って調べた。 たしかに書いてる RegExp objects made by regular expression literals share a single instance: function make_a_matcher() { return /a/gi; } var x = make_a_matcher(); var y = make_a_matcher(); // Beware: x and y are the same object! x.lastIndex = 10; document.writeln(y.
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - attackercan/regexp-security-cheatsheet
GitHub - sizuhiko/hexpress: hexpress is a PHP library that human way to define regular expressions
GitHub - VerbalExpressions/PHPVerbalExpressions: PHP Regular expressions made easy
GitHub - selvinortiz/flux: Fluent regular expressions in PHP
GitHub - gherkins/regexpbuilderphp: 🦉 human-readable regular expressions
