セキュア開発基礎論

Aug 4, 2025 10 min

概要

セキュア開発は、単に脆弱性の「修正」ではなく、設計・実装・運用のすべての段階で脅威の構造を理解し、それを防ぐ設計思想を組み込む活動である。本章では、Webアプリケーションに代表されるソフトウェア開発において頻出するセキュリティ脆弱性、開発プロセスへのセキュリティ統合、最新のDevSecOps実践、および新興脅威への対応までを体系的に解説する。

1. Webアプリケーションの主要脆弱性

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

  • 本質：信頼境界外（ユーザー入力）からのHTML/JS文脈への出力（リフレクション）
  • 分類：
    • Stored XSS：データベースなどに蓄積された悪性スクリプトが後で反映される
    • Reflected XSS：クエリ文字列やフォーム入力が即時的に出力される
    • DOM-based XSS：JavaScriptによって動的に構築されるDOMが汚染される

攻撃例（DOM-based XSS）：

<script>
  const q = location.hash.substring(1); // #alert(1)
  document.getElementById('output').innerHTML = q;
</script>

防御技術：

  • 出力エスケープ（HTML／JS／CSS文脈ごとのエンコーディング）
  • CSP（Content Security Policy）：
    • default-src 'self'; script-src 'self'; object-src 'none';
    • unsafe-inline 使用は原則非推奨（CSPバイパスの温床）
  • ライブラリの活用：DOMPurify、OWASP Encoder等

1.2 SQLインジェクション（SQLi）

  • 本質：クエリ構築にユーザー入力をそのまま結合し、構文を破壊・乗っ取る
  • 高度化形態：
    • Blind SQLi：エラーメッセージ非表示環境でも、応答差異で情報収集
    • Time-based SQLi：SLEEP(5) などの遅延でブール値推測

攻撃例（Blind SQLi）：

SELECT * FROM users WHERE id = '1' AND SUBSTRING(password,1,1) = 'a'

防御技術：

  • プリペアドステートメント：プレースホルダで構文とデータを分離
  • WAF／RASPによる構文異常検出
  • エラーメッセージの非表示

1.3 CSRF（クロスサイトリクエストフォージェリ）

  • 本質：被害者のブラウザが保持する認証情報を悪用して意図しないリクエストを送信させる

攻撃例：

<img src="https://target.example.com/transfer?amount=10000&to=attacker">

防御技術：

  • CSRFトークンの埋め込みと照合（Double Submit Tokenなど）
  • SameSite属性付きCookie：
    • Strict：クロスドメインリクエストでは一切送信されない
    • Lax：GETに限り送信される（安全なデフォルト）
    • None：送信されるが Secure 属性が必須

1.4 セッション管理の不備

  • 本質：セッショントークンの予測性・漏洩・盗用により、正規ユーザになりすまされる

防御技術：

  • セッションIDに高強度ランダム値使用
  • Cookieに HttpOnly / Secure / SameSite を正しく付与
  • セッション固定攻撃への対策：ログイン後にセッションIDを再発行

1.5 パスワード関連の攻撃

  • パスワードリスト攻撃／クレデンシャルスタッフィング
  • ブルートフォース
  • 辞書攻撃

防御技術：

  • 動的レートリミット（IPベース + ユーザベース）
  • アカウントロック／CAPTCHA／遅延応答
  • パスワード強度検証 + ソルト付きハッシュ（bcrypt, Argon2）

2. 脆弱性の根本原因と設計上の配慮

原因分類具体例設計原則
入力検証不足フォーム、URLパラメータ、Cookie入力境界明示 + Allowリスト設計
出力処理の甘さinnerHTML, eval, document.write文脈別エスケープ + DOM操作制限
認証認可の設計ミス管理者権限漏れ、IDOR最小権限・ゼロトラスト
セッション管理の甘さトークン固定、Cookie誤設定ID再発行、TTL制限、非永続Cookie

3. セキュア開発ライフサイクル（SDL）

3.1 マイクロソフトSDLモデル（要約）

  1. トレーニングの実施
  2. 要件定義時のセキュリティ要件記述
  3. 設計時の脅威モデリング
  4. コーディング時のセキュアコーディング標準
  5. テスト時の静的解析・動的解析・Fuzzing
  6. リリース判定にセキュリティレビューを含める
  7. 運用フェーズでの脆弱性対応プロセス設計

3.2 OWASP SAMMとの比較

  • SDL：ウォーターフォール志向、重厚だが明確
  • SAMM：アジャイル対応重視、各活動を定量化して継続改善

4. DevSecOpsの実践

4.1 セキュリティ自動化パイプライン構成

Git Commit
   ↓
Pre-Commit Hook（lint/secret scan）
   ↓
CI（SAST／SBOM生成／コンテナ脆弱性スキャン）
   ↓
CD（脆弱性の重大度評価→デプロイ判定）

4.2 活用技術

  • SAST：Semgrep, SonarQube
  • DAST：OWASP ZAP, Burp Suite
  • SCA：Syft, Trivy, Dependabot
  • IaCスキャン：tfsec, Checkov
  • 署名とサプライチェーン：Sigstore, Cosign, SLSAフレームワーク

5. 最新脅威と対応技術

5.1 サプライチェーン攻撃

  • 依存ライブラリの汚染、Typo-squatting、ソフトウェア署名の偽装
  • 対策：
    • SBOMの生成・管理
    • サードパーティ評価ポリシー
    • Provenance（由来証明）の強制

5.2 ソフトウェア署名と整合性保証

  • コード署名（例：JAR、EXE、コンテナイメージ）
  • Cosign, Sigstore Fulcio/Rekor による透明性ログベースの署名

5.3 機械学習サービスへの攻撃（Adversarial ML）

  • 入力摂動による誤分類
  • モデル抽出／逆コンパイル
  • 対策：勾配マスキング、差分プライバシ、推論API制限

まとめ：セキュア開発に必要な視点

  • 「脆弱性 = 実装ミス」ではなく、「設計判断の失敗」であることを意識する
  • 自動化と文化浸透の両面からの「DevSecOpsによる全社展開」が実効性を持つ
  • 脅威モデリングとリスクベースアプローチを開発初期から取り込むべし

試験対策ポイント

  • XSS／SQLi／CSRFの具体的構造と防御策
  • JWTの構造・署名検証・スコープ管理
  • SDLとDevSecOpsの違い・適用フェーズ
  • SBOM／SLSA／Sigstoreといった最新技術動向
  • 脆弱性の分類と入力→出力→認可の流れの全体把握

~Yu Tokunaga