SecurityForgeを開発した理由
— そしてなぜ無料公開したのか
4,025以上の攻撃ペイロード、25のWAFフィンガープリント、AI連携ワークフローを備えたオープンソースの攻撃的セキュリティツールキット。WAFに費用をかけている全ての企業が、実際の攻撃パターンでテストすべき理由を解説します。
要約
私たちはSecurityForgeを開発しました。4,025以上の厳選された攻撃ペイロード、25のWAFベンダーの自動フィンガープリント、Claude CodeおよびChatGPTとのネイティブ統合を備えたオープンソースの攻撃的セキュリティツールキットです。無料で、依存関係はゼロ、10秒で実行できます。
オープンソースにした理由は単純です。攻撃者はすでにこれらのペイロードを持っています。持っていないのは防御側です。これは公平な競争環境を作ります。
$ pip install securityforge
$ securityforge detect https://example.com
WAF Detected: Cloudflare
Confidence: 100%
$ securityforge test https://example.com -c xss --max 10
Loaded 989 payloads
Testing 10 payloads against https://example.com
誰も語らない問題
Webアプリケーションセキュリティにおける不都合な真実があります。ほとんどの企業は、自社のWAFが本当に機能しているかどうか分かっていません。
年間50万円〜500万円をWAF(Web Application Firewall)に支払い — Cloudflare、AWS WAF、Akamai、Imperva — アプリケーションの前に設置して、守られていると思い込みます。商用ツールで簡単なスキャンを実行し、緑のチェックマークを確認して終了です。
しかし、本物の攻撃者が現れたらどうなるでしょうか?
セキュリティコンサルティングに長年携わってきましたが、パターンは常に同じです:
- 企業がWAFをデフォルトルールで導入
- 安全だと思い込む
- 攻撃者がGitHubの無料ペイロードを使って15分でWAFをバイパス
- 企業が侵害される
- 繰り返し
問題はWAFベンダーにあるわけではありません — 彼らは優れた製品を作っています。問題は、実際の攻撃ペイロードでWAF設定のストレステストを行う人がいないことです。デフォルトルールだけでは不十分です。カスタムルールにはカスタムテストが必要です。
既存のテストツールは、時代遅れ(2019年で更新停止)、断片的(50以上のリポジトリに分散)、高額(WAFより高い商用ツール)、あるいは使いにくい(ツールのない生のテキストファイル)のいずれかです。SecurityForgeはこの4つ全てを解決します。
中身の詳細:技術的な深堀り
SecurityForgeはインターネットからスクレイピングしたランダムなペイロード文字列の寄せ集めではありません。全てのペイロードは攻撃ベクトルで分類され、OWASPフレームワークにマッピングされ、該当する場合はCVEタグ付けされ、実際のWAFに対してテストされ、何をするか・なぜ重要かを説明するドキュメントが付属しています。
15カテゴリにわたる4,025以上のペイロード
深堀り:XSSに779ペイロードが必要な理由
XSSは最も一般的なWeb脆弱性(OWASP A03:2021)であり、WAFバイパス技術は常に進化しています。私たちのコレクションは<script>alert(1)</script>の779バリエーションではありません。以下を含みます:
- イベントハンドラの悪用 —
<img src=x onerror=alert(1)>と、全HTMLエレメントを対象とした200以上のバリエーション - エンコーディングバイパス — 二重URLエンコーディング、Unicode正規化、HTMLエンティティ、大文字小文字混在、16進エンコーディング
- DOMベースXSS — クライアントサイドフレームワーク(React、Angular、Vue)を対象としたペイロード
- Mutation XSS (mXSS) — ブラウザのHTMLパーサーの違いを利用するペイロード
- 2025〜2026年の最新技術 — テンプレートリテラル、CSSインジェクション、SVG悪用、WebSocketベースの配信
全てのペイロードは一つの質問に答えるために設計されています:あなたのWAFはこれをブロックしますか、それとも素通りしますか?
LLMセキュリティ:新しいフロンティア
最もワクワクしているカテゴリです。組織がLLMを本番環境に導入するにつれ、プロンプトインジェクションは新しいXSSになっています。300以上のAIセキュリティペイロードには以下が含まれます:
- 直接プロンプトインジェクション(DPI) — ユーザー入力によるシステムプロンプトの上書き
- 間接プロンプトインジェクション — LLMが処理するデータに命令を埋め込む(RAGポイズニング)
- ジェイルブレイク技術 — DAN、ロールプレイ、エンコーディングトリック、マルチターンエスカレーション
- データ抽出 — 学習データやシステムプロンプトの巧妙なクエリによる抽出
- ツール/関数呼び出しの悪用 — LLMのツール使用を操作して不正なアクションを実行
138の最新バイパス技術(2025〜2026年)
このセクションだけでもクローンする価値があります。過去18ヶ月で発見されたバイパス技術で、ほとんどのWAFルールセットがまだ対応できていないものです:
- Chunked Transfer Encodingの悪用
- HTTP/2ヘッダースマグリング
- Unicode正規化バイパス
- ポリグロットペイロード(複数のコンテキストで同時に有効)
- ブラウザ固有のパース癖
- Content-Type混同攻撃
WAF検出:25ベンダーのフィンガープリント
ペイロードをテストする前に、何に対峙しているか知る必要があります。SecurityForgeのWAFデテクターは、HTTPレスポンスヘッダー、Cookie、エラーページ、サーバーシグネチャ、レスポンスタイミングパターンを分析して25ベンダーを識別します。
$ securityforge detect https://example.com
WAF Detected: Cloudflare
Confidence: 100%
Signatures matched:
Header: cf-ray
Server: cloudflare
Response text: cloudflare
Response text: attention required
| # | WAFベンダー | 検出方法 | 主要シグネチャ |
|---|---|---|---|
| 1 | Cloudflare | ヘッダー、Cookie、エラーページ | cf-ray, __cfduid |
| 2 | Akamai | ヘッダー、Cookie、Bot Manager | akamai-grn, ak_bmsc |
| 3 | AWS WAF | ヘッダー、Cookie、レスポンス | x-amzn-waf-action, awsalb |
| 4 | Imperva | ヘッダー、Cookie、チャレンジ | x-iinfo, incap_ses |
| 5 | F5 BIG-IP | ヘッダー、Cookie、エラーページ | x-wa-info, bigipserver |
| 6 | Fastly | ヘッダー、Cookie、サーバー | x-sigsci-requestid |
| 7 | Azure WAF | ヘッダー、Cookie、Front Door | x-azure-fdid, arr_affinity |
| 8 | Google Cloud Armor | ヘッダー、サーバー、reCAPTCHA | x-cloud-trace-context |
| 9 | Barracuda | ヘッダー、Cookie、サーバー | x-barracuda-url |
| 10 | Citrix NetScaler | ヘッダー、Cookie、サーバー | citrix-transactionid, nsc_ |
| 11 | Radware | ヘッダー、レスポンス | x-protected-by, AppWall |
| 12 | Palo Alto | ヘッダー、レスポンス | x-pan-, x-prisma |
| 13 | Check Point | ヘッダー、レスポンス | x-checkpoint |
| 14 | ModSecurity | ヘッダー、サーバー、レスポンス | x-mod-security |
| 15 | Qualys WAF | ヘッダー、レスポンス | x-qualys |
| 16 | Penta Security | ヘッダー、Cookie | x-wapples |
| 17 | StackPath | ヘッダー、サーバー | x-stackpath-shield |
| 18 | Sophos | ヘッダー、レスポンス | x-sophos |
| 19 | Scutum | ヘッダー、レスポンス | x-scutum |
| 20 | Rohde & Schwarz | ヘッダー、レスポンス | x-rs- |
| 21 | Sucuri | ヘッダー、Cookie、サーバー | x-sucuri-id |
| 22 | Fortinet FortiWeb | ヘッダー、Cookie、サーバー | x-fortiweb, fortiwafsid |
| 23 | Wallarm | ヘッダー、サーバー | x-wallarm-waf-check |
| 24 | Reblaze | ヘッダー、Cookie、サーバー | x-reblaze-protection, rbzid |
| 25 | Vercel | ヘッダー、サーバー | x-vercel-id |
各検出には、一致したシグネチャの数に基づく信頼度スコア(0〜100%)が含まれます。高信頼度(70〜100%)は複数の指標が確認されたことを意味します。低信頼度はヒントは見つかったが確実ではないことを意味します。
OWASPカバレッジ100% — 4つのフレームワーク全て
ほとんどのツールはOWASP Top 10の一部しかカバーしていません。SecurityForgeは4つの主要OWASPフレームワーク全てを100%のカテゴリ網羅率でカバーしています:
セキュリティ評価でいずれかのOWASPカテゴリ — Web、モバイル、AI、API — のペイロードが必要な場合、SecurityForgeで全て対応できます。5つの異なるリポジトリからペイロードをかき集める必要はありません。
なぜAIネイティブが重要なのか
これがSecurityForgeをSecLists、PayloadsAllTheThings、その他全てのペイロードコレクションと差別化するポイントです。
SecurityForgeは初日からAIアシスタントと連携するよう設計されました。全てのペイロードは構造化されたJSONで分類、タグ付け、ドキュメント化されています — 生のテキストとして放り込まれているのではありません。これにより、AIアシスタントがデータを理解し、知的な判断を下すことができます。
Claude Code(IDE内で)
Claude Code:
✓ waf_detector.py実行 → Cloudflare検出(92%)
✓ Cloudflare固有のXSSバイパスペイロードを選択
✓ waf_tester.py実行 — 779ペイロードをテスト
✓ 12ペイロードがWAFルールをバイパス
✓ HTMLレポートを生成
✓ security_report.htmlに保存
ChatGPTで
認証バイパスにはどのペイロードを試すべきですか?"
ChatGPT:
✓ CVE-2026-28515(REST APIバイパス)を参照
✓ SecurityForgeから150以上の関連ペイロードを取得
✓ 各攻撃ベクトルを平易な日本語で説明
✓ テスト方法と順序を提案
✓ WAFルールの推奨事項を提供
重要な洞察:AIアシスタントは扱うデータの質に左右されます。構造化されドキュメント化されたペイロードデータベースがあれば、ChatGPTは汎用的なセキュリティチャットボットから本格的なペネトレーションテストのコパイロットに変わります。
なぜオープンソース?なぜ無料?
プロプライエタリにすることもできました。WAF検出とAI統合を備えた厳選されたペイロードデータベースには、真の商業的価値があります — セキュリティコンサルティング会社は喜んで支払うでしょう。しかし、4つの理由からオープンソースにしました:
攻撃者はすでにこれらのペイロードを持っています。非公開のTelegramチャンネル、ダークウェブフォーラム、クローズドなバグバウンティコミュニティで共有しています。アクセスできないのは防御側です。オープンソースにすることで公平な競争環境を作ります。
WAFベンダーは、顧客がバイパス技術を簡単にテストできることを知れば、ルールセットの改善に積極的になります。SecurityForgeは公開ベンチマークを作ります — あなたのWAFがこれらのペイロードをブロックできなければ、コミュニティがそれを知ることになります。
一人で全てのWAFベンダーの新しいバイパス技術を追跡することは不可能です。オープンソースであれば、バグバウンティハンターが新しいバイパスを提供し、研究者が公開されたペイロードを追加し、WAFベンダーは標準化されたセットに対してテストできます。
AIアシスタントはセキュリティ業務にますます使用されています。しかし、有用であるためには構造化され、分類され、十分にドキュメント化されたデータが必要です。SecurityForgeは人間が読めるだけでなく、AIが読めるように構築されています。
実際の使い方
シナリオ1:「WAFは本当に守ってくれているのか?」
$ pip install securityforge
$ securityforge detect https://yoursite.com
WAF Detected: AWS WAF (87% confidence)
# ステップ2: カテゴリ別テストを実行
$ securityforge test https://yoursite.com -c xss --max 20
$ securityforge test https://yoursite.com -c sqli --max 20
# ステップ3: 結果を確認
Results saved to securityforge_results.json
シナリオ2:「WAFを導入したばかり — 何から始める?」
OWASP Top 10のペイロードから始めてください。WAFがこれらをブロックできなければ、他は意味がありません:
- A03: インジェクション — 全てのXSSとSQLiペイロードを実行。ほとんどの侵害はここから始まります。
- A01: アクセス制御の不備 — パストラバーサルとSSRFペイロードをテスト。
- A10: SSRF — クラウド環境では特に重要。メタデータエンドポイントへのアクセスをテスト。
シナリオ3:「バグバウンティでWAFを発見した」
securityforge detectを実行してベンダーを特定- データベース内のベンダー固有のバイパスペイロードを確認
- 138の最新バイパス技術(2025〜2026年)を試す
- エンコーディングバリエーションとポリグロットを使用
シナリオ4:「LLMのプロンプトインジェクションをテスト」
Loaded 300+ payloads
Testing 20 payloads against https://your-llm-app.com
$ securityforge payloads
ai_prompt_injection 8 files
llm_testing 4 files
Categories: prompt injection, jailbreaks, indirect injection, data exfiltration
カスタムペイロード:真の実力
プリビルトのデータベースは出発点に過ぎません。SecurityForgeの真の力は、あなたの環境に特化したカスタムペイロードを構築することにあります。
全ての組織のWAF設定は異なります。CloudflareがECサイトに適用するルールは、AWS WAFが金融APIに適用するルールとは異なります。汎用的なテストでは隙間を見逃します。カスタムテストがそれを見つけます。
$ python3 payload_creator.py
何をテストしますか?
> CloudflareのReactフロントエンド向けXSSバイパス
15のカスタムペイロードを生成:
1. React dangerouslySetInnerHTML悪用
2. テンプレートリテラルによるJSXエクスプレッションインジェクション
3. Cloudflareエンコーディングバイパス(二重URL + Unicode)
4. Reactハイドレーションを対象としたDOMクロバリング
...
AIアシスタントを使えばさらに先に進めます:テック・スタックを平易な言葉で説明し、SecurityForgeのデータベースを基盤としてClaude CodeやChatGPTにターゲットを絞ったペイロードを生成させましょう。
2人のスタートアップからFortune 500の大企業まで、全ての企業が一つの質問に自信を持って答えられるようにしたい:「私たちのWAFは鉄壁なのか、それともセキュリティシアターなのか?」
今後の展望
SecurityForgeはまだ始まったばかりです。これから構築するもの:
- 自動更新パイプライン — 新しいCVEとバイパス技術を公開から48時間以内に追加
- 月次WAFベンチマークレポート — ペイロードデータベースに対するベンダーの有効性を比較する公開レポート
- コミュニティペイロード投稿 — 自動検証付きの構造化された貢献プロセス
- REST APIモード — SecurityForgeをCI/CDパイプラインに統合
- さらなるAI統合 — Codex CLI、Gemini、Ollama経由のローカルLLM
$ securityforge detect https://example.com
$ securityforge test https://example.com -c xss --max 10
# これだけです。ワンインストール。設定なし。APIキーなし。