mcpField
S
security-hardening

security-hardening

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

security-hardening について

監査やペネトレーションテストの指摘を、検証済みの修正につなげるセキュリティ強化スキルです。根本原因への対処、多層防御、元の PoC による再テストを重視します。

主な機能

  1. 01根本原因の修正
  2. 02安全な実装パターンの案内
  3. 03多層防御の追加
  4. 04PoC による再テスト
  5. 05回帰テストのチェック

活用シーン

  1. 01報告されたインジェクションや XSS の修正
  2. 02認可や認証の修正確認
  3. 03セキュリティ指摘の回帰テスト追加

インストール

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

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

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

詳細

セキュリティ強化(FIX フェーズ)

概要

検出事項を、正しく検証済みの修正につなげます。適切なレイヤーで根本原因を修正し、多層防御を追加してから、穴が塞がれたことを証明するために再テストします。

基本原則: 再テストしていない修正は、修正ではなく期待にすぎません。元のエクスプロイトを再現し、今度は失敗することを確認してください。

検出事項ごとのプロセス

  1. 根本原因 — 信頼できないデータがなぜシンクに届くのでしょうか?症状をブロックリストで塞ぐのではなく、原因となる箇所を修正します。
  2. 安全なパターンを適用 — 下の表を参照してください。
  3. 多層防御 — 独立した制御をもう1つ追加します(検証とパラメーター化など)。
  4. 再テスト — active-pentest/監査の正確な PoC を再実行し、今度は失敗することを確認します。
  5. 回帰防止 — 気付かないうちに再発しないよう、テストを追加します。

安全なパターンの早見表

脆弱性根本原因の修正多層防御
SQL/NoSQL インジェクションパラメーター化クエリ/ORM バインディングを使用し、動的な識別子には許可リストを適用最小権限の DB ユーザー、入力検証
コマンドインジェクションシェルを避け、exec 配列/安全な API を使用し、シェル補間を行わない引数の許可リスト、権限の降格
XSSコンテキストに応じた出力エンコーディング、フレームワークの自動エスケープ、textContentCSP、HTML のサニタイズ(DOMPurify)、HttpOnly クッキー
アクセス制御の不備/IDORすべてのアクションでサーバー側の認可を強制し、クエリの対象をユーザーに限定デフォルト拒否、一元化されたポリシーチェック
マスアサインメントバインド可能なフィールドの明示的な許可リスト(DTO/スキーマ)読み取りモデルと書き込みモデルを分離
認証の不備bcrypt/argon2、CSPRNG トークン、ログイン時にセッションをローテーションMFA、レート制限、短いトークン TTL と失効
暗号化の不備信頼できるライブラリ、AES-GCM、あらゆる通信に TLS を使用、自作暗号を使わない鍵管理/ローテーション、HSTS
SSRF宛先の許可リスト、解決と検証、メタデータ/内部 IP をブロック送信トラフィックのファイアウォール、生の URL を取得しない
安全でないデシリアライゼーション安全な形式(JSON)、yaml.safe_load、署名付きペイロード型の許可リスト、隔離
コード内のシークレット環境変数/シークレットマネージャーに移し、露出したシークレットをローテーションCI でのシークレットスキャン、短期間有効なトークン
セキュリティ設定の不備デバッグを無効化し、CORS を最小権限に設定して、デフォルト認証情報を削除強化されたベースライン、CI での設定レビュー
モバイルでの安全でない保存Keychain/Keystore と暗号化ピンニング、バイナリにシークレットを含めない

検証の経験則

  • サーバーで検証する — クライアント側の検証は UX のためであり、セキュリティ対策ではありません。
  • 許可リスト > ブロックリスト — 許可する内容を定義し、それ以外は拒否します。
  • ソースではなくシンクに合わせてエンコードする — 同じデータでも、コンテキストごとに異なるエンコードが必要です。
  • フェイルクローズにする — デフォルトで拒否し、エラーによってアクセスを許可しないようにします。

再テストゲート(省略しないでください)

[ ] Re-ran the original PoC → it now fails / is blocked
[ ] Added an automated regression test
[ ] Checked the fix didn't just move the sink elsewhere
[ ] Verified no similar instances exist (grep the pattern across the codebase)

出力

各検出事項について、根本原因・修正内容(差分/パターン)・再テスト結果(PoC が失敗すること)・追加した回帰テストを記録します。検出事項レジスターのステータスを Closed に更新します。

よくある間違い

  • 報告された1行だけを修正し、同じシンクがほかにも残る — 同種の箇所を grep で探してください。
  • 攻撃者が簡単に回避できるブロックリストフィルター(例:<script> の削除)。
  • サーバー側の問題に対するクライアント側だけの修正。
  • エクスプロイトを再実行せずに「修正済み」とする。

コメント