セキュア開発基礎論

概要

セキュア開発は、単に脆弱性の「修正」ではなく、設計・実装・運用のすべての段階で脅威の構造を理解し、それを防ぐ設計思想を組み込む活動である。本章では、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) などの遅延でブール値推測

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モデル（要約）

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

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 フォールトトレランスの目的

システムやサービスの稼働中に障害が発生しても、機能を継続させることを目的とする設計思想。
高可用性（High Availability, HA）やビジネス継続計画（BCP）と密接に関連。

5.2 冗長化の設計パターン

種類	説明	代表例
ハードウェア冗長化	サーバやネットワーク機器の二重化・多重化	クラスタリング、RAID
ソフトウェア冗長化	アプリケーションレイヤでの障害回避	アクティブ/スタンバイ、ロードバランサ
データ冗長化	データベースやストレージの複製	レプリケーション、分散ストレージ
ネットワーク冗長化	通信経路やISPの冗長化	冗長回線、マルチホーミング

5.3 障害検知と自動復旧

監視・アラート：Prometheus, Grafana, Zabbixなどを活用
自動フェイルオーバー：
- 主要ノードが停止 → 予備ノードに自動切替
- アプリケーションレベルではリトライやバックオフ戦略
自己修復（Self-Healing）：
- コンテナ・クラウド環境で自動再デプロイ
- Infrastructure as Codeで迅速復旧

5.4 障害対応プロセス

検知：監視ツール・ログ解析で異常を特定
影響範囲特定：どのサービス・ユーザに影響かを評価
封じ込め・切替：冗長化機能を使い影響範囲を最小化
復旧：障害原因修正・サービス復旧
事後評価：障害原因、再発防止策、文書化

5.5 セキュア開発との接続

フォールトトレランス設計は単なる可用性確保ではなく、セキュリティと一体で考える必要がある。
- 例：障害発生時に認証・権限チェックがバイパスされないよう設計
- 例：自動復旧プロセスが秘密情報や設定ファイルを漏洩させないよう制御
DevSecOpsの観点では、CI/CDパイプラインやIaCも冗長性・監視・自己修復機能を組み込み、セキュリティと可用性を統合することが推奨される。

5.6 耐障害設計の設計パラダイム

用語	概要	実務例
フェールセーフ（Fail-Safe）	障害が発生した場合でも、安全な状態にシステムを移行させる設計思想	電子レンジのドアセンサーが故障しても加熱が停止する、航空機の自動操縦が異常時に安全運転に切替
フールプルーフ（Foolproof）	ユーザや運用者の誤操作に対して、システムが安全に振る舞うよう設計する思想	ATMで誤操作しても現金が多く出ない、削除ボタンに確認ダイアログを設置
フェールソフト（Fail-Soft）	障害が発生してもシステム全体を停止させず、機能の一部を制限して継続運用する設計思想	Webサービスの一部機能が障害時に停止しても、ログインや閲覧は継続、クラウドサービスで一部リージョンが落ちても残りは稼働

基礎知識チェック

設問 - Level 1

セキュア開発において、脆弱性の修正だけでなく、より根本的に重要な活動は何ですか？
XSS（クロスサイトスクリプティング）の本質は何ですか？
SQLインジェクション攻撃を防ぐための最も基本的な防御技術は何ですか？
CSRF（クロスサイトリクエストフォージェリ）攻撃の本質を簡潔に説明してください。
セッション固定攻撃を防ぐための対策として、ログイン後に行うべきことは何ですか？
パスワードリスト攻撃やブルートフォース攻撃に対する防御技術の一つとして、レートリミット以外に挙げられるものは何ですか？
Webアプリケーションの脆弱性の根本原因として、「入力検証不足」と「出力処理の甘さ」以外に主要なものを一つ挙げてください。
マイクロソフトSDLモデルにおいて、設計段階で行うセキュリティ活動として挙げられているものは何ですか？
DevSecOpsのCIパイプラインで実行されるセキュリティ自動化スキャンの一つを挙げてください。
サプライチェーン攻撃の対策として、生成・管理が推奨されるものは何ですか？
FIDO2/WebAuthnのようなパスワードレス認証技術が解決しようとしているパスワード認証の根本的な課題は何ですか？

設問 - Level 2

XSSの主要な3つの分類（Stored, Reflected, DOM-based）について、それぞれの特徴と攻撃が成立するメカニズムを簡潔に説明してください。
プリペアドステートメントがSQLインジェクション攻撃に有効な理由を、その仕組みと関連付けて説明してください。
CSRF攻撃に対する防御策として、CSRFトークンの利用とSameSite属性付きCookieの設定があります。これらの対策は、それぞれどのような仕組みで攻撃を防ぐのか、役割の違いを説明してください。
セッション管理の不備によって引き起こされる「セッションハイジャック」と「セッション固定攻撃」の違い、およびそれぞれの主要な対策を説明してください。
パスワード関連の攻撃（パスワードリスト攻撃、ブルートフォース、辞書攻撃）に対して、動的レートリミット、アカウントロック、CAPTCHA以外に推奨されるパスワードの安全な保存方法と、その理由を説明してください。
OWASP SAMMはマイクロソフトSDLモデルと比較して、どのような開発アプローチに対応し、どのような特徴を持つモデルとして位置づけられますか？
DevSecOpsにおけるSAST、DAST、SCAのそれぞれの役割と、セキュリティ自動化パイプラインにおける実行タイミングの違いを説明してください。
サプライチェーン攻撃の具体例として、「依存ライブラリの汚染」と「Typo-squatting」を挙げ、それぞれどのような手口か説明してください。
ソフトウェア署名と整合性保証が、サプライチェーン攻撃への対策としてどのように機能するか、具体例（Cosign, Sigstoreなど）を交えて説明してください。
機械学習サービスへの攻撃のうち、「入力摂動による誤分類（Adversarial Example）」とは具体的にどのような攻撃か、その仕組みを簡潔に説明してください。
Secure属性、HttpOnly属性、SameSite属性はCookieのセキュリティを高めるために重要です。それぞれの属性がCookieのどのような脆弱性を軽減するか説明してください。
セキュア開発ライフサイクルにおいて、「脅威モデリング」が設計段階でどのような役割を果たすか、その目的と得られる効果について説明してください。

回答 - Level 1

設計・実装・運用のすべての段階で脅威の構造を理解し、それを防ぐ設計思想を組み込む活動。
信頼境界外（ユーザー入力）からのHTML/JS文脈への出力（リフレクション）。
プリペアドステートメント。
被害者のブラウザが保持する認証情報を悪用して意図しないリクエストを送信させること。
セッションIDの再発行。
アカウントロック、CAPTCHA、遅延応答、パスワード強度検証、ソルト付きハッシュ。
認証認可の設計ミス、セッション管理の甘さ。
脅威モデリング。
SAST（静的アプリケーションセキュリティテスト）、SBOM生成、コンテナ脆弱性スキャン。
SBOM（Software Bill of Materials：ソフトウェア部品表）。
パスワードの漏洩、再利用、フィッシングといったパスワード依存による限界。

回答 - Level 2

Stored XSS: 攻撃スクリプトがデータベースなどに保存され、後で他のユーザーがそのデータにアクセスした際に実行される。Reflected XSS: ユーザーの入力（URLのクエリ文字列など）が悪意のあるスクリプトとして即座にWebページに出力され、そのユーザーのブラウザで実行される。DOM-based XSS: サーバー側の処理を経由せず、クライアントサイドのJavaScriptによって動的に構築されるDOMが、ユーザー入力によって汚染され、スクリプトが実行される。
プリペアドステートメントは、SQLクエリの「構文」と「データ」を完全に分離してデータベースに渡す仕組みです。プレースホルダを用いることで、ユーザー入力がデータとしてのみ扱われ、SQL構文の一部として解釈されることがないため、悪意のあるSQLコードが挿入されてもクエリの構造が破壊されるのを防ぎ、SQLインジェクションを根本的に防ぎます。
CSRFトークン: ユーザーがサイトにアクセスした際に、予測困難なランダムな文字列（トークン）をサーバーが生成し、Webページ内のフォームなどに埋め込みます。リクエスト送信時にはこのトークンも一緒に送信され、サーバー側で以前生成したものと一致するかを検証することで、正規ユーザーからのリクエストであることを確認し、意図しないリクエストを防ぎます。SameSite属性付きCookie: ブラウザがCookieを送信する条件を制御します。Strictは、同じサイトからのリクエスト以外ではCookieを送信せず、Laxはトップレベルのナビゲーション（GETリクエスト）の場合に限り送信します。これにより、クロスサイトからのリクエスト時にセッションCookieが自動的に送信されるのを防ぎ、CSRF攻撃を軽減します。
セッションハイジャック: 攻撃者が正規ユーザーの有効なセッションIDを何らかの方法で盗み出し、そのセッションIDを使って正規ユーザーになりすましてアクセスする攻撃。対策はCookieのHttpOnly/Secure/SameSite属性設定、セッションIDの高強度ランダム化。セッション固定攻撃: 攻撃者が**あらかじめ正規ユーザーにセッションIDを強制的に割り当て（固定化）**し、その後正規ユーザーがそのセッションIDでログインすると、攻撃者がそのセッションIDを使って正規ユーザーになりすます攻撃。対策は、ログイン後にセッションIDを再発行すること。
ハッシュ関数とソルトを組み合わせた方式、特にPBKDF2、bcrypt、Argon2のような計算コストの高い鍵導出関数（KDF）の使用が推奨されます。これは、パスワードを平文で保存する代わりに、ソルト（ランダムな値）と組み合わせてハッシュ化することで、たとえハッシュ値が漏洩しても元のパスワードの特定を困難にするためです。計算コストが高いKDFは、ブルートフォース攻撃や辞書攻撃を遅延させる効果があります。
OWASP SAMM（Software Assurance Maturity Model）は、マイクロソフトSDLがウォーターフォール開発モデルを強く意識しているのに対し、**アジャイル開発や継続的インテグレーション/デリバリー（CI/CD）**といったモダンな開発アプローチにも対応しやすいように設計されています。SAMMは、セキュリティ活動を「ガバナンス」「設計」「実装」「検証」「運用」の5つのビジネス機能に分類し、それぞれを「成熟度レベル」で定量化することで、組織のセキュリティ成熟度を測り、段階的に改善していく継続的なアプローチを重視します。
SAST (Static Application Security Testing): ソースコードやバイナリを実行せずに静的に解析し、脆弱性を特定します。主に開発の早期段階（Git Commit/CIパイプラインの初期）で実行され、コーディング上のミスや潜在的な脆弱性パターンを検出します。DAST (Dynamic Application Security Testing): 稼働中のアプリケーションに対して実際にアクセスし、動的にテストして脆弱性を検出します。主にCDパイプラインのデプロイ前や運用環境で実行され、外部から見たアプリケーションの脆弱性を検出します。SCA (Software Composition Analysis): 依存しているオープンソースコンポーネントやライブラリに既知の脆弱性がないかをスキャンします。CIパイプラインの中で実行され、SBOM生成と合わせてソフトウェアサプライチェーンの安全性を確保します。
依存ライブラリの汚染: 開発者が利用するオープンソースライブラリやパッケージの公式リポジトリや配布経路が攻撃者によって不正に改ざんされ、悪意のあるコードが注入されたバージョンが配布される手口です。開発者は意図せず脆弱なライブラリを組み込んでしまいます。Typo-squatting: 有名なライブラリ名に似た（スペルミスや紛らわしい名前の）偽のライブラリを作成し、開発者が誤ってそれをインストールするように誘導する手口です。偽ライブラリには悪意のあるコードが含まれています。
ソフトウェア署名と整合性保証は、ソフトウェアが正規の供給元によって作成・リリースされ、かつ改ざんされていないことを保証します。例えば、CosignやSigstoreはコンテナイメージなどのデジタル署名を生成・検証するためのツールやフレームワークです。これにより、開発者がイメージをビルドする際に署名を付与し、そのイメージをデプロイする側は署名を検証することで、サプライチェーンの途中で改ざんされた悪意のあるイメージがシステムに導入されるのを防ぎます。Provenance（由来証明）情報も合わせて検証することで、ビルドプロセスそのものの信頼性も確認できます。
「入力摂動による誤分類（Adversarial Example）」とは、機械学習モデルの予測を誤らせることを目的として、入力データに人間には知覚できないような微小な変更（摂動）を加える攻撃です。例えば、画像認識モデルに対し、わずかにノイズを加えた画像を提示することで、モデルがその画像を全く別の物体として誤認識するように仕向けることができます。これにより、自動運転車の標識認識を誤らせるなどの深刻な問題につながる可能性があります。
Secure属性: この属性を持つCookieは、HTTPS接続でのみサーバーに送信されます。これにより、HTTP接続で傍受されるリスクを軽減し、Cookieの機密性を保護します。HttpOnly属性: JavaScriptなどのクライアントサイドスクリプトからCookieにアクセスするのを禁止します。これにより、XSS攻撃によってCookieが窃取されるリスクを大幅に軽減します。SameSite属性: クロスサイトリクエスト時にCookieが送信される条件を制御します。LaxやStrictを設定することで、CSRF攻撃によって意図しないリクエストと共にセッションCookieが送信されるのを防ぎます。
「脅威モデリング」は、設計段階でシステムを構成する要素（データ、プロセス、コンポーネントなど）を洗い出し、それらの間に存在するデータの流れや信頼境界を可視化することで、潜在的な脅威や脆弱性を特定し、適切な対策を設計に組み込む活動です。目的は、開発ライフサイクルの早期にセキュリティリスクを特定し、手戻りの少ない効率的な対策を講じること。これにより、設計段階でセキュリティ要件を明確にし、より堅牢なシステムを構築することができます。
フォールトトレランス設計において、フェールセーフ、フールプルーフ、フェールソフトを適用する場合の具体的な設計判断の例を挙げ、それぞれの違いを説明してください。

概要

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

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

攻撃例（DOM-based XSS）：

防御技術：

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

攻撃例（Blind SQLi）：

防御技術：

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

攻撃例：

防御技術：

1.4 セッション管理の不備

防御技術：

1.5 パスワード関連の攻撃

防御技術：

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

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

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

3.2 OWASP SAMMとの比較

4. DevSecOpsの実践

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

4.2 活用技術

5. 耐障害設計（フォールトトレランス）

5.1 フォールトトレランスの目的

5.2 冗長化の設計パターン

5.3 障害検知と自動復旧

5.4 障害対応プロセス

5.5 セキュア開発との接続

5.6 耐障害設計の設計パラダイム

基礎知識チェック

設問 - Level 1

設問 - Level 2

回答 - Level 1

回答 - Level 2