セキュリティの甘いデフォルト設定の検出

設定が不足しているためアプリケーションが不安全に実行されるfail-open脆弱性を検出します。悪用可能なデフォルト設定と、安全に失敗する fail-secure パターンを区別します。

• Fail-open (CRITICAL): SECRET = env.get('KEY') or 'default' → 弱い秘密鍵を使用してアプリが実行される
• Fail-secure (SAFE): SECRET = env['KEY'] → 設定が不足するとアプリがクラッシュする

使用場面

• 本番アプリケーションのセキュリティ監査 (認証、暗号化、API セキュリティ)
• デプロイメントファイル、IaC テンプレート、Docker 設定の確認
• 環境変数の処理と秘密鍵管理のコードレビュー
• デプロイ前の確認 (ハードコードされた認証情報や弱いデフォルト設定の確認)

使用してはいけない場面

以下の場合はこのスキルを使用しないでください:

• テスト環境に明確にスコープされたテストフィクスチャ (test/、spec/、__tests__/ の中のファイル)
• 例またはテンプレートファイル (.example、.template、.sample サフィックス)
• 開発専用ツール (開発用ローカル Docker Compose、デバッグスクリプト)
• README.md または docs/ ディレクトリの文書化例
• デプロイ時に置き換えられるビルド時設定
• 適切な設定がないとアプリが起動しないクラッシュ動作 (fail-secure)

疑わしい場合は、アプリがデフォルトで実行するか、それともクラッシュするかを判断するためにコードパスをトレースしてください。

却下する正当化

• 「それは開発用のデフォルト設定に過ぎない」 → 本番コードに含まれていれば、それは検出すべき問題です
• 「本番設定がそれをオーバーライドする」 → 本番設定の存在を確認してください。存在しない場合、コードレベルの脆弱性は残ります
• 「適切な設定なしでは実行されることはない」 → コードトレースで証明してください。多くのアプリが静かに失敗します
• 「認証の背後にある」 → 多層防御の観点から、セッションが侵害されるとデフォルト設定の弱さも悪用されます
• 「リリース前に修正します」 → 今ドキュメント化してください。「後で」はめったに実現しません

ワークフロー

潜在的なすべての検出について、このワークフローに従ってください:

1. 検索: プロジェクト内の検出と甘いデフォルト設定の発見

プログラミング言語、フレームワーク、プロジェクト規約を確認します。この情報を使用して、秘密鍵の保存場所、秘密鍵の使用パターン、認証情報を必要とするサードパーティ統合、暗号化、その他の関連設定などをさらに検出します。この情報をさらに使用して、甘いデフォルト設定を分析します。

例 **/config/、**/auth/、**/database/**、環境ファイルでパターンを検索:

• フォールバック秘密鍵: getenv.*\) or ['"]、process\.env\.[A-Z_]+ \|\| ['"]、ENV\.fetch.*default:
• ハードコードされた認証情報: password.*=.*['"][^'"]{8,}['"]、api[_-]?key.*=.*['"][^'"]+['"]
• 弱いデフォルト設定: DEBUG.*=.*true、AUTH.*=.*false、CORS.*=.*\*
• 暗号化アルゴリズム: セキュリティコンテキストの MD5|SHA1|DES|RC4|ECB

検出結果に基づいて検索アプローチをカスタマイズしてください。

テストフィクスチャや例ファイルではなく、本番環境に到達するコードに焦点を当ててください。

2. 検証: 実際の動作

各マッチについて、コードパスをトレースして実行時の動作を理解します。

回答すべき質問:

• このコードはいつ実行されるか? (起動時 vs. 実行時)
• 設定変数が不足している場合はどうなるか?
• セキュアな設定を強制する検証があるか?

3. 確認: 本番環境への影響

この問題が本番環境に到達するかどうかを判断します:

本番設定が変数を提供する場合 → 低い重大度 (ただしコードレベルの脆弱性は残ります) 本番設定が不足しているか、デフォルト設定を使用する場合 → CRITICAL

4. 報告: 証拠を含めて

報告例:

Finding: ハードコードされた JWT シークレットフォールバック
Location: src/auth/jwt.ts:15
Pattern: const secret = process.env.JWT_SECRET || 'default';

Verification: JWT_SECRET なしでアプリが起動; シークレットが jwt.sign() の 42 行目で使用される
Production Impact: Dockerfile に JWT_SECRET がない
Exploitation: 攻撃者は 'default' を使用して JWT を偽造し、不正アクセスを獲得

クイック検証チェックリスト

フォールバック秘密鍵: SECRET = env.get(X) or Y → 検証: 環境変数なしでアプリが起動するか? 秘密鍵が暗号化/認証で使用されるか? → スキップ: テストフィクスチャ、例ファイル

デフォルト認証情報: ハードコードされた username/password ペア → 検証: デプロイされた設定で有効か? 実行時オーバーライドがないか? → スキップ: 無効化されたアカウント、文書化例

Fail-Open セキュリティ: AUTH_REQUIRED = env.get(X, 'false') → 検証: デフォルト設定は不安全か (false/disabled/permissive)? → 安全: アプリがクラッシュするか、デフォルト設定が安全 (true/enabled/restricted)

弱い暗号化: セキュリティコンテキストの MD5/SHA1/DES/RC4/ECB → 検証: パスワード、暗号化、またはトークンに使用されるか? → スキップ: チェックサム、セキュリティ以外のハッシング

広範なアクセス: CORS *、権限 0777、公開デフォルト → 検証: デフォルトで不正アクセスを許可するか? → スキップ: 正当な理由のある明示的な広範な設定

デバッグ機能: スタックトレース、イントロスペクション、詳細エラー → 検証: デフォルトで有効か? レスポンスで公開されるか? → スキップ: ログのみ、ユーザー向けではない

詳細な例とカウンター例については、examples.md を参照してください。