performing-security-headers-audit

セキュリティヘッダー監査の実施

使用するタイミング

• 標準的な設定レビューとして、許可を得たウェブアプリケーションのセキュリティ評価を行う場合
• XSS、クリックジャッキング、データ漏えいに対するブラウザレベルの保護を評価する場合
• セキュリティヘッダーの実装が求められるコンプライアンス評価（PCI DSS、SOC 2）を行う場合
• すぐに実施できる効果的なセキュリティ改善策を特定するため、初期偵察を行う場合
• 新しいデプロイに対する CI/CD パイプラインのセキュリティゲートチェックを行う場合

前提条件

• 許可：対象アプリケーションの書面によるスコープ（ヘッダーのレビューはリスクが低いです）
• curl：対象エンドポイントからレスポンスヘッダーを取得するために使用します
• SecurityHeaders.com：ヘッダーをすばやく評価するオンラインスキャナー
• Mozilla Observatory：Mozilla のウェブセキュリティテストツール
• Burp Suite：複数のページにわたる包括的なヘッダー分析に使用します
• ブラウザ DevTools：ヘッダーと CSP 違反をリアルタイムで調べるために使用します

ワークフロー

ステップ 1：対象からセキュリティヘッダーを収集する

セキュリティ関連のレスポンスヘッダーをすべて取得して、一覧にまとめます。

# Fetch all response headers
curl -s -I "https://target.example.com/" | grep -iE \
  "(strict-transport|content-security|x-frame|x-content-type|x-xss|referrer-policy|permissions-policy|feature-policy|x-permitted|cross-origin|set-cookie|server|x-powered-by|cache-control)"

# Check headers across multiple pages
PAGES=("/" "/login" "/api/health" "/admin" "/account/settings" "/static/app.js")

for page in "${PAGES[@]}"; do
  echo "=== $page ==="
  curl -s -I "https://target.example.com$page" 2>/dev/null | grep -iE \
    "(strict-transport|content-security|x-frame|x-content-type|x-xss|referrer-policy|permissions-policy|set-cookie|server|x-powered)"
  echo
done

# Check both HTTP and HTTPS responses
echo "=== HTTP Response ==="
curl -s -I "http://target.example.com/" | head -20
echo "=== HTTPS Response ==="
curl -s -I "https://target.example.com/" | head -20

ステップ 2：トランスポートセキュリティ（HSTS）を評価する

HTTP Strict Transport Security の設定を評価します。

# Check HSTS header
curl -s -I "https://target.example.com/" | grep -i "strict-transport-security"

# Expected: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# Verify HSTS attributes:
# max-age: Should be >= 31536000 (1 year) for preload eligibility
# includeSubDomains: Protects all subdomains
# preload: Eligible for browser HSTS preload list

# Check if HTTP redirects to HTTPS
curl -s -I "http://target.example.com/" | head -5
# Should be 301/302 redirect to https://

# Check if HSTS is on the preload list
# Visit: https://hstspreload.org/?domain=target.example.com

# Test for HTTPS-only cookies
curl -s -I "https://target.example.com/login" | grep -i "set-cookie"
# All session cookies should have Secure flag

# Check for mixed content
curl -s "https://target.example.com/" | grep -oP "http://[^\"']+" | head -20
# HTTP resources loaded on HTTPS pages create mixed content vulnerabilities

ステップ 3：Content Security Policy（CSP）を監査する

CSP ヘッダーの有効性と、潜在的なバイパスを分析します。

# Extract CSP header
CSP=$(curl -s -I "https://target.example.com/" | grep -i "content-security-policy" | cut -d: -f2-)
echo "$CSP"

# Check for dangerous directives:
# 'unsafe-inline' in script-src: Allows inline scripts (XSS risk)
# 'unsafe-eval' in script-src: Allows eval() (XSS risk)
# * in any directive: Allows loading from any origin
# data: in script-src: Allows data: URI scripts
# Missing default-src: No fallback policy

echo "$CSP" | tr ';' '\n' | while read directive; do
  echo "  $directive"
  if echo "$directive" | grep -q "unsafe-inline"; then
    echo "    WARNING: unsafe-inline allows inline script execution"
  fi
  if echo "$directive" | grep -q "unsafe-eval"; then
    echo "    WARNING: unsafe-eval allows eval() calls"
  fi
  if echo "$directive" | grep -q " \* "; then
    echo "    WARNING: wildcard allows loading from any origin"
  fi
done

# Check for CSP report-only (not enforcing)
curl -s -I "https://target.example.com/" | grep -i "content-security-policy-report-only"
# Report-only does NOT block violations, only logs them

# Test CSP with Google's evaluator
# https://csp-evaluator.withgoogle.com/
# Paste the CSP header for automated analysis

# Check for CSP bypass via whitelisted domains
# If CDN domains are whitelisted, check for JSONP endpoints or angular libraries

ステップ 4：フレーム保護とクリック対策ヘッダーを確認する

クリックジャッキング対策と iframe への埋め込み制御を検証します。

# X-Frame-Options
curl -s -I "https://target.example.com/" | grep -i "x-frame-options"
# Expected: DENY or SAMEORIGIN
# ALLOW-FROM is deprecated and not supported in modern browsers

# CSP frame-ancestors (supersedes X-Frame-Options)
curl -s -I "https://target.example.com/" | grep -i "content-security-policy" | grep -o "frame-ancestors[^;]*"
# Expected: frame-ancestors 'none' or frame-ancestors 'self'

# X-Content-Type-Options
curl -s -I "https://target.example.com/" | grep -i "x-content-type-options"
# Expected: nosniff (prevents MIME type sniffing)

# X-XSS-Protection (legacy, but still useful for older browsers)
curl -s -I "https://target.example.com/" | grep -i "x-xss-protection"
# Expected: 1; mode=block (or 0 if CSP is comprehensive)
# Note: Modern recommendation is 0 (disable) when CSP is present

# Referrer-Policy
curl -s -I "https://target.example.com/" | grep -i "referrer-policy"
# Expected: strict-origin-when-cross-origin or no-referrer
# Prevents sensitive URL data from leaking via Referer header

ステップ 5：Cookie のセキュリティ属性を監査する

セッション Cookie と認証 Cookie のセキュリティフラグを調べます。

# Fetch all Set-Cookie headers
curl -s -I -L "https://target.example.com/login" | grep -i "set-cookie"

# Check each cookie for required attributes:
# Secure: Only sent over HTTPS
# HttpOnly: Not accessible via JavaScript (prevents XSS cookie theft)
# SameSite: Controls cross-site cookie sending (Strict, Lax, None)
# Path: Restricts cookie scope
# Domain: Controls which domains receive the cookie
# Max-Age/Expires: Cookie lifetime

# Automated cookie check
curl -s -I "https://target.example.com/login" | grep -i "set-cookie" | while read line; do
  echo "Cookie: $(echo "$line" | grep -oP '[^:]+=[^;]+')"
  missing=""
  echo "$line" | grep -qi "secure" || missing="$missing Secure"
  echo "$line" | grep -qi "httponly" || missing="$missing HttpOnly"
  echo "$line" | grep -qi "samesite" || missing="$missing SameSite"
  if [ -n "$missing" ]; then
    echo "  MISSING:$missing"
  else
    echo "  All flags present"
  fi
done

# Check for __Host- and __Secure- cookie prefixes
# __Host- cookies must have Secure, Path=/, no Domain
# __Secure- cookies must have Secure flag

ステップ 6：Permissions Policy と情報開示を確認する

ブラウザー機能の制御と、情報漏えいにつながるヘッダーを確認します。

# Permissions-Policy (formerly Feature-Policy)
curl -s -I "https://target.example.com/" | grep -i "permissions-policy"
# Controls browser features: camera, microphone, geolocation, etc.
# Expected: Restrict unused features
# Example: permissions-policy: camera=(), microphone=(), geolocation=()

# Cross-Origin headers
curl -s -I "https://target.example.com/" | grep -iE "(cross-origin-embedder|cross-origin-opener|cross-origin-resource)"
# COEP: Cross-Origin-Embedder-Policy: require-corp
# COOP: Cross-Origin-Opener-Policy: same-origin
# CORP: Cross-Origin-Resource-Policy: same-origin

# Information disclosure headers to flag
curl -s -I "https://target.example.com/" | grep -iE "(server|x-powered-by|x-aspnet|x-generator)"
# Server: Apache/2.4.52 (should be removed or generic)
# X-Powered-By: PHP/8.1.2 (should be removed)
# These headers reveal technology stack to attackers

# Cache-Control for sensitive pages
curl -s -I "https://target.example.com/account/settings" | grep -i "cache-control"
# Sensitive pages should have: Cache-Control: no-store, no-cache, must-revalidate
# Prevents browser caching of sensitive data

# Generate comprehensive report using online tools
echo "Scan with SecurityHeaders.com: https://securityheaders.com/?q=target.example.com"
echo "Scan with Mozilla Observatory: https://observatory.mozilla.org/analyze/target.example.com"

主な概念

概念	説明
HSTS	ブラウザーにドメインへの接続で HTTPS のみを使用させ、プロトコルのダウングレード攻撃を防ぎます
CSP	ページで読み込み可能なリソース（スクリプト、スタイル、画像）を制限します
X-Frame-Options	ページを iframe に埋め込めるかどうかを制御します（クリックジャッキング対策）
X-Content-Type-Options	MIME タイプのスニッフィングを防ぎ、宣言された Content-Type をブラウザーに強制的に尊重させます
Referrer-Policy	クロスオリジンリクエストで送信されるリファラー情報の量を制御します
Permissions-Policy	ページで利用可能なブラウザー機能（カメラ、マイク、位置情報）を制限します
SameSite Cookie	クロスサイトのコンテキストで Cookie を送信するタイミングを制御します（Strict、Lax、None）
HSTS Preloading	初回アクセス時の保護のために、ブラウザーのソースコードに HSTS ポリシーをハードコードします

ツールとシステム

ツール	用途
SecurityHeaders.com	セキュリティヘッダーをレターグレードで評価するオンラインスキャナー
Mozilla Observatory	スコアと推奨事項を提示する包括的なウェブセキュリティスキャナー
CSP Evaluator (Google)	Content Security Policy の弱点とバイパスを分析します
Burp Suite Professional	アプリケーションのすべてのページにわたってレスポンスヘッダーを検査します
securityheaders (CLI)	コマンドラインのセキュリティヘッダースキャナー
Hardenize	TLS とセキュリティヘッダーの監視サービス

よくあるシナリオ

シナリオ 1：ヘッダーがまったく設定されていない

レガシーアプリケーションがセキュリティヘッダーをまったく返しません。HSTS、CSP、X-Frame-Options、Cookie のセキュリティフラグのいずれもありません。すべてのページがクリックジャッキングに対して脆弱で、XSS に対するブラウザーレベルの緩和策もなく、Cookie は HTTP 経由で送信されます。

シナリオ 2：unsafe-inline を含む弱い CSP

CSP ヘッダーに script-src 'self' 'unsafe-inline' が含まれています。外部スクリプトの読み込みは制限されますが、unsafe-inline ディレクティブによって任意のインラインスクリプトが実行可能になり、XSS に対する CSP の効果が失われます。

シナリオ 3：Secure フラグのないセッション Cookie

セッション Cookie に Secure フラグが設定されていません。HTTP と HTTPS が混在するサイトでは、攻撃者が平文の HTTP リクエストを介してネットワーク上でセッショントークンを傍受できます。

シナリオ 4：HSTS が有効になっていないため SSL ストリッピングが可能

HSTS ヘッダーがありません。ネットワーク上の攻撃者は SSL ストリッピング攻撃を実行し、被害者の HTTPS 接続を HTTP にダウングレードして、すべてのトラフィックを傍受できます。

出力形式

## Security Headers Audit Report

**Target**: target.example.com
**Grade**: D (SecurityHeaders.com)
**Assessment Date**: 2024-01-15

### Headers Assessment
| Header | Status | Current Value | Recommended |
|--------|--------|---------------|-------------|
| Strict-Transport-Security | MISSING | - | max-age=31536000; includeSubDomains; preload |
| Content-Security-Policy | WEAK | script-src 'self' 'unsafe-inline' | script-src 'self' 'nonce-{random}' |
| X-Frame-Options | MISSING | - | DENY |
| X-Content-Type-Options | PRESENT | nosniff | nosniff (OK) |
| Referrer-Policy | MISSING | - | strict-origin-when-cross-origin |
| Permissions-Policy | MISSING | - | camera=(), microphone=(), geolocation=() |
| X-XSS-Protection | MISSING | - | 0 (with strong CSP) |

### Cookie Security
| Cookie | Secure | HttpOnly | SameSite | Path |
|--------|--------|----------|----------|------|
| session | NO | YES | Not set | / |
| user_pref | NO | NO | Not set | / |
| csrf_token | YES | NO | Strict | / |

### Information Disclosure
| Header | Value | Risk |
|--------|-------|------|
| Server | Apache/2.4.52 | Technology fingerprinting |
| X-Powered-By | PHP/8.1.2 | Version-specific exploit targeting |

### Recommendation Priority
1. **Critical**: Add Secure and SameSite flags to session cookie
2. **High**: Implement HSTS with min 1-year max-age
3. **High**: Replace 'unsafe-inline' in CSP with nonce-based policy
4. **Medium**: Add X-Frame-Options: DENY
5. **Medium**: Add Referrer-Policy: strict-origin-when-cross-origin
6. **Low**: Remove Server and X-Powered-By version information
7. **Low**: Add Permissions-Policy to restrict unused browser features