理Kotowary

Webの中のセキュリティ — コードを書くときに守ること

大人こども
初級中級上級

概要 — まず全体をつかむ

中級では「境界で防ぐ」を軸に整理しました。上級では、脅威モデリングと多層の作り込みへ。

詳細 — 1段階ずつ追う

脅威モデリングから始める

「何を、誰から、どう守るか」を先に設計します。

  • STRIDE — なりすまし・改ざん・否認・情報漏洩・DoS・権限昇格の観点で洗い出す
  • 信頼境界の明示 — 図に境界を引き、越える所すべてで検証・認可
  • 多層防御 — 予防・検知・対応を層で重ねる
やさしく言うと（中級）

多くのWeb脆弱性は「信頼できない入力が、ある境界を越えて悪さをする」構図です。だから対策も境界ごとに決まります。

  • ブラウザへ出す境界 → 出力エスケープ（XSS対策）
  • DBへ渡す境界 → パラメータ化（SQLインジェクション対策）
  • 他サイトからの操作の境界 → トークン／SameSite（CSRF対策）
  • コードと秘密の境界 → シークレット管理（秘密情報の隔離）

登場人物メモ:

  • ※1 信頼境界 — 信用できる領域と、できない領域の境目
  • ※2 多層防御 — 対策を重ね、1つ破られても次で止める
アニメーション『信頼境界（外は信用しない）』を開く
信頼境界 — 外は信用せず、越える所に関所を置く境界をまたぐ所で必ず「検証・認証・エンコード」する信頼できる内側自分が管理する領域アプリのロジックデータベース秘密情報（鍵・パスワード）信用しない外側利用者・他システム信頼境界利用者の入力フォーム・URL・API🛡 入力検証型・範囲・許可リスト他システム・外部API呼び出し元は名乗るだけ🛡 認証・認可誰か・権限があるか利用者のブラウザ画面に値を表示🛡 出力エンコード文脈に応じてエスケープ外から来たものは信用しない。境界を越える所で検証・認証・エンコードして内側を守る

守りの層（作り込み）

  1. 入力 — 検証＋正規化（Unicodeの見た目差、二重デコード）
  2. 出力 — 文脈別エスケープ＋CSP／SRI
  3. 認証・認可 — 中央化、最小権限
  4. 暗号 — TLS＋保存時暗号、鍵管理
  5. 依存 — SCA／SBOMでサプライチェーンを管理
  6. 監視 — 監査ログ、異常検知、改ざん検知
やさしく言うと（中級）
  1. 入力検証 — 型・範囲・許可リストで、想定外を弾く（土台）
  2. XSS — 出力を文脈に応じてエスケープ、CSP でスクリプト実行を制限。なぜ効くか＝出力文脈（HTML属性・JS・URL）ごとに変換規則が違い、文脈に合った変換で初めて無害化されるため
  3. CSRF — CSRFトークン＋SameSite Cookie。SameSite は「クロスサイトからの Cookie 自動送信を抑制」することで、他サイト起点のなりすまし操作を成立させにくくする
  4. SQLインジェクション — プレースホルダ（パラメータ化クエリ）。なぜ効くか＝命令（SQL文）とデータ（入力値）を分離し、入力を文字列連結でSQLに混ぜないため
  5. 秘密管理 — 環境変数・シークレットマネージャ、鍵のローテーション
  6. その他 — アクセス制御（認可）、依存ライブラリの更新、監査ログ

運用まで含めた守り

  • セキュリティヘッダ — CSP・HSTS・SRI・SameSite・X-Content-Type-Options
  • サプライチェーン攻撃 — 依存やビルドパイプラインの汚染に注意
  • シークレット — 集中管理＋ローテーション＋最小配布
  • セキュアSDLC（シフトレフト） — 設計・CI・レビューにセキュリティを組み込む
やさしく言うと（中級）
  • 既定は拒否 — 許可リスト方式（deny by default）
  • 依存の管理 — 使っているライブラリの既知の脆弱性を放置しない
  • 運用・監視 — 攻撃に気づける状態を保つ（運用の全体像は Webのセキュリティ（全体像））
  • 代表的な指標 — OWASP Top 10 のような整理を出発点にする

⚠️ 現実の破れ方

  • OWASP Top 10 — アクセス制御不備・インジェクション・設定ミスが上位常連
  • 設定ミス — 公開設定・デフォルト資格情報・冗長な権限
  • 依存の穴 — 既知脆弱性の放置
  • CSPバイパス — 緩い設定や信頼した出所の悪用
  • ログの不足／改ざん — 攻撃に気づけない・追えない
やさしく言うと（中級）
  • 境界の取り違え — フロントで検証したから安全、と誤解（サーバで必ず再検証）
  • 単一対策依存 — WAFだけ・エスケープだけに頼る
  • 設定・依存の放置 — 公開設定ミス、古いライブラリの穴

理解度チェック

そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

問1. ブラウザに「読み込んでよいスクリプトの出所」を制限させ、XSSの被害を抑えるヘッダは？

問2. 使っているライブラリの既知脆弱性を機械的に洗い出す取り組みは？

問3. 脅威モデリングの観点「STRIDE」に含まれないものはどれ？

問4. 本文が挙げる、認証・認可の作り込みの原則の組み合わせとして正しいのは？

問5. 本文がいう「多層防御」で、層として重ねる3つはどれ？

問6. 入力の「正規化」で本文が特に警戒しているのはどれ？

問7. アプリが使っている依存（部品）を一覧化した「部品表」を英字4文字の略語で答えてください。

問8. 設計やCI、レビューといった早い工程からセキュリティを組み込む考え方を、カタカナで（「〜レフト」）答えてください。