mcpField
I
injection-testing

injection-testing

github.com/mn-youssefセキュリティ4938 回インストール20 週間前に更新
リポジトリ

injection-testing について

injection-testingは、信頼できない入力がインタープリターに届く可能性のある、許可済みアプリケーションを動的にテストするセキュリティスキルです。候補となる入力箇所を特定し、構造変化を調べ、制御された非破壊の証拠で影響を確認します。

主な機能

  1. 01入力からインタープリターまでの経路特定
  2. 02SQL、シェル、テンプレート、パーサーの注入検査
  3. 03無害な証拠による検出確認
  4. 04データ持ち出しなしで影響を限定
  5. 05箇所、ペイロード、証拠、影響の報告

活用シーン

  1. 01許可済みアプリケーションの注入脆弱性テスト
  2. 02時間差や帯域外信号によるブラインド注入の確認
  3. 03修正に向けた限定的な影響の記録

インストール

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

$npx skills add https://github.com/mn-youssef/security-skills --skill injection-testing

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

同梱ファイルreferences/injection-recipes.md

詳細

インジェクションテスト(検出/悪用 — 入力がインタープリターに到達する場合)

概要

インジェクションは、入力がインタープリターによって実行される言語(SQL、シェル、テンプレートエンジン、XML/LDAP/XPath パーサー)に渡ると発生します。このスキルでは動的にそれを実証します。コードレベルのパターンについては、security-code-audit/references/database.md と api-backend.md を参照してください。

基本原則: 入力が単なるデータではなく、コマンドの構造を変える箇所を見つけます。インジェクションが成立するのは、インタープリターの動作を変える小さな構造変更ペイロードです。

適用する場合/スキップする場合

  • 適用する場合: 信頼できない入力がインタープリター(SQL/NoSQL DB、OS シェル、テンプレートエンジン、XML/LDAP/XPath パーサー)に到達する可能性がある場合。
  • スキップする場合: 対象のシンクの種類が存在しない場合 → そのインジェクションの種類は該当しません。
  • 該当しない場合: 存在しないインタープリター(例:「SQL なし → SQLi は該当なし」)を明記し、存在するシンクのみをテストしてください。適用対象が一部に限られるのは通常のことです。

⚠️ 許可

自分が所有する、またはテストを許可されたアプリで実施し、状態を変更するペイロードは本番以外の環境で使用してください。実データに対して --dump を実行しないでください。共有システムで --os-shell/RCE を実行しないでください。; DROP などの破壊的なペイロードも使用しないでください。被害を与えずに確認してください。

方法

  1. シンクをマッピングする — クエリ/コマンド/テンプレート/パーサーに到達する可能性があるすべての入力を特定します(監査結果を使用)。
  2. プローブする — 構造を壊す文字を送信し、動作の変化(エラー、結果の違い、応答時間)を確認します。
  3. 確認する — 「何かが変わった」という段階から、制御された無害な実証へ進みます。
  4. 影響範囲を限定する — 攻撃者が到達できる可能性がある範囲を記録します。実データを持ち出してはいけません。

クイックリファレンス — プローブ → 確認

種類プローブ確認(無害)
SQLi' " ') → エラー/変化真偽値 ' OR '1'='1 ;時間 ' OR SLEEP(5)--
Blind SQLi出力がない場合は?時間ベース/真偽値の差分
NoSQLi'、{"$ne":null}、[$gt]=演算子インジェクションによる認証回避
コマンド;id `id``id``$(id)`
SSTI${7*7} {{7*7}} <%=7*7%>49 がレンダリングされる → エンジン固有のエスカレーション
XXE外部エンティティを含む XMLOOB フェッチ/ファイル読み取り(無害なカナリア)
LDAP*)(uid=*フィルターの改変
XPath' or '1'='1ノード選択の変化
CRLF反映されるヘッダー内の %0d%0aヘッダー/レスポンス分割

種類ごとの検出方法と安全な確認用ペイロードについては、references/injection-recipes.md を参照してください。

ツール

SQLi の確認には sqlmap を使用します(対象を限定:--batch --level/--risk は低く設定し、--dump/--os-shell は使用しないでください)。ファジングには Burp/ZAP を、Blind/XXE にはインタラクションサーバー(Burp Collaborator/interactsh)経由の OOB を使用します。 これらは active-pentest を通じて実行してください。

出力

各検出結果について、シンク、構造変更ペイロード、解釈が行われたことを示す証拠(エラー/時間/OOB)、影響範囲の限定評価(例:「DB の読み取りが可能」)を記載します。重大度は High~Critical です。

引き継ぎ

多くの場合、侵入の足掛かり/エスカレーション手段になります → vulnerability-chaining。修正には security-hardening を使用してください(パラメーター化、安全な API、許可リスト、外部エンティティの無効化、構造を含まないクエリの出力)。

よくある間違い

  • SQLi だけを試す — SSTI、XXE、コマンド、NoSQL はテンプレート、ファイルパーサー、検索、JSON に潜んでいます。
  • Blind インジェクションを見落とす — 目に見える出力がないからといって脆弱ではないとは限りません。時間/真偽値/OOB を使用してください。
  • 「証明する」ために破壊的な操作を行う — SLEEP や 49 で実証できますが、DROP は破壊行為です。
  • 二次インジェクションを忘れる — 保存された入力が、後でクエリに使用されたときにインジェクションを引き起こします。

コメント