セキュリティ監査

OWASP Top 10 — Webセキュリティの必修科目

OWASP（Open Web Application Security Project）が発表するTop 10は、Webアプリケーションに対する最も重要なセキュリティリスクのリストです。

佐久間: 「OWASP Top 10は、Webセキュリティの”教科書の目次”みたいなもの。これを知らないのは、医者が人体の臓器を知らないのと同じだ。」

OWASP Top 10（2021年版）

A01: アクセス制御の不備

最も多い脆弱性。認可チェックが不十分で、本来アクセスできないデータや機能にアクセスできてしまう。

// 脆弱: ユーザーIDだけでデータを取得（所有権チェックなし）
app.get('/api/user/:id', async (req, res) => {
  const user = await prisma.user.findUnique({ where: { id: req.params.id } });
  res.json(user); // 他人のデータも見えてしまう
});

// 安全: ログインユーザーと一致するか確認
app.get('/api/user/:id', authMiddleware, async (req, res) => {
  if (req.user.id !== req.params.id && req.user.role !== 'admin') {
    return res.status(403).json({ error: 'アクセス権限がありません' });
  }
  const user = await prisma.user.findUnique({ where: { id: req.params.id } });
  res.json(user);
});

A05: セキュリティの設定ミス

デフォルト設定、不要な機能の有効化、不適切なエラー処理などが原因。

// よくある設定ミス

// 1. デバッグモードが本番で有効
app.set('env', 'development'); // 本番では 'production'

// 2. 不要なHTTPヘッダーの露出
// X-Powered-By: Express → サーバー技術が分かる
app.disable('x-powered-by'); // または helmet() を使う

// 3. ディレクトリリスティングが有効
app.use(express.static('public', { dotfiles: 'deny' }));

// 4. CORSが全開放
app.use(cors()); // → すべてのオリジンからアクセス可能

// 正しいCORS設定
app.use(cors({
  origin: ['https://shimalink.com'],
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  credentials: true
}));

A06: 脆弱で古いコンポーネント

使用しているライブラリに既知の脆弱性がある場合。

# 脆弱性チェック
npm audit

# 結果例:
# found 3 vulnerabilities (1 low, 1 moderate, 1 high)

# 自動修正
npm audit fix

# 破壊的変更を含む修正
npm audit fix --force  # 注意: テストを必ず実行すること

佐久間: 「依存ライブラリの脆弱性は”時限爆弾”みたいなもの。定期的にチェックして、問題があればすぐに更新する。」

A09: セキュリティログと監視の失敗

攻撃が起きても気づけなければ、被害は拡大する一方です。

// 記録すべきイベント
const securityEvents = {
  LOGIN_SUCCESS: 'ログイン成功',
  LOGIN_FAILURE: 'ログイン失敗',
  ACCESS_DENIED: 'アクセス拒否',
  DATA_EXPORT: 'データエクスポート',
  ADMIN_ACTION: '管理者操作',
  SUSPICIOUS_INPUT: '不審な入力検知'
};

function logSecurityEvent(event, details) {
  console.log(JSON.stringify({
    timestamp: new Date().toISOString(),
    event: event,
    ip: details.ip,
    userId: details.userId,
    details: details.message
  }));
}

ポイント

• OWASP Top 10はWebセキュリティの基本知識として必須
• アクセス制御の不備（A01）が最も多い脆弱性
• 設定ミス、古いライブラリ、ログ不足も重大なリスク
• 定期的にnpm auditでライブラリの脆弱性をチェックする

セキュリティチェックリスト

体系的にセキュリティを検証するためのチェックリストを作成します。佐久間さんが実際の監査で使っている項目に基づいています。

佐久間: 「チェックリストがあれば、“確認し忘れ”がなくなる。パイロットが離陸前に必ずチェックリストを確認するのと同じだよ。」

認証・認可チェックリスト

## 認証（Authentication）
- [ ] パスワードはbcrypt/Argon2でハッシュ化して保存している
- [ ] パスワードポリシーがある（8文字以上、複雑性要件）
- [ ] ログイン失敗時のレート制限がある（5回失敗でロック等）
- [ ] セッションIDは十分にランダムで推測不能
- [ ] ログアウト時にセッションを確実に無効化している
- [ ] 「パスワードを忘れた」機能が安全に実装されている
- [ ] パスワードリセットトークンは一度限り、有効期限付き

## 認可（Authorization）
- [ ] すべてのAPIエンドポイントで認可チェックを行っている
- [ ] ユーザーは自分のデータにのみアクセスできる
- [ ] 管理者機能は管理者のみアクセス可能
- [ ] IDの書き換え（IDOR）で他人のデータにアクセスできない
- [ ] 水平権限昇格（同レベルの他ユーザーのデータ）を防いでいる
- [ ] 垂直権限昇格（管理者権限の取得）を防いでいる

入力・出力チェックリスト

## 入力検証
- [ ] すべてのユーザー入力をサーバー側で検証している
- [ ] SQLクエリはパラメータ化/ORMを使用している
- [ ] ファイルアップロードの種類・サイズを制限している
- [ ] URLリダイレクトのホワイトリスト検証をしている

## 出力エスケープ
- [ ] HTMLコンテキストでエスケープしている
- [ ] JavaScriptコンテキストでエスケープしている
- [ ] URLパラメータをエンコードしている
- [ ] CSPヘッダーを設定している

通信・データ保護チェックリスト

## 通信
- [ ] すべてのページでHTTPSを強制している
- [ ] HSTSヘッダーを設定している
- [ ] TLS 1.2以上を使用している
- [ ] HTTPからHTTPSへリダイレクトしている

## データ保護
- [ ] 機密データは保存時に暗号化している
- [ ] バックアップも暗号化している
- [ ] 不要になったデータは安全に削除している
- [ ] ログに機密情報（パスワード、トークン）を記録していない

セキュリティヘッダーチェックリスト

## HTTPセキュリティヘッダー
- [ ] Content-Security-Policy
- [ ] X-Content-Type-Options: nosniff
- [ ] X-Frame-Options: DENY（またはSAMEORIGIN）
- [ ] X-XSS-Protection: 0（CSPがあればこちらは無効化推奨）
- [ ] Strict-Transport-Security
- [ ] Referrer-Policy: strict-origin-when-cross-origin

// helmetで一括設定
const helmet = require('helmet');
app.use(helmet());
// これだけで多くのセキュリティヘッダーが設定される

CSRF対策チェックリスト

## CSRF（Cross-Site Request Forgery）
- [ ] 状態変更リクエスト（POST/PUT/DELETE）にCSRFトークンを使用
- [ ] CSRFトークンはリクエストごとに検証
- [ ] SameSite Cookie属性を設定している

// CSRFトークンの実装例
const csrf = require('csurf');
app.use(csrf({ cookie: true }));

// フォームにトークンを埋め込む
app.get('/form', (req, res) => {
  res.render('form', { csrfToken: req.csrfToken() });
});

佐久間さんがShimaLinkで見つけた3つの問題

1. IDORの脆弱性
   /api/shops/123 → 他人のショップ情報を編集できた
   → 所有者チェックの追加で修正

2. レート制限の欠如
   ログインAPIに回数制限なし → ブルートフォース可能
   → express-rate-limitの導入で修正

3. CORS設定の不備
   すべてのオリジンからのアクセスを許可していた
   → ホワイトリスト方式に変更

ポイント

• チェックリストを使えば確認漏れを防げる
• 認証、認可、入出力、通信、ヘッダーを体系的に確認する
• 自分では見つけにくい脆弱性があるため、第三者の目が重要
• helmetライブラリでセキュリティヘッダーを一括設定できる

ペネトレーションテストの基本

ペネトレーションテスト（ペンテスト）は、実際の攻撃者と同じ手法でシステムの脆弱性を発見するテスト手法です。

佐久間: 「泥棒を捕まえるには、泥棒の考え方を知る必要がある。ペンテストは”合法的な泥棒”のようなものだ。」

ペネトレーションテストとは

重要: 許可なく他人のシステムをテストすることは犯罪（不正アクセス禁止法違反）です。

ペンテストの種類

佐久間さんがShimaLinkに対して行ったのはグレーボックステストです。

ペンテストの5つのフェーズ

Phase 1: 偵察（Reconnaissance）

ターゲットの情報を収集する。

# 公開情報の収集（OSINTの例）

# DNSレコードの確認
dig shimalink.com ANY

# サブドメインの列挙
# admin.shimalink.com, api.shimalink.com などが見つかるかも

# 使用技術の特定（レスポンスヘッダーから）
curl -I https://shimalink.com
# → Server: nginx, X-Powered-By: Express

Phase 2: スキャン（Scanning）

脆弱性スキャナーで自動チェック。

# OWASP ZAP（無料のWebアプリスキャナー）
# GUIツールでURLを入力するだけで自動スキャン

# Nikto（Webサーバースキャナー）
nikto -h https://shimalink.com

# npm audit（依存ライブラリの脆弱性）
npm audit

Phase 3: 脆弱性の検証（Exploitation）

発見した脆弱性が実際に悪用可能か確認する。

例: IDORの検証
1. 自分のショップページ: /api/shops/123 → 200 OK
2. 他人のショップページ: /api/shops/456 → 200 OK!?
   → アクセスできてしまう = 脆弱性確認

Phase 4: アクセスの維持と深掘り

一つの脆弱性から、どこまでアクセスを拡大できるか確認する。

Phase 5: レポート作成

発見した脆弱性、影響度、再現手順、修正推奨事項をレポートにまとめる。

開発者ができる簡易セキュリティテスト

専門家に頼む前に、自分たちでできる基本的なテスト。

## 簡易セキュリティテスト手順

1. 認証テスト
   - [ ] ログインせずにAPIにアクセスしてみる
   - [ ] 期限切れのトークンでアクセスしてみる

2. 認可テスト
   - [ ] 他のユーザーのIDでAPIにアクセスしてみる
   - [ ] 一般ユーザーで管理者APIにアクセスしてみる

3. 入力テスト
   - [ ] 各フォームにXSSペイロードを入力してみる
   - [ ] 長い文字列（10000文字）を入力してみる
   - [ ] 特殊文字（<>"';&|）を入力してみる

4. 設定テスト
   - [ ] HTTPでアクセスしたらHTTPSにリダイレクトされるか
   - [ ] セキュリティヘッダーが返されているか
   - [ ] エラーページに内部情報が含まれていないか

ツール紹介

佐久間: 「ツールは便利だけど、万能じゃない。ビジネスロジックの脆弱性はツールでは見つけられない。人間の判断力が不可欠だ。」

ポイント

• ペンテストは許可を得た上で行う「合法的な攻撃テスト」
• 偵察→スキャン→検証→深掘り→レポートの5フェーズ
• 開発者でも簡易テストは実施できる
• ツールと人間の判断力の両方が必要

インシデント対応計画

セキュリティ事故は「起きるかどうか」ではなく「いつ起きるか」の問題です。事前に対応計画を策定しておくことで、被害を最小限に抑えられます。

佐久間: 「消防署は火事が起きてから避難計画を考えない。事前に計画があるから、迅速に対応できるんだ。」

インシデント対応の4フェーズ

Phase 1: 準備（Preparation）
    ↓
Phase 2: 検知と分析（Detection & Analysis）
    ↓
Phase 3: 封じ込め・根絶・復旧（Containment, Eradication, Recovery）
    ↓
Phase 4: 事後対応（Post-Incident Activity）

Phase 1: 準備

事故が起きる前に体制を整えます。

## インシデント対応チーム（IRT）

| 役割 | 担当 | 責任 |
|------|------|------|
| インシデントマネージャー | Yuki | 全体指揮、意思決定 |
| 技術リード | あなた | 技術調査、修正実装 |
| コミュニケーション | あなた | ユーザー・外部への通知 |
| ログ分析 | あなた | ログ調査、証拠保全 |

## 連絡先リスト
- チーム: Slackチャンネル #security-incident
- サーバー管理: [クラウドプロバイダー]
- 法務: [顧問弁護士]
- 監督機関: 個人情報保護委員会（必要に応じて）

Phase 2: 検知と分析

異常を素早く検知し、影響範囲を特定します。

// アラート設定の例
const alertConditions = {
  // 短時間での大量ログイン失敗
  bruteForce: {
    condition: 'loginFailures > 10 in 5min from same IP',
    severity: 'high',
    action: 'IP一時ブロック + アラート送信'
  },
  // 大量のデータアクセス
  dataExfiltration: {
    condition: 'API responses > 1000 in 10min from same user',
    severity: 'critical',
    action: 'セッション無効化 + アラート送信'
  },
  // 管理者APIへの不正アクセス試行
  adminAccess: {
    condition: 'non-admin user accessing /admin/*',
    severity: 'high',
    action: 'ログ記録 + アラート送信'
  }
};

影響度の分類

Phase 3: 封じ込め・根絶・復旧

封じ込め（Containment）

被害の拡大を止めます。

# 即座の対応例

# 1. 攻撃元IPのブロック
iptables -A INPUT -s 攻撃者IP -j DROP

# 2. 侵害されたアカウントの無効化
# DBで直接セッションを無効化

# 3. サービスのメンテナンスモード切り替え
# → ユーザーへの影響を最小限に

根絶（Eradication）

脆弱性そのものを修正します。

- 脆弱性の特定と修正パッチの作成
- バックドアやマルウェアの除去
- 侵害された認証情報のリセット
- 関連するすべてのシステムの確認

復旧（Recovery）

サービスを安全に復旧します。

1. 修正パッチの適用とテスト
2. 段階的なサービス復旧
3. 監視の強化（再発がないか確認）
4. 影響を受けたユーザーへの通知

Phase 4: 事後対応（ポストモーテム）

同じ事故を繰り返さないために振り返りを行います。

## インシデント振り返りテンプレート

### 概要
- 発生日時:
- 検知日時:
- 復旧日時:
- 影響範囲:

### タイムライン
- 02:00 異常なアクセスを検知
- 02:15 チームに通知
- 02:30 メンテナンスモードに切り替え
- 03:00 攻撃経路を特定
- ...

### 根本原因
[何が原因だったか]

### うまくいったこと
- ログ監視が機能し、早期に検知できた
- チームの連携がスムーズだった

### 改善すべきこと
- 入力検証が不十分だった
- インシデント対応手順が文書化されていなかった

### アクションアイテム
- [ ] [担当者] XSSサニタイズの強化（期限: 3/20）
- [ ] [担当者] インシデント対応手順書の作成（期限: 3/25）
- [ ] [担当者] セキュリティ研修の実施（期限: 4/1）

佐久間: 「ポストモーテムは”犯人探し”じゃない。“システム改善”のためにやるんだ。誰かを責めるんじゃなく、プロセスを改善する。」

ShimaLinkのインシデント対応計画

# ShimaLink インシデント対応計画 v1.0

## 1. 検知
- サーバーログの24時間監視
- 異常アクセスの自動アラート（Slack #security-alert）
- npm auditの週次自動実行

## 2. 初動対応（30分以内）
- インシデントマネージャーへの連絡
- 影響範囲の初期評価
- 必要に応じてメンテナンスモード切り替え

## 3. 通知
- 影響を受けたユーザーへの通知（24時間以内）
- 個人情報漏洩の場合、監督機関への報告（72時間以内）

## 4. 復旧後
- ポストモーテムの実施（7日以内）
- 再発防止策の実装
- lessons.mdへの教訓記録

ポイント

• インシデント対応は「事前に計画しておく」ことが最重要
• 準備→検知→封じ込め→事後対応の4フェーズ
• ポストモーテムは犯人探しではなくプロセス改善のため
• 対応計画は定期的に見直し、訓練する

[ShimaLink セキュリティ監査レポート]
─────────────────────────────
監査日: 2024年4月
監査者: 佐久間セキュリティコンサルティング

総合評価: 合格（修正後）

対応済み:
  ✓ XSS対策（入力サニタイズ + CSP）
  ✓ SQLインジェクション対策（パラメータ化クエリ + ORM）
  ✓ パスワードハッシュ化（bcrypt）
  ✓ HTTPS強制（TLS 1.3 + HSTS）
  ✓ CSRF対策トークン導入
  ✓ レート制限実装
  ✓ エラーメッセージの情報漏洩修正
  ✓ インシデント対応計画策定

推奨事項:
  - 定期的なペネトレーションテスト（年2回）
  - 依存ライブラリの自動脆弱性スキャン
  - セキュリティ研修の継続
─────────────────────────────