nrslib 102f31447a refactor: rename faceted to facets across package layout

2026-02-22 02:40:33 +09:00

7.3 KiB

Raw Permalink Blame History

セキュリティ知識

AI生成コードのセキュリティ問題

AI生成コードには特有の脆弱性パターンがある。

パターン	リスク	例
もっともらしいが危険なデフォルト	高	`cors: { origin: '*' }` は問題なく見えるが危険
古いセキュリティプラクティス	中	非推奨の暗号化、古い認証パターンの使用
不完全なバリデーション	高	形式は検証するがビジネスルールを検証しない
入力を過度に信頼	重大	内部APIは常に安全と仮定
コピペによる脆弱性	高	同じ危険なパターンが複数ファイルで繰り返される

特に厳しく審査が必要:

認証・認可ロジック（AIはエッジケースを見落としがち）
入力バリデーション（AIは構文を検証しても意味を見落とす可能性）
エラーメッセージ（AIは内部詳細を露出する可能性）
設定ファイル（AIは学習データから危険なデフォルトを使う可能性）

インジェクション攻撃

SQLインジェクション

文字列連結によるSQL構築 → REJECT
パラメータ化クエリの不使用 → REJECT
ORMの raw query での未サニタイズ入力 → REJECT

// NG
db.query(`SELECT * FROM users WHERE id = ${userId}`)

// OK
db.query('SELECT * FROM users WHERE id = ?', [userId])

コマンドインジェクション

exec(), spawn() での未検証入力 → REJECT
シェルコマンド構築時のエスケープ不足 → REJECT

// NG
exec(`ls ${userInput}`)

// OK
execFile('ls', [sanitizedInput])

XSS (Cross-Site Scripting)

HTML/JSへの未エスケープ出力 → REJECT
innerHTML, dangerouslySetInnerHTML の不適切な使用 → REJECT
URLパラメータの直接埋め込み → REJECT

認証・認可

認証の問題

ハードコードされたクレデンシャル → 即REJECT
平文パスワードの保存 → 即REJECT
弱いハッシュアルゴリズム (MD5, SHA1) → REJECT
セッショントークンの不適切な管理 → REJECT

認可の問題

権限チェックの欠如 → REJECT
IDOR (Insecure Direct Object Reference) → REJECT
権限昇格の可能性 → REJECT

// NG - 権限チェックなし
app.get('/user/:id', (req, res) => {
  return db.getUser(req.params.id)
})

// OK
app.get('/user/:id', authorize('read:user'), (req, res) => {
  if (req.user.id !== req.params.id && !req.user.isAdmin) {
    return res.status(403).send('Forbidden')
  }
  return db.getUser(req.params.id)
})

データ保護

機密情報の露出

APIキー、シークレットのハードコーディング → 即REJECT
ログへの機密情報出力 → REJECT
エラーメッセージでの内部情報露出 → REJECT
.env ファイルのコミット → REJECT

データ検証

入力値の未検証 → REJECT
型チェックの欠如 → REJECT
サイズ制限の未設定 → REJECT

暗号化

弱い暗号アルゴリズムの使用 → REJECT
固定IV/Nonceの使用 → REJECT
暗号化キーのハードコーディング → 即REJECT
HTTPSの未使用（本番環境） → REJECT

ファイル操作

パストラバーサル

ユーザー入力を含むファイルパス → REJECT
../ のサニタイズ不足 → REJECT

// NG
const filePath = path.join(baseDir, userInput)
fs.readFile(filePath)

// OK
const safePath = path.resolve(baseDir, userInput)
if (!safePath.startsWith(path.resolve(baseDir))) {
  throw new Error('Invalid path')
}

ファイルアップロード

ファイルタイプの未検証 → REJECT
ファイルサイズ制限なし → REJECT
実行可能ファイルのアップロード許可 → REJECT

依存関係

既知の脆弱性を持つパッケージ → REJECT
メンテナンスされていないパッケージ → 警告
不必要な依存関係 → 警告

エラーハンドリング

スタックトレースの本番露出 → REJECT
詳細なエラーメッセージの露出 → REJECT
エラーの握りつぶし（セキュリティイベント） → REJECT

レート制限・DoS対策

レート制限の欠如（認証エンドポイント） → 警告
リソース枯渇攻撃の可能性 → 警告
無限ループの可能性 → REJECT

マルチテナントデータ分離

テナント境界を超えたデータアクセスを防ぐ。認可（誰が操作できるか）とスコーピング（どのテナントのデータか）は別の関心事。

基準	判定
読み取りはテナントスコープだが書き込みはスコープなし	REJECT
書き込み操作でクライアント提供のテナントIDを使用	REJECT
テナントリゾルバーを使うエンドポイントに認可制御がない	REJECT
ロール分岐の一部パスでテナント解決が未考慮	REJECT

読み書きの一貫性

テナントスコーピングは読み取りと書き込みの両方に適用する。片方だけでは、参照できないが変更できる状態が生まれる。

読み取りにテナントフィルタを追加したら、対応する書き込みも必ずテナント検証する。

書き込みのテナント検証

書き込み操作では、リクエストボディのテナントIDではなく認証済みユーザーから解決したテナントIDを使う。

// NG - クライアント提供のテナントIDを信頼
fun create(request: CreateRequest) {
    service.create(request.tenantId, request.data)
}

// OK - 認証情報からテナントを解決
fun create(request: CreateRequest) {
    val tenantId = tenantResolver.resolve()
    service.create(tenantId, request.data)
}

認可とリゾルバーの整合性

テナントリゾルバーが特定ロール（例: スタッフ）を前提とする場合、エンドポイントに対応する認可制御が必要。認可なしだと、前提外のロールがアクセスしてリゾルバーが失敗する。

// NG - リゾルバーが STAFF を前提とするが認可制御なし
fun getSettings(): SettingsResponse {
    val tenantId = tenantResolver.resolve()  // STAFF 以外で失敗
    return settingsService.getByTenant(tenantId)
}

// OK - 認可制御でロールを保証
@Authorized(roles = ["STAFF"])
fun getSettings(): SettingsResponse {
    val tenantId = tenantResolver.resolve()
    return settingsService.getByTenant(tenantId)
}

ロール分岐があるエンドポイントでは、全パスでテナント解決が成功するか検証する。

OWASP Top 10 チェックリスト

カテゴリ	確認事項
A01 Broken Access Control	認可チェック、CORS設定
A02 Cryptographic Failures	暗号化、機密データ保護
A03 Injection	SQL, コマンド, XSS
A04 Insecure Design	セキュリティ設計パターン
A05 Security Misconfiguration	デフォルト設定、不要な機能
A06 Vulnerable Components	依存関係の脆弱性
A07 Auth Failures	認証メカニズム
A08 Software Integrity	コード署名、CI/CD
A09 Logging Failures	セキュリティログ
A10 SSRF	サーバーサイドリクエスト

7.3 KiB Raw Permalink Blame History Unescape Escape