クイックサマリー：以前は、JavaScriptの正規表現は他の言語の正規表現に比べてパフォーマンスが劣っていたものの、近年改良が重ねられ、他の言語に見劣りしなくなっています。この記事では、Steven Levithan氏がJavaScriptの正規表現の歴史と現状を評価し、より読みやすく、保守性とレジリエンスに優れた正規表現の書き方をアドバイスします。 モダンJavaScriptの正規表現は、皆さんがよく知っている従来の正規表現と比べると随分進化しました。正規表現はテキストを検索して置き換えるツールとして非常に優れている一方で、書くのも理解するのも難しいという根強い評判があります（しかし今から説明するように、この認識は時代遅れかもしれません）。 正規表現に関するこの認識は、JavaScriptに特に当てはまります。PCREやPerl、.NET、Java、Ruby、C++、Pythonといっ
多機能なウェブサーバーとして2004年に登場したNginxは、2023年6月時点では業界トップシェアとなるほど人気を集めるサーバーです。そんなNginxの設定において、スラッシュを一つ付けるか付けないかの差で大きなセキュリティホールができてしまう問題について、大手パスワードマネージャーやGoogle製のツールの例をとりあげてセキュリティアナリストのダニエル・マツモトさんがブログで解説しています。 Hunting for Nginx Alias Traversals in the wild https://labs.hakaioffsec.com/nginx-alias-traversal/ Nginxの設定には、特定のURLへのアクセスをどう処理するべきかを記述できる「location」というディレクティブが存在しており、URLをサーバー内のファイルに対応させるのによく利用されています。例
PHP 8.1へのアップグレードにまつわるまとめ PHP 8.1へのアップグレードには、mbstringにまつわるマニュアルに記述されない後方互換性のない変更が含まれることがあります。そのことを周知するべく、この記事を書くことにしました。 私てきめんは、PHPカンファレンス 2022にて、「治っていくmbstring 令和時代の文字化け」というタイトルでトークしています。以下スライドも参考にしてください。 Major overhaul of mbstringについて PHP 8.1から、Major overhaul of mbstringと呼ばれる、mbstringの大規模改修の内容が反映されるようになりました。困ったことに、RFC(Request For Comments)やChangelog、マニュアルにない内容で、mbstringを多用するPHPユーザーにとてつもない困惑をもたらすこ
こんにちは、kintone 開発チームの @hikoma です。kintone のテストを JUnit 4 から JUnit 5 に移行した話を公開したいと思います。 背景 2017 年に JUnit 5 がリリースされてから約 4 年半、みなさんは既に JUnit 5 を利用していることかと思います。 kintone では JUnit 5 への移行がなかなか進みませんでした。テストのボリュームがそれなりにあり（Java の単体テストが約 6500、REST API のテストが約 4000、Selenium のテストが約 3000）、E2E テストで並列実行やリトライのために JUnit 4 の仕組みを利用していたので、目に見える問題が起きていない状況では優先度も上がりませんでした。 しかし、このような状況ではテストの改善に着手しにくく、持続的な開発のリスクも感じていたため、何度目かの移行
先日、このようなツイートを書いたところ、かなりの反響がありました。 JavaScript の正規表現の脆弱性の例でいうと、例えば /\s+$/ は脆弱性があると言える console.time(); /\s+$/.test(" ".repeat(65536) + "a"); console.timeEnd(); 結構時間がかかるのがわかる。でも /\s+$/ を見て「これは危険だな」と理解出来る人はそんなにいない。JavaScript に限らないけれど。 — Takuo Kihira (@tkihira) February 17, 2022 これは一般に ReDoS (Regular expression Denial of Service) と呼ばれる脆弱性です。正確に理解するのが難しい脆弱性なので、少し解説してみたいと思います。 結論 長い記事になるので、最初に「とりあえずこれだけ知っ
はじめに 2021年12月に発見されたLog4jのCVE-2021-44228は、稀に見るレベル、まさに超弩級の脆弱性となっています。今回、私はTwitterを主な足がかりとして情報収集を行いましたが、(英語・日本語どちらにおいても)かなりWAFそのものが話題になっていることに驚きました。ある人は「WAFが早速対応してくれたから安心だ！」と叫び、別の人は「WAFを回避できる難読化の方法が見つかった。WAFは役に立たない！」と主張する。さらにはGitHubに「WAFを回避できるペイロード(攻撃文字列)一覧」がアップロードされ、それについて「Scutumではこのパターンも止まりますか？」と問い合わせが来るなど、かなりWAFでの防御とその回避方法について注目が集まりました。 実はWAFにおいては、「回避(EvasionあるいはBypass)」との戦いは永遠のテーマです。これは今回Log4jの件で
H(uman-friendly) な grep コマンド hgrep をつくりました． github.com '\w+ で検索した時の出力 ファイルを特定のパターンで検索し，マッチした箇所を構文ハイライトしたコード片で表示します．超ざっくり言うと，ripgrep で検索して bat でマッチ箇所付近を表示するような感じです． grep -C によるコンテキスト表示に似ていますが，マッチ行が近い時は1つのコード片にまとめる，周囲何行を表示するかをヒューリスティックに少し賢く決めているなど，ちょっと出力は工夫しています． 動機 手元のリポジトリでコードを検索する時は 単純に grep で検索してマッチ結果を眺める grep | fzf のように検索結果を fzf で絞り込んだりプレビューする vim $(grep -l ...) のように検索結果をエディタで開く あたりを使い分けているのですが
「自分のサイトの正規表現一覧表がパクられた」──DeNAが運営するWebサイト内で、自分が作成した表が無断転載されているというツイートが物議を醸している。投稿者で、個人でWebサイトを運営するむらしゅん（@murashun）さんは10月30日、DeNAのRPAサービス「Coopel」で、自身のブログで掲載した図表と全く同じものが掲載されているのを見つけたという。 ツイートされた画像には、むらしゅんさんが作成したという正規表現一覧表と、同じ文言や順番で説明していることや、具体例については一部をCoopelに置き換えて表現していることが確認できる。むらしゅんさんの運営するWebサイトには、同サイト内の著作権について説明するページに設けており、転載許可については別途問い合わせをするよう提示していた。
みなさん、ワンライナーで日本語を簡単に処理したい場合、何を使うでしょうか。 ワンライナーで言語処理といえばPerlですよね[要出展]。 Perlでは、「ひらがな」「カタカナ」「漢字」といった文字にマッチする正規表現を簡単に書くことができます。 例えば、青春→鯖鰆みたいなやつという記事では、漢字にマッチさせるのに\p{Han}という正規表現を使っていました。 $ perl -Mutf8 -CSD -le 'print "漢" =~ m{\p{Han}} ? 1 : 0' 1 $ perl -Mutf8 -CSD -le 'print 1 if "あ" =~ m{\p{Han}} ? 1 : 0' 0 なんてこった。 "「"は明らかに漢字じゃないだろう？ 調べてみると、perlunicodeに以下のような記述がありました。 Prior to Perl v5.26, the single for
English version is available here: https://blog.ryotak.net/post/homebrew-security-incident-en/ (公式インシデント報告はこちらから読むことができます: https://brew.sh/2021/04/21/security-incident-disclosure/) はじめにHomebrewプロジェクトはHackerOne上で脆弱性開示制度(Vulnerability Disclosure Program)を設けており、脆弱性の診断行為が許可されています。 本記事は、当該制度に参加し、Homebrewプロジェクトのスタッフから許可を得た上で実施した脆弱性診断行為について解説したものであり、無許可の脆弱性診断行為を推奨することを意図したものではありません。 Homebrewに脆弱性を発見した場合は、
はじめにMicrosoftは脆弱性の診断行為をセーフハーバーにより許可しています。 本記事は、そのセーフハーバーを遵守した上で発見/報告した脆弱性を解説したものであり、無許可の脆弱性診断行為を推奨する事を意図したものではありません。 Microsoftが運営/提供するサービスに脆弱性を発見した場合は、Microsoft Bug Bounty Programへ報告してください。 要約VSCodeのIssue管理機能に脆弱性が存在し、不適切な正規表現、認証の欠如、コマンドインジェクションを組み合わせることによりVSCodeのGitHubリポジトリに対する不正な書き込みが可能だった。 発見のきっかけ電車に乗っている際にふと思い立ってmicrosoft/vscodeを眺めていた所、CI用のスクリプトが別のリポジトリ(microsoft/vscode-github-triage-actions)にま
Mozilla、今後はV8の正規表現エンジンをFirefoxにそのまま取り込むと表明。そのための互換レイヤを開発 WebブラウザにはJavaScriptを実行するためのJavaScriptエンジンが搭載されています。それはChromeであれば「V8」、Firefoxであれば「SpiderMonkey」と呼ばれ、それぞれのWebブラウザベンダがECMAScriptの標準に準拠したうえで独自に実装しています。 そしてJavaScriptは以前から正規表現の機能を備えているため、正規表現を解釈し展開するための正規表現エンジンもそれぞれのWebブラウザベンダが実装を行っていました。 その正規表現エンジンについてMozillaは今後、V8の正規表現エンジンのコードをそのままFirefoxのSpiderMonkeyに取り込むようにすると表明しました。 Mozillaはこれを実現するため、V8用の正規表
English version is here: https://mksben.l0.cm/2020/05/jquery3.5.0-xss.html 先月、jQuery 3.5.0がリリースされました。 このバージョンでは、僕が報告した問題がSecurity Fixとして含まれています。 jQuery 3.5.0 Released! | Official jQuery Blog https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/ 報告したバグは、CVE-2020-11022、 CVE-2020-11023 として採番されています。 https://github.com/advisories/GHSA-gxr4-xjj5-5px2 https://github.com/advisories/GHSA-jpcq-cgw6-v4j6
正規表現はVimに限らずコンピューター上でのテキスト操作において非常に強力です。 しかし学習の難しさも非情で多くのIT技術者、Vimmerが正規表現に苦しんでいるのを幾度となく目の当たりにしています。 ただ正規表現は本当にそんなに難しいのでしょうか。 いいえそんなことはありません。 正規表現は本来とても簡単な原理で学習も容易なのです。 にも関わらず難しいと思われてしまうのは、原理を理解しないまま外見上の機能をそのまま覚えようとするからです。 本記事では正規表現の原理にフォーカスし解説することで、Vimを含む様々な正規表現実装の利用難度を適切にしようという記事です。 本記事は Vim Advent Calendar 2019 の1日目の記事です。 「正規表現」はもともと形式言語という言語学の一分野の研究から生まれました。 言語学というのは言葉を科学的に研究する学問です。 形式言語はその中でも
Intro textarea などに入力された文字数を、JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID の
ECMAScript 2018で正規表現の戻り読み(lookbehind)が追加されました。 /(?<=foo)bar/.test('foobar'); // => true 'foobar'.replace(/(?<=foo)bar/, 'baz'); // => 'foobaz 正規表現の戻り読みと言えばPerlでは1998年7月リリースのバージョン5.005からサポートしており、そこから20年もたってと思いたくなるかもしれません。しかし、ECMAScript (JavaScript)のそれはPerlのものとは一味違います。なんと戻り読みの中で量指定子(*、+、?、{n}など)を使えるのです。 // JavaScriptなら(?<=...)の中で+が使える。 /(?<=fo+)bar/.test('foobar'); // => true # Perlでは(?<=...)の中で+を使お
150万以上ある Mongo のレコードに LIKE 検索したい時こうすると雲泥の差になった (1分以上かかってたのが 50ms 以下になった)。 ①インデックスを使う ($hint 指定しないと $regex の場合は使われないっぽい) ②パターンの頭に ^ を付ける ③パターンに .* を使わない ④パターンに () を使わない— tyru (@_tyru_) 2018年3月22日 控えめに150万件以上と言ったけど実際は190万件ぐらいだった。 以下の全てのクエリは 0 件を返す。 というか今見たら $and 使う必要はなかった。 // 89790ms db.getCollection('colName').find({$and: [{name: /(あああ)/}, {status: 1}]}) // 1361ms db.getCollection('colName').find({
お久しぶりです＆あけましておめでとうございます。昨年はブログを書く時間をうまく作ることができず、あまり記事を書けませんでした。今年はできるだけ月に1回程度何か書いていきたいと思っています。今年もよろしくお願いします！ さて、ブログを書かなかった間にXSSからSQLインジェクションへ興味が移った、なんてことはありませんでしたので、今日もいつも通り大好きなXSSの話をしたいと思います！ 最近、正規表現にユーザ入力を使っていることに起因するDOM based XSSに連続して遭遇しました。あまり見慣れていない注意が必要な問題だと思うので、この記事では、見つけたもの2つがどのように生じたか、また、問題を起こさないためにどうすればよいかを紹介します。 そのうちの1つはLINEのBug Bounty Programを通じて報告した問題です。 賞金と、"LINE SECURITY BUG BOUNTY"
FOLIOアドベントカレンダー 21日目です。 12月は読み応えのある記事が多いので、わたしからはさくっとしたTipsを。 いま作業してるリポジトリのファイル群から、目当ての文字列を1秒でも早く見つけるための話。 おすすめのコマンド grep だと対象指定が面倒だったり、カレントディレクトリ以下を指定すると巨大なnode_modules以下のファイルも対象になってしまったりするので、git管理下のファイルのみを対象に検索できて高速な git grep がおすすめ。 git grep 検索したい文字列 だけで検索できる。 ~/.bashrc や ~/.zshrcなどに以下のエイリアスを書いておくと、 gg hoge だけでgit管理下のファイルにあるhogeをハイライトつきでリストアップしてくれてめちゃ手軽。 alias gg='git grep' もちろん日本語も gg ほげほげ でいける
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
