CWE-798|Hardcoded Data ハードコードされた認証情報の使用
CWE-798 Hardcoded Sensitive Dataにおける一般的なパターン・漏洩データ類型
以下が、ハードコードされやすい情報の主な類型や一般的なパターンです。
分類 | よく漏洩する情報例 | 主なリスク・影響 |
---|---|---|
認証情報 (Credentials) | ユーザー名、パスワード、Basic認証情報、アクセスキー・シークレットキー | 不正アクセス、アカウントの乗っ取り、機密情報漏洩 |
APIキー (API Keys) | Google API、Firebase、AWS API、マップAPI等 | 外部サービスの悪用、課金被害、データの改ざん |
トークン (Tokens) | JWTトークン、OAuthトークン、SDKトークン(AppsFlyer, REPRO等) | 認証突破、不正トラッキング、ユーザー情報漏洩 |
データベース情報 | DB接続文字列、DBユーザー名・パスワード | データベースへの不正アクセス、情報流出、データ改ざん |
バックエンドサービスのURL | Firebase URL、管理画面URL、APIのエンドポイント | インフラへの直接攻撃、データ漏洩の足掛かり |
暗号化関連情報 | 暗号化キー、秘密鍵、証明書 | 暗号化された情報の解読、データ盗難 |
分析・マーケティング情報 | 分析SDKのキー、広告ID、ユーザー分析ツールのID | 分析データの漏洩・改ざん、プライバシー侵害 |
📝 一般的なハードコードのパターン
以下のようなケースでハードコードが多発します。
- 開発環境から本番環境へコード移行する際、テスト用の情報を削除し忘れる。
- コードや設定ファイルに認証情報を直接書き込んでしまう。
- 環境変数や安全な保管場所を使わず、開発の利便性を優先してコードに情報を記載する。
- GitHubなどのリポジトリでうっかり機密情報をcommit/pushしてしまい、そのままアプリ公開される。
🚩 対策としてのベストプラクティス
- 認証情報・キーは環境変数や安全なVault(HashiCorp Vault, AWS Secrets Managerなど)で管理する。
- GitHubリポジトリなどでシークレット検出ツールを使い、commit時に自動検出する。
- アプリ公開前にコードレビューを徹底し、機密情報が含まれないか確認する。
まとめ
- CWE-798は固定のCVSSスコアを持たず、個々の脆弱性の状況に応じてスコア算出される。
- ハードコードされやすい情報は主に認証情報、APIキー、トークン、データベース情報、分析関連情報であり、漏洩すると極めて深刻なセキュリティリスクを生じるため、厳密な管理が必要です。