ペンリジェント・ヘッダー

セキュリティ・エンジニアのためのJavaScriptフィルタ:決定論的なパイプライン、より少ない誤検知、そして「フィルター=サニタイザー」の神話をゼロにする

セキュリティ・エンジニアのための filter()決定論的なパイプライン、より少ない誤検出、そして "フィルタがサニタイザーである "という神話をなくす。

もし検索したなら "javascriptフィルター"このどちらかの結果を望んでいる可能性が高い:

  • ノイジーなスキャン出力をクリーンに変える、 行動可能 ショートリスト
  • スパゲッティループを記述することなく、オブジェクト(アセット、所見、IOC、ルール)の配列をフィルタリングします。
  • CI、ブラウザのサンドボックス、あるいはセキュリティ・パイプラインの内部で実行できるように、フィルタリングを高速化する。
  • 文字列のフィルタリング」≠「信頼できない入力を安全にする」という古典的な罠を避ける。

最後の1つは、多くのセキュリティ・ツールが静かに失敗しているところだ。

ロングテールのクエリには理由がある。 "javascriptによるオブジェクトのフィルター配列" スタックオーバーフローの正規スレッドのタイトルは、次のとおりである。 "閲覧回数228k回"これは、実務家が実際に何をクリックし、コピーし、展開するかの強いシグナルである。(スタック・オーバーフロー)

Array.prototype.filter() 保証するもの(そして絶対に保証しないもの)

言語レベルでは、 フィルター():

  • を返します。 新しい配列 述語が真理を返す要素を含む。
  • を生産する。 シャローコピー (オブジェクトの参照は共有され、クローン化されない)。(MDN ウェブドックス)
  • スキップ 空きスロット 疎配列の場合(述語は "穴 "には呼ばれない)。(TC39)

MDNは "浅いコピー "と "スパース配列の空のスロットでは呼び出されない "の両方を明示している。(MDN ウェブドックス)

ECMAScriptの仕様では、コールバックは要素の欠落に対して呼び出されないことも明示されている。(TC39)

セキュリティ・パイプラインでスパース配列が重要な理由

疎な配列は予想以上に現れる:JSON変換、"インデックスの削除 "のバグ、複数ソースのマージによる部分的な結果、素朴なデデュープなどだ。

const results = [ {id: 1}, , {id: 3} ]; // 穴に注意
const kept = results.filter(() => true);

console.log(kept); // [{id: 1}, {id: 3}] (穴が消える)

パイプラインが「同じ長さの入力、同じ長さの出力」を想定している場合、疎な配列はそれを壊してしまう。トリアージパイプラインでは、次のようになります。 サイレント データ損失。

高CTRパターン:オブジェクトの配列をフィルタリングする

実際の "javascriptフィルター "の使い方のほとんどは、オブジェクトの配列(アセット/ファインディング/IOC)をフィルターすることです。

例:証拠が添付された悪用可能なウェブ調査結果のみを残す

const findings = [
  { id: "XSS-001", type:タイプ: "xss", 重大度: "high「high", verified: true, evidence:["req.txt", "resp.html"] }、
  { id: "INFO-009", type: "banner", severity: "バナー":バナー", 重大度: "info", 検証済み: false:「info", verified: false, evidence:[] },
  ssrf"、重大度:"critical"、検証:true:「critical"、verified: true、evidence: []:["dnslog.png"] }、
];

const actionable = findings.filter(f => 以下のようになります。
  f.verified && (f.severity === "high" || f.verified &&)
  (f.severity === "high" || f.severity === "critical") && f.evidence?
  f.evidence?.length > 0
);

console.log(actionable.map(f => f.id)); // ["XSS-001", "SSRF-004"].

例:スコープコントロール(プログラムを台無しにする最も簡単な場所)

const inScopeHosts = new Set(["api.example.com", "admin.example.com"]);

const assets = [
  { host: "api.example.com", ip:"203.0.113.10"、alive: true }、
  { host: "cdn.example.com", ip:"203.0.113.11", alive: true }、
  { host: "admin.example.com", ip:"203.0.113.12", alive: false }、
];

const targets = assets
  .filter(a => a.alive)
  .filter(a => inScopeHosts.has(a.host));

console.log(targets);
// 【{host: "api.example.com", ...}】。

を使用している。 セット 偶発的な事故を避ける O(n²) パターン(インクルード() 内部 フィルター() 大規模な配列にまたがって)。これは、何万ものアセットをフィルタリングする場合に重要です。

パフォーマンスの現実:パックド・アレイとホーリー・アレイ、そしてなぜ少ししか気にしなくていいのか?

V8は次のように区別されている。 満員 そして ぽこぽこ 一般に、パックされた配列に対する操作は、穴のあいた配列に対する操作よりも効率的である。(V8)

セキュリティへの影響:穴を作るパイプライン (arr[i]を削除するスパース・マージ)はパフォーマンスを低下させる可能性がある。 そして 正しさである。現実的なルールは単純だ:

  • 穴を作らない。好む スプライス, フィルターまたはアレイを再構築する。
  • 大規模なデータセットを処理する場合は、ホットアレイで型を混在させないようにする。

セキュリティ・エンジニアの決定表: フィルターいくつか見つける減らす

セキュリティ・パイプラインのゴール最高のツールなぜよくある間違い
全試合をキープ(ショートリスト)フィルター()サブセット配列を返す述語中のソースの変異
初戦でストップ(ポリシーゲート)some()早期終了のブール値filter().length > 0
最初のマッチを取得する(ルート選択)find()早期撤退+エレメントfilter()[0]
メトリクスの構築(カウント、スコア)reduce()ワンパスアグリゲーションレデューサーで高価なI/Oを行う

これはスタイルというより、パイプラインを決定論的で、あらゆる場所(CI、ブラウザー・サンドボックス、エージェント・ランナー)で実行できるほど安価にすることだ。

危険な過負荷:「フィルタリング」は「サニタイズ」ではない

さて、セキュリティ・エンジニアが冷酷になるべき部分だ: 文字列フィルタリングはセキュリティの境界ではない.

OWASPのXSS防止ガイダンスは、次の点を強調している。 出力エンコーディング (入力フィルタリングに頼るのではなく、(そして適切な文脈に適切な守備を用いる)。(OWASPチートシートシリーズ)

OWASPのXSSフィルタ回避のコンテンツは、入力フィルタリングを不完全な防御として明確に位置づけ、回避方法をカタログ化している。(OWASPチートシートシリーズ)

PortSwiggerのXSSチートシート(2025年10月更新)も同様に、WAFやフィルタをバイパスするのに役立つベクターが含まれていることを明示している。(ポートスウィガー)

現実的な例:解析の違いで崩れるURL「フィルター

悪いパターンだ:

関数 allowUrl(u) {
  return !u.includes("javascript:") && !u.includes("data:");
}

より良いパターン:パース+許可リスト+正規化:

function allowUrl(u, allowedHosts) { 以下のようになります。
  const url = new URL(u, ""); // 相対入力用の安全なベース
  if (!["https:"].includes(url.protocol)) return false;
  return allowedHosts.has(url.hostname);
}

const allowedHosts = new Set(["docs.example.com", "cdn.example.com"]);

これがメンタル・シフトだ: 文字列のマッチングを停止する構造化データの検証を開始する。

フィルタ/サニタイザ」が本番で失敗することを証明するCVEと、それをチェックに組み込むべき理由

あなたの組織が「HTMLをサニタイズしています」と言うとき、あなたの脅威モデルは即座にそれを含むべきである: どのサニタイザー、どのバージョン、どのコンフィグ、どのバイパス履歴ですか?

CVE-2025-66412 (Angular テンプレートコンパイラ保存型 XSS)

NVDは、不完全な内部セキュリティスキーマが原因で、Angularのテンプレートコンパイラに保存されたXSSについて説明しています。(NVD)

セキュリティー上の収穫: 「フレームワークのサニタイゼーション」は、永続的な保証ではない。バージョン管理、勧告、回帰テストなど、他のセキュリティ管理と同じように扱ってください。

JavaScriptフィルタ Penligent

CVE-2025-26791 (不正な正規表現による DOMPurify mXSS)

NVD によると、3.2.4 より前の DOMPurify には、場合によっては変異 XSS を引き起こす可能性のある、不正なテンプレートリテラル正規表現があるとのことです。(NVD)

セキュリティー上の収穫: サニタイザーのオプションは重要だ。コンフィグの組み合わせは、"尊敬されるライブラリを使っている "場合でも、悪用される状況を作り出す可能性がある。

CVE-2024-45801 (DOMPurify 深度チェックバイパス + プロトタイプ汚染弱体化)

NVDは特殊なネスティング技術が深さチェックを回避する可能性があると報告している。(NVD)

セキュリティー上の収穫: ヒューリスティック(深さ制限、ネスティングチェック)に依存する防御は、しばしばバイパスの標的になる。

CVE-2025-59364 (express-xss-sanitizer の再帰 DoS)

NVD が、ネストした JSON リクエストボディのサニタイズ時に、再帰の深さに制限がないことを指摘した。(NVD)

セキュリティー上の収穫: 「サニタイズ」コードは可用性バグを引き起こす可能性がある。サービスを確実にクラッシュさせることができるのであれば、攻撃者にXSSは必要ありません。

Pentest自動化のための実践的な「javascriptフィルター」パターン

1) 信頼度ゲート:信頼度の高い候補だけを高価な検証のために残す

const候補 = [
  { id: "C1", signal: 0.92, cost: 3.0 }、
  { id: "C2", signal: 0.55, cost: 1.2 }, { id: "C3", signal: 0.81, cost: 9.5 }、
  { id: "C3", signal: 0.81, cost: 9.5 }、
];

const budget = 10;
const shortlist = 候補
  .filter(c => c.signal >= 0.8) // 信頼しきい値
  .filter(c => c.cost  c.id)); // ["C1"].

2) 証拠の完全性:証拠なしにレポートを出荷させない

const reportItems = findings.filter(f =>)
  f.検証済み &&
  Array.isArray(f.evidence)及び&&。
  f.evidence.length >= 1
);

3) キルスイッチフィルタ:搾取ステップの前にポリシーを適用する。

用途 some() マッチしたら拒否」:

const forbidden = [/i, /i.gov$/i, /i.mil$/i];
const isForbidden = host => forbidden.some(rx => rx.test(host));

ペンリジェントがフィットする場所

エビデンスファースト」のワークフローで、 フィルター() には最適だ。 決定論的オーケストレーション次に何を検証するか、どの道を探るか、そして最終報告に何を載せるかを決めること。難しいのは検証のループで、再現を行い、証明を集め、結果を一貫したものにする。

コードで候補をフィルタリングし、自動化されたシステムで検証を行い、エビデンスを取得し、環境間で実行の一貫性を保つのです。PenligentのAIペンテスト・プラットフォームとしての位置づけは、パイプラインの「検証+エビデンス+レポート」セグメントにおいて特に理にかなっている。

茫然自失: https://penligent.ai/

javascriptフィルター ペンリゲント

ジャバスクリプト・フィルター」をセキュリティ・グレードに保つための簡単なチェックリスト

  • トリート フィルター() として データシェーピング入力のサニタイズ」ではない。
  • 空のスロットではコールバックがスキップされることを覚えておこう。(TC39)
  • 用途 セット/地図 規模に応じたメンバーシップ・フィルタ
  • 好む some()/find() 早く帰りたいとき
  • XSS防御のためには、ブラックリスト・フィルターではなく、OWASPのコンテキスト・ベースのエンコーディング・ガイダンスに従うこと。(OWASPチートシートシリーズ)
  • サニタイザー/フレームワークのCVEを第一級のサプライチェーンリスクとして追跡する。(NVD)

参考文献と権威あるリンク(コピー&ペースト)

記事を共有する
関連記事