mcpField
W
wooyun-legacy

wooyun-legacy

github.com/trailofbitsセキュリティ522105 回インストール15 週間前に更新
リポジトリ

wooyun-legacy について

wooyun-legacyは、2010年から2016年に報告されたWooYunの事例を基にしたWeb脆弱性分析ナレッジベースです。許可を得たセキュリティテストやコードレビュー向けに、テスト手法、チェックリスト、防御策をまとめています。

主な機能

  1. 01Web脆弱性のパターンとチェックリスト
  2. 02インジェクション、XSS、アクセス制御を網羅
  3. 03攻撃対象領域の整理方法
  4. 04テストの優先順位付け
  5. 05一般的な脆弱性への緩和策

活用シーン

  1. 01許可されたWebアプリの侵入テストを計画
  2. 02サーバー側またはクライアント側コードをレビュー
  3. 03セキュリティテストケースやチェックリストを作成
  4. 04Web脆弱性の修正状況を評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/trailofbits/skills-curated --skill wooyun-legacy

インストール後、Claude Code で/wooyun-legacyを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
bank-penetration.md
command-execution.md
file-upload.md
info-disclosure.md
logic-flaws.md
path-traversal.md
sql-injection.md
telecom-penetration.md
unauthorized-access.md
xss.md
references/checklists/
command-execution-checklist.md
csrf-checklist.md
file-upload-checklist.md
info-disclosure-checklist.md
logic-flaws-checklist.md
misconfig-checklist.md
path-traversal-checklist.md
rce-checklist.md
sql-injection-checklist.md
ssrf-checklist.md
unauthorized-access-checklist.md
weak-password-checklist.md
xss-checklist.md
xxe-checklist.md

詳細

WooYun 脆弱性分析ナレッジベース

WooYun プラットフォームに報告された 88,636 件の実際の脆弱性事例(2010~2016 年)から抽出した手法とテストパターンです。


使用する場面

ここで説明するテストは、テストを実施する明示的な許可を得たシステムに対してのみ行ってください。

  • Web アプリケーションのペネトレーションテスト
  • セキュリティコードレビュー(サーバーサイドまたはクライアントサイド)
  • テストする明示的な許可を得た Web ターゲットに対する脆弱性調査
  • セキュリティテストケースやチェックリストの作成
  • Web アプリケーションの攻撃対象領域の評価
  • 修正の有効性のレビュー
  • 許可されたセキュリティテストの状況におけるトレーニングや教育

使用しない場面

  • ネットワークインフラストラクチャのテスト(ファイアウォール、ルーター、スイッチ)
  • モバイルアプリケーションのバイナリー解析
  • マルウェア解析やリバースエンジニアリング
  • コンプライアンスのみを対象とする評価(テストを伴わない PCI-DSS、SOC2 のチェックリスト)
  • 物理セキュリティ評価
  • ソーシャルエンジニアリングキャンペーン
  • クラウドインフラストラクチャの設定ミス(IAM、S3 バケット)。これらには Web 脆弱性のパターンではなく、クラウド専用のツールが必要です。

退けるべき自己正当化

次のような近道は、脆弱性の見落としにつながります。退けてください。

  • 「WAF が検出してくれる」— WAF は回避可能です。ミドルウェアではなく、アプリケーションのロジックをテストしてください。
  • 「社内アプリだから、認証は重要ではない」— 社内アプリも SSRF、ラテラルムーブメント、認証情報の使い回しによって侵害されます。
  • 「どこでもすでにパラメーター化クエリーを使っている」— ORM の誤用、動的 SQL を使ったストアドプロシージャ、二次インジェクションがないか確認してください。
  • 「フレームワークが XSS を処理してくれる」— テンプレートエンジンには生出力モードがあり、JavaScript コンテキストでは HTML エンコーディングを回避でき、DOM XSS は完全にクライアントサイドで発生します。
  • 「拡張子を確認しているから、ファイルアップロードは安全」— 拡張子の確認は、ヌルバイト、二重拡張子、パーサー間の不一致、競合状態によって回避されます。
  • 「フロントエンドで検証している」— クライアントサイドの検証は UX 機能であり、セキュリティ制御ではありません。
  • 「誰もその URL を推測できない」— 隠蔽によるセキュリティは、ディレクトリの総当たり、リファラーの漏えい、JS ソースの分析に対して有効ではありません。
  • 「深刻度が低いので、報告する価値はない」— 低深刻度の検出結果も、連鎖することで重大な攻撃経路になります。

基本的な考え方

Vulnerability = Expected Behavior - Actual Behavior
             = Developer Assumptions + Attacker Input -> Unexpected State

Analysis chain:
1. Where does data come from?  (Input sources)
   -> GET/POST/Cookie/Header/File/WebSocket
2. Where does data flow?       (Data path)
   -> Validation -> Processing -> Storage -> Output
3. Where is data trusted?      (Trust boundaries)
   -> Client / Server / Database / OS / External service
4. How is data processed?      (Processing logic)
   -> Filter / Escape / Validate / Execute
5. Where does data end up?     (Output sinks)
   -> HTML / SQL / Shell / Filesystem / Log / Email

攻撃対象領域のマッピング

              +-------------------------------------------+
              |         Application Attack Surface         |
              +-------------------------------------------+
                                  |
          +-----------------------+-----------------------+
          |                       |                       |
     +----v----+            +-----v-----+           +-----v-----+
     |  Input  |            | Processing|           |  Output   |
     +---------+            +-----------+           +-----------+
     | GET     |            | Input     |           | HTML page |
     | POST    |    ->      | validation|    ->     | JSON resp |
     | Cookie  |            | Biz logic |           | File DL   |
     | Headers |            | DB query  |           | Error msg |
     | File    |            | File op   |           | Log entry |
     | Upload  |            | Sys call  |           | Email     |
     +---------+            +-----------+           +-----------+

SQL インジェクション

事例数: 27,732 | 参照: sql-injection.md | チェックリスト: sql-injection-checklist.md

高リスクのパラメーター: id、sort_id、username、password、search、 keyword、page、order、cat_id

インジェクションポイントの検出:

  • 文字列終端文字: ' " ) ') ") -- # /*
  • DB のフィンガープリント: @@version(MSSQL)、version()(MySQL)、 v$version(Oracle)

回避手法:

  • 空白文字: /**/ %09 %0a ()
  • キーワード: SeLeCt sel%00ect /*!select*/
  • 等号: LIKE REGEXP BETWEEN IN
  • 引用符: 0x の 16 進数表記、char()、concat()

基本的な防御策: パラメーター化クエリー(PreparedStatement/ORM バインディング)。


クロスサイトスクリプティング(XSS)

事例数: 7,532 | 参照: xss.md | チェックリスト: xss-checklist.md

出力箇所: ユーザープロフィールのフィールド(ニックネーム、自己紹介)、検索結果への入力の反映、 ファイルメタデータ(ファイル名、代替テキスト)、メールの内容(件名、本文)

回避手法:

  • タグの改変: <ScRiPt> <script/x> <script\n>
  • イベントハンドラー: onerror onload onmouseover onfocus
  • エンコーディング: HTML エンティティ、JS Unicode、URL エンコーディング
  • プロトコルハンドラー: javascript: data: vbscript:

基本的な防御策: コンテキストを考慮した出力エンコーディング+コンテンツセキュリティポリシー。


コマンド実行

件数: 6,826 | 参考: command-execution.md | チェックリスト: command-execution-checklist.md

エントリーポイント:システムコマンドのラッパー(ping、traceroute、nslookup)、 ファイル操作(圧縮、展開、画像処理)、コード評価 (eval、assert、preg_replace(/e))、フレームワークの脆弱性 (Struts2、WebLogic、JBoss)

コマンドチェーン:

  • Linux:; | || && \ $()`
  • Windows:& | || &&

回避手法:

  • 空白文字:${IFS} $IFS$9 %09 < <>
  • キーワード:ca\t ca''t c$@at /???/??t
  • エンコード:$(printf "\x63\x61\x74")、 `echo Y2F0|base64 -d`

主な防御策:シェルの呼び出しを避け、exec より execFile を使い、 許可する入力を許可リストで管理します。


ファイルアップロード

件数: 2,711 | 参考: file-upload.md | チェックリスト: file-upload-checklist.md

検出の回避:

  • クライアント側の検証:JS を変更するか、リクエストを直接送信する
  • Content-Type:image/gif ヘッダーと PHP コードの本文を使用する
  • 拡張子:.php5 .phtml .pht .php. .php::$DATA
  • 内容検査:GIF89a と <?php を組み合わせるか、画像ベースのウェブシェルを使用する
  • パーサーの不一致:/upload/1.asp;.jpg(IIS 6.0)

パーサー固有の脆弱性:

  • IIS 6.0:/test.asp/1.jpg、test.asp;.jpg
  • Apache:.php.xxx(不明な拡張子へのフォールバック)
  • Nginx:/1.jpg/1.php(cgi.fix_pathinfo)
  • Tomcat:test.jsp%00.jpg

主な防御策:拡張子を許可リストで管理し、アップロードされたファイル名を変更して、 ウェブルートの外部に保存し、サーバー側でコンテンツタイプを検証します。


パストラバーサル

件数: 2,854 | 参考: path-traversal.md | チェックリスト: path-traversal-checklist.md

リスクの高いパラメーター:file、path、filename、url、dir、 template、page、include、download

トラバーサルのペイロード:

  • 基本形:../../../etc/passwd
  • エンコード:%2e%2e%2f、..%252f、%c0%ae%c0%ae/
  • NULL バイト:../../../etc/passwd%00.jpg
  • Windows:..\..\..\windows\win.ini

対象ファイル(Linux):/etc/passwd、/etc/shadow、 /proc/self/environ、/var/log/apache2/access.log

主な防御策:正規パスを解決し、許可リストに登録されたディレクトリと照合して検証し、 ファイルパスにユーザー入力を直接使用しないでください。


不正アクセス

件数: 14,377 | 参考: unauthorized-access.md | チェックリスト: unauthorized-access-checklist.md

アクセスの種類:

  • 管理パネルの露出:/admin、/manager、/console
  • 認証なしの API:トークン検証の欠落、予測可能なトークン
  • 露出したサービス:Redis(6379)、MongoDB(27017)、 Elasticsearch(9200)、Memcached(11211)、Docker(2375)
  • IDOR:ID の列挙による水平権限昇格

主な防御策:すべてのエンドポイントで認証と認可を行い、 セッションを管理し、最小権限の原則を適用します。


情報漏えい

件数: 7,337 | 参考: info-disclosure.md | チェックリスト: info-disclosure-checklist.md

情報漏えいの原因:スタックトレースを含むエラーメッセージ、公開された .git または .svn ディレクトリ、バックアップファイル(.bak、.sql、.tar.gz)、 設定ファイル、デバッグ用エンドポイント、ディレクトリ一覧

主な防御策:カスタムエラーページを用意し、ディレクトリ一覧を無効にして、本番環境では デバッグ用エンドポイントを削除し、一般にアクセス可能なファイルを監査します。


ビジネスロジックの欠陥

ケース数: 8,292 | 参考資料: logic-flaws.md | チェックリスト: logic-flaws-checklist.md

脆弱性のパターン:

  • パスワードリセット:レスポンス本文に含まれる確認コード、手順のスキップ、 制御可能なリセットトークン
  • 認可のバイパス:水平(ID の列挙)、垂直(権限の昇格)
  • 決済ロジック:金額の改ざん、数量の操作、クーポンの併用
  • CAPTCHA:更新されない、再利用可能、総当たり攻撃が可能、クライアント側のみ

テストの進め方:

  1. ビジネスフローを把握する -> 状態遷移図を描く
  2. 重要なチェックを特定する -> 結果を左右するパラメーターを確認する
  3. バイパスを試みる -> パラメーターの変更/手順のスキップ/リプレイ/競合を試す
  4. 影響を検証する -> 被害の範囲を実証する

基本的な防御策:ビジネス上重要なロジックをすべてサーバー側で検証します。


その他のカテゴリ

これらのカテゴリは、詳細な参考資料がないケースデータに基づいています。それぞれに、実際のケースから抽出したテスト用チェックリストがあります。

カテゴリチェックリスト
CSRFcsrf-checklist.md
SSRFssrf-checklist.md
弱いパスワードweak-password-checklist.md
設定ミスmisconfig-checklist.md
リモートコード実行rce-checklist.md
XML 外部エンティティ(XXE)xxe-checklist.md

注: RCE のチェックリストでは、デシリアライゼーション、OGNL インジェクション、フレームワーク固有のリモートコード実行を扱います。これらは、前述のコマンド実行に関する参考資料が焦点を当てる OS コマンドインジェクションとは異なります。


手法のケーススタディ

実際の侵入テスト手法の例(匿名化済み):

ケーススタディ説明
bank-penetration.md金融機関に対する複数段階の攻撃チェーン
telecom-penetration.md通信事業者のインフラへの侵入

これらの例は、個々の脆弱性が連鎖して、システム全体の侵害に至るシナリオを示しています。


テスト優先度の枠組み

優先度:高(最初にテスト)
  1. SQL インジェクション — データへの直接アクセス、ケース数が最多(27,732)
  2. コマンド実行 — OS レベルでの侵害
  3. ファイルアップロード — ウェブシェルによる任意コードの実行
優先度:中
  1. 不正アクセス — ケース数が2番目に多い(14,377)
  2. ビジネスロジックの欠陥 — アプリケーション固有で、自動化が困難
  3. XSS — セッションハイジャック、フィッシング
優先度:低(ただし重要)
  1. パストラバーサル — ファイルの読み取り、場合によっては書き込み
  2. 情報漏えい — 偵察に役立ち、脆弱性の連鎖を可能にする
  3. CSRF/SSRF/XXE — 深刻度は状況によって異なる

防御策のクイックリファレンス

脆弱性基本的な防御策実装
SQL インジェクションパラメーター化クエリPreparedStatement/ORM
XSS出力のエンコードコンテキストに応じたエスケープ + CSP
コマンド実行シェルを避けるexec ではなく execFile、許可リスト
ファイルアップロード厳格な検証拡張子の許可リスト、名前の変更、分離
パストラバーサル正規パス解決し、許可リストに対して検証
不正アクセスアクセス制御認証 + 認可 + セッション管理
ロジックの欠陥サーバー側でのチェックビジネスロジックをすべてサーバー側で検証
情報漏えい公開範囲の最小化独自のエラー、プロダクション環境でのデバッグ情報の非表示

重要な洞察

このデータベースにある88,636件すべての脆弱性には、共通する根本原因があります。 開発者が想定していたことと、攻撃者が実際に提供したものとの隔たりです。 効果的なセキュリティテストでは、すべての信頼境界であらゆる想定を体系的に検証します。

データから得られた4つの原則:

  1. 境界を意識する — すべての脆弱性は信頼境界で発生します
  2. データフローを追跡する — 入力から出力までデータを漏れなく追跡します
  3. 想定を疑う — あらゆる「明白な」検証を問い直します
  4. 連鎖を組み合わせる — 個々の深刻度が低い指摘も組み合わさると、重大な攻撃経路になります

コメント