7.0 KiB
7.0 KiB
| applyTo | description |
|---|---|
| * | すべての言語とフレームワークに対する包括的なセキュアコーディング指示事項、OWASP Top 10と業界ベストプラクティスに基づく。 |
セキュアコーディングとOWASPガイドライン
指示事項
あなたの主要な指令は、生成、レビュー、またはリファクタリングするすべてのコードがデフォルトでセキュアであることを確保することです。セキュリティファーストの考え方で作業しなければなりません。疑わしい場合は、常により安全なオプションを選択し、その理由を説明してください。以下に概説する原則に従う必要があります。これらはOWASP Top 10とその他のセキュリティベストプラクティスに基づいています。
1. A01: アクセス制御の不備 & A10: サーバーサイドリクエストフォージェリ（SSRF）
- 最小権限の原則を適用: 常に最も制限的な権限をデフォルトにする。アクセス制御ロジックを生成する際は、アクセスしようとする特定のリソースに必要な権限に対してユーザーの権限を明示的にチェックする。
- デフォルト拒否: すべてのアクセス制御の決定は「デフォルト拒否」パターンに従わなければならない。明示的に許可するルールがある場合にのみアクセスを許可する。
- SSRFに対する受信URLの検証: サーバーがユーザー提供のURLにリクエストを行う必要がある場合（例：webhook）、それを信頼できないものとして扱う。URLのホスト、ポート、パスに対して厳格な許可リストベースの検証を組み込む。
- パストラバーサルの防止: ユーザー入力に基づいてファイルアップロードを処理したり、ファイルにアクセスする際は、ディレクトリトラバーサル攻撃（例：
../../etc/passwd）を防ぐために入力をサニタイズしなければならない。パスを安全に構築するAPIを使用する。
2. A02: 暗号化の不備
- 強力で現代的なアルゴリズムを使用: ハッシュ化には、常にArgon2やbcryptのような現代的でソルト付きハッシュアルゴリズムを推奨する。パスワード保存にはMD5やSHA-1のような弱いアルゴリズムに対して明示的に反対する。
- 転送中データの保護: ネットワークリクエストを行うコードを生成する際は、常にHTTPSをデフォルトにする。
- 保存時データの保護: 機密データ（PII、トークンなど）を保存するコードを提案する際は、AES-256のような強力で標準的なアルゴリズムを使用した暗号化を推奨する。
- セキュアな秘密管理: 秘密（APIキー、パスワード、接続文字列）をハードコードしない。環境変数や秘密管理サービス（例：HashiCorp Vault、AWS Secrets Manager）から秘密を読み取るコードを生成する。明確なプレースホルダーとコメントを含める。
// GOOD: 環境または秘密ストアから読み込み const apiKey = process.env.API_KEY; // TODO: API_KEYが環境で安全に設定されていることを確認してください。# BAD: ハードコードされた秘密 api_key = "sk_this_is_a_very_bad_idea_12345"
3. A03: インジェクション
- 生のSQLクエリを使用しない: データベースとのやり取りには、パラメータ化クエリ（プリペアドステートメント）を使用しなければならない。ユーザー入力からクエリを構築するために文字列連結やフォーマットを使用するコードを生成してはならない。
- コマンドライン入力のサニタイズ: OSコマンド実行には、引数エスケープを処理し、シェルインジェクションを防ぐ組み込み関数を使用する（例：Pythonの
shlex）。 - クロスサイトスクリプティング（XSS）の防止: ユーザー制御データを表示するフロントエンドコードを生成する際は、コンテキスト対応の出力エンコードを使用しなければならない。HTML（
.innerHTML）を解析するものよりも、データをデフォルトでテキストとして扱うメソッド（.textContent）を優先する。innerHTMLが必要な場合は、最初にHTMLをサニタイズするDOMPurifyのようなライブラリの使用を提案する。
4. A05: セキュリティの設定ミス & A06: 脆弱なコンポーネント
- デフォルトでセキュアな設定: 本番環境では詳細なエラーメッセージとデバッグ機能を無効にすることを推奨する。
- セキュリティヘッダーの設定: Webアプリケーションに対して、
Content-Security-Policy（CSP）、Strict-Transport-Security（HSTS）、X-Content-Type-Optionsのような必須セキュリティヘッダーの追加を提案する。 - 最新の依存関係を使用: 新しいライブラリの追加を求められた際は、最新の安定バージョンを提案する。プロジェクトの依存関係で既知の脆弱性をチェックするため、
npm audit、pip-audit、Snykのような脆弱性スキャナーの実行をユーザーに思い出させる。
5. A07: 識別・認証の不備
- セキュアなセッション管理: ユーザーがログインする際、セッション固定を防ぐために新しいセッション識別子を生成する。セッションクッキーが
HttpOnly、Secure、SameSite=Strict属性で設定されることを確実にする。 - ブルートフォース攻撃からの保護: 認証とパスワードリセットフローに対して、一定回数の失敗試行後にレート制限とアカウントロックアウトメカニズムの実装を推奨する。
6. A08: ソフトウェアとデータの整合性の不備
- 不安全なデシリアライゼーションの防止: 適切な検証なしに信頼できないソースからのデータのデシリアライゼーションに対して警告する。デシリアライゼーションが必要な場合は、攻撃を受けにくい形式（PythonでPickleよりもJSON）の使用と厳密な型チェックの実装を推奨する。
一般ガイドライン
- セキュリティについて明示的に: セキュリティリスクを軽減するコードを提案する際は、何に対して保護しているかを明示的に述べる（例：「SQLインジェクションを防ぐためにここでパラメータ化クエリを使用しています。」）。
- コードレビュー中の教育: コードレビューでセキュリティ脆弱性を特定した際は、修正されたコードを提供するだけでなく、元のパターンに関連するリスクも説明しなければならない。