SQLインジェクション脆弱性を修正してセキュリティを強化した話

概要

フルテキスト検索機能の実装中に発見したSQLインジェクション脆弱性を、Prismaのパラメータ化クエリに移行することで修正しました。本記事では、$queryRawUnsafeの危険性と、セキュアなクエリ実装のベストプラクティス、さらにエラーハンドリングの改善について解説します。

技術スタック

• Prisma ORM (v5.x)
• TypeScript (v5.x)
• PostgreSQL (v14+)
• Node.js (v20 LTS)
• セキュリティツール: OWASP ZAP, Snyk

背景・課題

脆弱性の発見

フルテキスト検索機能を実装した際、初期実装では$queryRawUnsafeを使用していました：

// 🔴 脆弱なコード（改善前）
export async function findManyWithFullTextSearch(params: {
  keywords: string[];
  // ...
}) {
  const searchQuery = keywords.join(' & ');

  // ユーザー入力が直接クエリに埋め込まれている！
  const results = await prisma.$queryRawUnsafe(`
    SELECT e.*
    FROM emails e
    WHERE e.search_vector @@ websearch_to_tsquery('simple', '${searchQuery}')
    ORDER BY ts_rank(e.search_vector, websearch_to_tsquery('simple', '${searchQuery}')) DESC
    LIMIT ${take} OFFSET ${skip}
  `);

  return results;
}

問題点

1. SQLインジェクションのリスク

   • ユーザー入力が適切にエスケープされていない
   • 悪意のある入力でデータベースを操作される可能性

2. tsquery構文エラーでアプリケーション停止

   • 特殊文字（', &, |など）を含む検索でエラー
   • エラーハンドリングが不足

3. セキュリティレビューで指摘

   • $queryRawUnsafeの使用は推奨されない
   • Prismaの型安全性の恩恵を受けられない

具体的な攻撃例

悪意のあるユーザーが以下のような検索を実行した場合：

// 攻撃例
const maliciousInput = "'; DROP TABLE emails; --";
// 生成されるSQL:
// WHERE e.search_vector @@ websearch_to_tsquery('simple', ''; DROP TABLE emails; --')

幸い、PostgreSQLの権限設定で実際の被害は防げていましたが、根本的な対策が必要でした。

解決方法

1. Prisma.sqlパラメータ化クエリへの移行

$queryRawUnsafeからPrisma.sqlを使用したパラメータ化クエリに変更しました：

// ✅ セキュアなコード（改善後）
import { Prisma } from '@prisma/client';

export async function findManyWithFullTextSearch(params: {
  keywords: string[];
  accountId: string;
  category?: string;
  skip?: number;
  take?: number;
}) {
  const { keywords, accountId, category, skip = 0, take = 50 } = params;

  // キーワードをAND結合（Prismaが自動的にエスケープ）
  const searchQuery = keywords.join(' & ');

  try {
    const results = await prisma.$queryRaw`
      SELECT e.*
      FROM emails e
      WHERE e.search_vector @@ websearch_to_tsquery('simple', ${searchQuery})
        AND e."accountId" = ${accountId}
        ${category ? Prisma.sql`AND EXISTS (
          SELECT 1 FROM "EmailClassificationResult" ecr
          WHERE ecr."emailId" = e.id AND ecr.category = ${category}
          LIMIT 1
        )` : Prisma.empty}
      ORDER BY ts_rank(e.search_vector, websearch_to_tsquery('simple', ${searchQuery})) DESC
      LIMIT ${take} OFFSET ${skip}
    `;

    return results;
  } catch (error) {
    // エラーハンドリング（後述）
    console.error('Full-text search error:', error);
    return [];
  }
}

重要なポイント:

• テンプレートリテラル構文（Prisma.sql`...`）を使用
• パラメータは${}で埋め込み、Prismaが自動エスケープ
• 条件分岐にはPrisma.emptyを活用

2. tsquery構文エラーのハンドリング

PostgreSQLのtsquery構文エラー（エラーコード42601）を適切にキャッチ：

export async function findManyWithFullTextSearch(params: SearchParams) {
  try {
    const results = await prisma.$queryRaw`
      SELECT e.*
      FROM emails e
      WHERE e.search_vector @@ websearch_to_tsquery('simple', ${searchQuery})
      -- ...
    `;

    return results as Email[];
  } catch (error) {
    // PostgreSQL構文エラーの場合は空配列を返す
    if (error instanceof Error && 'code' in error && error.code === '42601') {
      console.warn('Invalid tsquery syntax, returning empty results:', searchQuery);
      return [];
    }

    // その他のエラーは再スロー
    throw error;
  }
}

エラーハンドリングの方針:

• 構文エラー: 空配列を返してアプリケーション継続
• その他のエラー: 再スローして上位で処理
• ログ出力で問題の追跡を可能に

3. bodyTextの文字数制限

tsvectorのサイズ制限（1MB）を超えないよう、本文を10,000文字に制限：

// マイグレーション
CREATE OR REPLACE FUNCTION update_search_vector()
RETURNS trigger AS $$
BEGIN
  NEW.search_vector :=
    setweight(to_tsvector('simple', COALESCE(NEW.subject, '')), 'A') ||
    setweight(to_tsvector('simple', COALESCE(NEW."fromName", '')), 'B') ||
    setweight(to_tsvector('simple', COALESCE(NEW."fromAddress", '')), 'C') ||
    setweight(to_tsvector('simple',
      LEFT(COALESCE(NEW."bodyText", ''), 10000)), 'D');  -- ← 10,000文字制限
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

4. バックフィルスクリプトの安全化

既存データの更新処理もCTE（Common Table Expression）を使用して安全化：

async function backfillSearchVector() {
  const BATCH_SIZE = 1000;
  const totalCount = await prisma.email.count();
  let processedCount = 0;

  console.log(`Starting backfill for ${totalCount} emails...`);

  for (let offset = 0; offset < totalCount; offset += BATCH_SIZE) {
    try {
      // CTEを使用した安全な一括更新
      const result = await prisma.$executeRaw`
        WITH batch AS (
          SELECT id, subject, "fromName", "fromAddress",
                 LEFT("bodyText", 10000) as truncated_body
          FROM emails
          ORDER BY id
          LIMIT ${BATCH_SIZE} OFFSET ${offset}
        )
        UPDATE emails
        SET search_vector =
          setweight(to_tsvector('simple', COALESCE(batch.subject, '')), 'A') ||
          setweight(to_tsvector('simple', COALESCE(batch."fromName", '')), 'B') ||
          setweight(to_tsvector('simple', COALESCE(batch."fromAddress", '')), 'C') ||
          setweight(to_tsvector('simple', COALESCE(batch.truncated_body, '')), 'D')
        FROM batch
        WHERE emails.id = batch.id
      `;

      processedCount += result;
      console.log(`Progress: ${processedCount}/${totalCount} (${Math.round(processedCount/totalCount * 100)}%)`);
    } catch (error) {
      console.error(`Error processing batch at offset ${offset}:`, error);
      // エラーが発生しても処理を継続
    }
  }

  console.log(`Backfill completed: ${processedCount} emails processed`);
}

技術的な詳細

Prisma.sqlの安全性の仕組み

Prisma.sqlは内部的に以下の処理を行います：

1. パラメータのエスケープ処理

   // ユーザー入力
   const input = "'; DROP TABLE emails; --";
   
   // Prismaによる処理
   // → パラメータとして安全にバインディング
   // → SQLインジェクションは不可能
   

2. 型安全性の保証

   // TypeScriptの型チェックが効く
   const accountId: string = "acc_123";
   const take: number = 50;
   
   // 型が合わない場合はコンパイルエラー
   // 例：以下はコンパイルエラーになる
   const invalidTake: string = "50";
   await prisma.$queryRaw`
     SELECT * FROM emails
     LIMIT ${invalidTake}  // Error: Type 'string' is not assignable to type 'number'
   `;
   

3. PreparedStatementの使用

   • データベースレベルでのパラメータバインディング
   • SQLパースと実行の分離
   • 実行計画のキャッシュによるパフォーマンス向上

$queryRawUnsafe vs Prisma.sql

項目	$queryRawUnsafe	Prisma.sql
セキュリティ	❌ 脆弱性リスク	✅ 安全
型安全性	❌ なし	✅ あり
パフォーマンス	同等	同等〜やや高速※
PreparedStatement	❌ なし	✅ あり
使用場面	非推奨	推奨

※PreparedStatementのキャッシュにより、繰り返し実行時にパフォーマンス向上

パフォーマンスベンチマーク

実際の環境でのベンチマーク結果：

// ベンチマークコード
import { performance } from 'perf_hooks';

async function benchmark() {
  const iterations = 1000;
  const keywords = ['typescript', 'react', 'nextjs'];

  // $queryRawUnsafe（非推奨）
  const unsafeStart = performance.now();
  for (let i = 0; i < iterations; i++) {
    await prisma.$queryRawUnsafe(
      `SELECT * FROM emails WHERE subject LIKE '%${keywords[0]}%' LIMIT 10`
    );
  }
  const unsafeTime = performance.now() - unsafeStart;

  // Prisma.sql（推奨）
  const safeStart = performance.now();
  for (let i = 0; i < iterations; i++) {
    await prisma.$queryRaw`
      SELECT * FROM emails WHERE subject LIKE ${`%${keywords[0]}%`} LIMIT 10
    `;
  }
  const safeTime = performance.now() - safeStart;

  console.log('Results:');
  console.log(`$queryRawUnsafe: ${unsafeTime.toFixed(2)}ms`);
  console.log(`Prisma.sql: ${safeTime.toFixed(2)}ms`);
  console.log(`Performance improvement: ${((unsafeTime - safeTime) / unsafeTime * 100).toFixed(2)}%`);
}

結果（10万レコードのテーブルで実測）:

$queryRawUnsafe: 3245.67ms
Prisma.sql: 2987.34ms
Performance improvement: 7.96%

PreparedStatementのキャッシュにより、約8%のパフォーマンス向上が確認されました。

条件分岐の実装パターン

Prisma.sqlでの動的クエリ構築にはPrisma.emptyが便利です：

// パターン1: 単純な条件分岐
const query = Prisma.sql`
  SELECT * FROM emails
  WHERE accountId = ${accId}
  ${category ? Prisma.sql`AND category = ${category}` : Prisma.empty}
`;

// パターン2: 複雑な条件分岐
const conditions = [];
if (category) {
  conditions.push(Prisma.sql`category = ${category}`);
}
if (minAge) {
  conditions.push(Prisma.sql`age >= ${minAge}`);
}

const query = Prisma.sql`
  SELECT * FROM users
  WHERE ${Prisma.join(conditions, ' AND ')}
`;

運用上の注意点

監査ログの実装

セキュリティインシデントの追跡のため、監査ログの実装が重要です：

import winston from 'winston';

// 監査ログ用のロガー設定
const auditLogger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json()
  ),
  transports: [
    new winston.transports.File({ filename: 'audit.log' }),
    // 本番環境ではCloudWatch等のログサービスに送信
  ]
});

// セキュリティイベントのログ記録
export async function logSecurityEvent(event: {
  type: 'SQL_INJECTION_ATTEMPT' | 'INVALID_QUERY' | 'UNAUTHORIZED_ACCESS';
  userId?: string;
  query?: string;
  ip?: string;
  details?: any;
}) {
  auditLogger.warn('Security Event', {
    ...event,
    timestamp: new Date().toISOString(),
    environment: process.env.NODE_ENV
  });

  // 重大なイベントの場合はアラート送信
  if (event.type === 'SQL_INJECTION_ATTEMPT') {
    await sendSecurityAlert(event);
  }
}

// 使用例
export async function findManyWithFullTextSearch(params: SearchParams) {
  const { keywords, accountId } = params;

  // 疑わしいパターンの検出
  const suspiciousPatterns = [
    /(\-\-|\/\*|\*\/|xp_|sp_|exec|execute|drop|create|alter|insert|update|delete)/i,
    /'.*or.*'='|".*or.*"="/i
  ];

  if (suspiciousPatterns.some(pattern => pattern.test(keywords.join(' ')))) {
    await logSecurityEvent({
      type: 'SQL_INJECTION_ATTEMPT',
      userId: accountId,
      query: keywords.join(' '),
      ip: req?.ip
    });
  }

  // 以下、通常の処理...
}

CSPヘッダーの設定

Content Security Policy（CSP）ヘッダーで追加の保護層を提供：

// Next.js の場合（next.config.js）
module.exports = {
  async headers() {
    return [
      {
        source: '/:path*',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: [
              "default-src 'self'",
              "script-src 'self' 'unsafe-inline' 'unsafe-eval'",
              "style-src 'self' 'unsafe-inline'",
              "img-src 'self' data: https:",
              "font-src 'self' data:",
              "connect-src 'self'",
              "frame-ancestors 'none'",
              "base-uri 'self'",
              "form-action 'self'"
            ].join('; ')
          },
          {
            key: 'X-Frame-Options',
            value: 'DENY'
          },
          {
            key: 'X-Content-Type-Options',
            value: 'nosniff'
          },
          {
            key: 'X-XSS-Protection',
            value: '1; mode=block'
          }
        ]
      }
    ];
  }
};

セキュリティスキャンの自動化

CI/CDパイプラインにセキュリティチェックを組み込み：

# .github/workflows/security.yml
name: Security Scan

on:
  pull_request:
  push:
    branches: [main]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Run Snyk Security Scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

      - name: Run SQLMap Test (staging only)
        if: github.ref == 'refs/heads/staging'
        run: |
          # SQLMapを使用した自動テスト
          sqlmap -u "https://staging.example.com/api/search?q=test" \
                 --batch --level=2 --risk=2 \
                 --output-dir=./sqlmap-results

      - name: Check for hardcoded credentials
        run: |
          npx secretlint "**/*"

テスト戦略

ユニットテストの実装

セキュリティ関連のユニットテストを追加：

// __tests__/security.test.ts
import { describe, it, expect, vi, beforeEach } from 'vitest';
import { findManyWithFullTextSearch } from '../search';
import { prisma } from '../prisma';

describe('SQL Injection Prevention', () => {
  beforeEach(() => {
    vi.clearAllMocks();
  });

  it('should safely handle SQL injection attempts', async () => {
    const maliciousInputs = [
      "'; DROP TABLE emails; --",
      "1' OR '1'='1",
      "admin'--",
      "' OR 1=1--",
      "'; DELETE FROM emails WHERE '1'='1"
    ];

    for (const input of maliciousInputs) {
      // Prisma.sqlがエスケープ処理することを確認
      const spy = vi.spyOn(prisma, '$queryRaw');

      await findManyWithFullTextSearch({
        keywords: [input],
        accountId: 'test_account'
      });

      // パラメータがバインドされていることを確認
      expect(spy).toHaveBeenCalled();
      const call = spy.mock.calls[0];

      // Prisma.Sql オブジェクトであることを確認
      expect(call[0]).toHaveProperty('sql');
      expect(call[0]).toHaveProperty('values');

      // SQLインジェクションが無効化されていることを確認
      expect(call[0].sql).not.toContain('DROP TABLE');
      expect(call[0].sql).not.toContain('DELETE FROM');
    }
  });

  it('should handle special characters in search queries', async () => {
    const specialCharInputs = [
      "test's",
      'test"quote',
      'test & test',
      'test | test',
      'test\\backslash'
    ];

    for (const input of specialCharInputs) {
      // エラーなく処理できることを確認
      await expect(
        findManyWithFullTextSearch({
          keywords: [input],
          accountId: 'test_account'
        })
      ).resolves.not.toThrow();
    }
  });

  it('should validate input types', async () => {
    // 型チェックのテスト
    const invalidParams = {
      keywords: ['test'],
      accountId: 'test_account',
      take: 'not-a-number', // 型エラー
      skip: '0' // 型エラー
    };

    // TypeScriptの型エラーをシミュレート
    // @ts-expect-error - 意図的な型エラー
    const result = await findManyWithFullTextSearch(invalidParams);

    // 実行時エラーが発生しないことを確認
    expect(result).toBeDefined();
  });
});

describe('Error Handling', () => {
  it('should return empty array on tsquery syntax error', async () => {
    // PostgreSQL構文エラーをシミュレート
    vi.spyOn(prisma, '$queryRaw').mockRejectedValueOnce(
      Object.assign(new Error('syntax error in tsquery'), {
        code: '42601'
      })
    );

    const result = await findManyWithFullTextSearch({
      keywords: ['invalid::syntax'],
      accountId: 'test_account'
    });

    expect(result).toEqual([]);
  });

  it('should log security events', async () => {
    const logSpy = vi.spyOn(console, 'warn');

    await findManyWithFullTextSearch({
      keywords: ["'; DROP TABLE emails; --"],
      accountId: 'test_account'
    });

    // セキュリティイベントがログに記録されることを確認
    expect(logSpy).toHaveBeenCalledWith(
      expect.stringContaining('Security Event')
    );
  });
});

統合テストの実装

// __tests__/integration/search.test.ts
import { describe, it, expect, beforeAll, afterAll } from 'vitest';
import { createTestDatabase, destroyTestDatabase } from '../test-utils';

describe('Full-text Search Integration', () => {
  let testDb: any;

  beforeAll(async () => {
    testDb = await createTestDatabase();

    // テストデータの投入
    await testDb.email.createMany({
      data: [
        { subject: 'TypeScript tutorial', bodyText: 'Learn TypeScript...' },
        { subject: 'React hooks guide', bodyText: 'Understanding hooks...' },
        { subject: 'Next.js best practices', bodyText: 'Server components...' }
      ]
    });
  });

  afterAll(async () => {
    await destroyTestDatabase(testDb);
  });

  it('should perform secure full-text search', async () => {
    const results = await findManyWithFullTextSearch({
      keywords: ['TypeScript'],
      accountId: 'test_account'
    });

    expect(results).toHaveLength(1);
    expect(results[0].subject).toContain('TypeScript');
  });

  it('should handle concurrent searches safely', async () => {
    // 並行処理のテスト
    const promises = Array.from({ length: 100 }, (_, i) =>
      findManyWithFullTextSearch({
        keywords: [`test${i}`],
        accountId: 'test_account'
      })
    );

    await expect(Promise.all(promises)).resolves.not.toThrow();
  });
});

トラブルシューティング

よくある問題と解決策

1. "ERROR: syntax error in tsquery" が発生する

症状: 特殊文字を含む検索クエリでエラーが発生

原因: PostgreSQLのtsquery構文で予約されている文字の使用

解決策:

// 特殊文字をエスケープする関数を実装
function escapeSpecialChars(query: string): string {
  // tsqueryの特殊文字をエスケープ
  return query
    .replace(/[&|!()':*]/g, ' ')  // 特殊文字を空白に置換
    .replace(/\s+/g, ' ')          // 連続する空白を1つに
    .trim();
}

// 使用例
const safeQuery = escapeSpecialChars(userInput);
const searchQuery = keywords.map(escapeSpecialChars).join(' & ');

2. パフォーマンスが低下する

症状: 大量のデータで検索が遅い

原因: インデックスが効いていない、または不適切なクエリ

解決策:

-- インデックスの確認
SELECT indexname, indexdef
FROM pg_indexes
WHERE tablename = 'emails';

-- 実行計画の確認
EXPLAIN ANALYZE
SELECT * FROM emails
WHERE search_vector @@ websearch_to_tsquery('simple', 'test');

-- 必要に応じてインデックスを再構築
REINDEX INDEX idx_emails_search_vector;

3. メモリ使用量が増加する

症状: 長時間稼働後にメモリ使用量が増加

原因: Prisma接続プールのリーク

解決策:

// 接続プールの監視
setInterval(async () => {
  const metrics = await prisma.$metrics.json();
  console.log('Connection pool metrics:', {
    activeConnections: metrics.counters.find(
      m => m.key === 'prisma_pool_connections_open'
    )?.value,
    idleConnections: metrics.counters.find(
      m => m.key === 'prisma_pool_connections_idle'
    )?.value
  });

  // 閾値を超えたら警告
  if (metrics.counters[0].value > 50) {
    console.warn('High connection count detected');
  }
}, 60000);

4. デプロイ後に接続エラーが発生する

症状: "Can't reach database server" エラー

解決策:

// リトライロジックの実装
async function executeWithRetry<T>(
  fn: () => Promise<T>,
  maxRetries = 3,
  delay = 1000
): Promise<T> {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await fn();
    } catch (error) {
      if (i === maxRetries - 1) throw error;

      console.log(`Retry attempt ${i + 1}/${maxRetries}`);
      await new Promise(resolve => setTimeout(resolve, delay * (i + 1)));
    }
  }
  throw new Error('Max retries exceeded');
}

// 使用例
const results = await executeWithRetry(
  () => findManyWithFullTextSearch(params)
);

学んだこと

意外だった落とし穴

1. Prisma.sqlでもエラーハンドリングは必要

   • パラメータ化しても、PostgreSQL構文エラーは発生する
   • 特殊文字を含む検索クエリに注意

2. CTEの重要性

   • バッチ更新時の安全性向上
   • クエリプランナーによる最適化
   • 可読性の向上

3. 文字数制限の設計

   • tsvectorの1MB制限を考慮
   • 検索パフォーマンスとのトレードオフ

今後使えそうな知見

1. セキュアなクエリ実装のチェックリスト

   ✅ Prisma.sqlを使用
   ✅ すべてのユーザー入力をパラメータ化
   ✅ エラーハンドリングを実装
   ✅ ログ出力で問題を追跡可能に
   ✅ セキュリティレビューを実施
   

2. エラーハンドリングのベストプラクティス

   try {
     // データベース操作
   } catch (error) {
     // 1. エラーの種類を判定
     // 2. 適切な処理を選択（リトライ/空結果/再スロー）
     // 3. ログ出力
     // 4. ユーザーへのフィードバック
   }
   

3. 段階的な移行戦略

   ステップ1: 脆弱性の特定
   ステップ2: セキュアな実装への変更
   ステップ3: 既存データの安全化
   ステップ4: テストとレビュー
   ステップ5: デプロイと監視
   

もっと良い書き方の発見

改善前（文字列連結）:

const query = `
  SELECT * FROM emails
  WHERE accountId = '${accountId}'
  ${category ? `AND category = '${category}'` : ''}
`;
await prisma.$queryRawUnsafe(query);

改善後（パラメータ化）:

const query = Prisma.sql`
  SELECT * FROM emails
  WHERE accountId = ${accountId}
  ${category ? Prisma.sql`AND category = ${category}` : Prisma.empty}
`;
await prisma.$queryRaw(query);

終わりに

SQLインジェクション脆弱性は、古典的でありながら今でも重大なセキュリティリスクです。今回の修正では、以下のポイントが重要でした：

• Prismaのパラメータ化クエリ活用: 型安全性とセキュリティを両立
• 適切なエラーハンドリング: ユーザー体験を損なわない
• 段階的な移行: リスクを最小化

特に、ORMを使用していても、Raw SQLを書く際は細心の注意が必要です。Prismaの$queryRawUnsafeは便利ですが、セキュリティリスクを理解した上で、可能な限りPrisma.sqlを使用することをお勧めします。

読者の皆さんも、既存のコードに$queryRawUnsafeや文字列連結によるSQL構築がないか、一度チェックしてみてください。発見したら、早めに修正することをお勧めします。

---

この記事で紹介したコードは、実際のプロダクションコードを簡略化したものです。エラーハンドリングやセキュリティチェックなど、実際の実装では追加の考慮事項があります。

関連技術: Prisma ORM, PostgreSQL, TypeScript, SQLインジェクション対策, セキュリティ, エラーハンドリング, パラメータ化クエリ

筆者: 91works開発チーム