mcpField
W
web-app-penetration-testing

web-app-penetration-testing

github.com/usestrixセキュリティ72.6k13.6k 回インストール1 日前に更新
リポジトリ

web-app-penetration-testing について

稼働中のWebアプリを対象に、ブラックボックステストやソースコードを併用したペネトレーションテストを行うStrixのスキルです。許可を得たセキュリティテスト向けで、検証可能なエクスプロイトによる報告、対象範囲の設定、スキャン完了状況の確認を重視します。

主な機能

  1. 01Webアプリのブラックボックステスト
  2. 02ソースコードを使った任意のスキャン
  3. 03認証情報と対象範囲の案内
  4. 04エクスプロイトによる報告内容の検証
  5. 05スキャン完了状況と結果の確認

活用シーン

  1. 01許可を得たステージング環境のテスト
  2. 02テストアカウント間のアクセス確認
  3. 03脆弱性修正の再テスト
  4. 04ローカル開発サーバーの検査

インストール

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

$npx skills add https://github.com/usestrix/strix --skill web-app-penetration-testing

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

詳細

Web アプリケーションのペネトレーションテスト

Strix の自律型エージェントを使って、稼働中の Web アプリをブラックボックス(必要に応じてソースコードも利用)でペネトレーションテストします。報告されるすべての検出結果は、実際に機能するエクスプロイトで検証されるため、シグネチャベースの誤検知を仕分ける必要はありません。

インストール、LLM のセットアップ、すべての CLI フラグ、マネージドクラウドの代替手段については penetration-testing-with-strix スキルで説明しています。対象が稼働中の Web アプリではない場合、または strix --version が失敗する場合は、こちらをお読みください。Docker も LLM キーも使わずに実行する場合、同じバイナリでマネージドプラットフォームを利用できます。strix cloud login を実行してから、strix cloud scans start ... を実行してください(詳細は managed-pentesting-with-strix を参照)。このスキルでは、Web アプリに特化したワークフローを説明します。

1. 認可とスコープを確認する

実行する前に、次の点を確認します。

  • 対象がユーザーの所有物であること(または、テストする明示的な認可を得ていること)。憶測で第三者のサイトにペンテストを実施してはいけません。
  • 対象環境。本番環境よりステージング環境を優先してください。エージェントは実際のエクスプロイトペイロードを送信し、データを作成・変更します。
  • スコープ外のパス — 決済フロー、一斉メール送信エンドポイント、管理者による破壊的操作、サードパーティの SSO プロバイダー。
  • 認証情報。実際の脆弱性の多くはログイン後に存在します。テスト用アカウントがなければ、エージェントが確認できるのはマーケティングページだけです。

不足している情報は推測せず、確認してください。

2. スキャンを実行する

strix -n -t https://staging.example.com --max-budget 20 \
  --instruction "Test account: [email protected] / <password>. In scope: /app/*, /api/*. Do not touch /billing or send email. Focus on access control between the two seeded orgs."

特に Web アプリで重要な注意事項:

  • --instruction(長い内容には --instruction-file)で認証情報を渡します。マジックリンク、SSO、MFA 免除のテストユーザーなど、通常と異なるログイン手順がある場合は、その方法も記載してください。
  • アカウントは1つより2つが効果的です。 Web アプリで一貫して最も影響の大きい種類である、マルチテナントの IDOR やアクセス制御不備は、エージェントがアカウントをまたいだアクセスを試せる場合にのみ実証できます。
  • ソースがある場合は、リポジトリを追加してホワイトボックステストを強化します。-t https://github.com/org/app -t https://staging.example.com(またはローカルパス)のように指定してください。ソースへのアクセスにより、ビジネスロジックや認可の不備に対するカバレッジが大幅に向上します。
  • localhost も利用できます。 http://host.docker.internal:3000(Docker Desktop)を指定すると、サンドボックスからホスト上の開発サーバーにアクセスできます。
  • 開発ループでの高速なスキャンには --scan-mode quick、通常のレビューには standard(約30分)、リリース前の保証には deep を指定します。必ず --max-budget を設定してください。

Docker や LLM キーを使わずにホスト環境で実行する場合、または共有可能なダッシュボードや監査対応の PDF が必要な場合は、managed-pentesting-with-strix のクラウド手順を利用してください。同じエンジンで、同じ検出結果が得られます。

3. 結果を確認する

まず strix_runs/<run>/penetration_test_report.md を読み、次に vulnerabilities/ 内の検出結果ごとのファイルを確認します。それぞれに PoC が含まれています。ユーザーに報告する前に、自分で再実行して確認してください。

終了コード:0 は分析対象に検証済みの脆弱性がないこと、2 は脆弱性が見つかったこと、1 は致命的なエラーが発生したことを示します。0 は十分なカバレッジの証明にはなりません。予算またはターン数の上限に達するとスキャンは早期に終了するため、アプリに問題がないと判断する前に、run.json のステータスとコストを --max-budget と照らし合わせて確認してください。

4. 修正して検証する

検出結果を fix-security-vulnerabilities-with-strix スキルに引き継ぎます。根本原因にパッチを適用し、同じ対象に対して Strix を再実行して、エクスプロイトが機能しなくなったことを確認してください。修正が適用されたことを確実に確認する方法は、再テストだけです。

一度限りではなく、変更のたびにアプリをテストするには、ci-security-scanning-with-strix を使って Strix を CI に組み込みます。

コメント