おい、最近のインシデントアラートを見たか？ 毎日のようにどこかの企業がSQLインジェクションやクロスサイトスクリプティング（XSS）でやられている。ニュース沙汰になってから慌ててWAFを導入しても、初期設定の「丸裸のマネージドルール」をただポチッと有効化しただけじゃ、百戦錬磨の攻撃者にとっては格好の通過儀礼でしかない。
「WAFを入れておけば安全です」なんて言うベンダーの営業トークを真に受けている後輩がいたら、今すぐその甘い汁を吐き出させたほうがいい。デフォルト設定のマネージドルールセット（MRS）は、誤検知（False Positive）を恐れるあまり、巧妙に難読化された攻撃ペイロードをいとも簡単に見逃す。
今回は、AWS WAFやAzure WAFのマネージドルールセットをどう調律（チューニング）し、さらに現場の泥臭い実務で必要になるカスタムルールをどう組み込むべきか、俺の実戦経験を総動員して叩き込んでやる。心して読め。
—
1. マネージドルールセット（MRS）の限界と「盲点」
AWS WAF（AWS Managed Rules）やAzure WAF（OWASP デフォルトルールセット）は、OWASP Top 10の脅威を防ぐための強力な盾だ。しかし、これらは「万能の処方箋」ではない。
攻撃者は、WAFのシグネチャを回避するために、文字エンコーディングの二重化、コメントアウトの挿入、あるいはアプリケーション側のパース仕様の隙をつくペイロードを送り込んでくる。
例えば、典型的なSQLインジェクションのPoCとして、以下のようなリクエストを考えてみよう。
GET /search?q=1%27%20UNION%20SELECT%20null,null,username,password%20FROM%20users-- - HTTP/1.1
Host: vulnerable-app.internalこれくらい素直なリクエストであれば、どのクラウドWAFのMRSでも一発でブロックできる。しかし、攻撃者はこれをそのまま投げたりしない。以下のように難読化してくる。
GET /search?q=1%2527%2520UN/**/ION%2520SEL/**/ECT%2520null,null,version()-- - HTTP/1.1
Host: vulnerable-app.internalURLエンコードを二重に行い（%2527）、さらにSQLのコメント構文（/**/）をキーワードの間に挟み込む。アプリケーション側がこれを適切にデコード・解釈してしまう場合、素のMRSのデフォルト感度（あるいは検査深度）のままだと、見事にすり抜けてバックエンドのデータベースに到達してしまうことがある。
ここで必要になるのが、「マネージドルールセットの感度引き上げ」と「カスタムルールによる多層防御（Defense in Depth）」だ。
—
2. AWS WAFでのマネージドルール最適化とアクション制御
AWS WAFを使う場合、AWSManagedRulesCommonRuleSet や AWSManagedRulesSQLiRuleSet を適用するのが基本だ。だが、これをただ「Count（カウント）」モードで動かしていたり、デフォルトのまま「Block（ブロック）」にしているだけでは不十分だ。
ここでは、誤検知を最小限に抑えつつ、攻撃ペイロードを確実に撃墜するためのTerraformによる最適化設定例を示す。単にルールを入れるだけでなく、スコープダウンステートメント（Scope-down statement）を用いて、静的アセットや管理画面外への無駄な検査コストを削りつつ、コアなエンドポイントを集中的に守るのがプロのやり方だ。
# AWS WAF WebACLの最適化設定サンプル (Terraform)
resource "aws_wafv2_web_acl" "optimized_waf" {
name = "production-optimized-web-acl"
description = "OWASP Top 10 countermeasures with customized managed rules"
scope = "REGIONAL"
default_action {
allow {}
}
# 1. AWS Managed Rules - SQLi ルールセットの追加と個別ルールのオーバーライド
rule {
name = "AWS-SQLiRuleSet"
priority = 10
override_action {
none {} # ルールグループ全体のデフォルト動作を使用
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesSQLiRuleSet"
vendor_name = "AWS"
# 例外処理（Exclusion）：特定のルールで誤検知が発生する場合の無効化
# ※実運用のログ分析で誤検知が確認された場合のみコメントアウトを解除すること
# excluded_rule {
# name = "SQLi_QUERYARGUMENTS"
# }
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "AWS-SQLiRuleSet-Metric"
sampled_requests_enabled = true
}
}
# 2. カスタムルール：特定の攻撃パターン（悪意あるスクリプトインジェクション等）に対する即時ブロック
rule {
name = "Custom-Block-Suspicious-XSS-Patterns"
priority = 20
action {
block {
custom_response {
response_code = 403
custom_response_body_key = "BlockedResponse"
}
}
}
statement {
or_statement {
statement {
byte_match_statement {
search_string = "<script"
field_to_match {
query_string {}
}
text_transformation {
priority = 1
type = "URL_DECODE"
}
text_transformation {
priority = 2
type = "LOWERCASE"
}
positional_constraint = "CONTAINS"
}
}
statement {
byte_match_statement {
search_string = "javascript:"
field_to_match {
body {
oversize_handling = "CONTINUE"
}
}
text_transformation {
priority = 1
type = "HTML_ENTITY_DECODE"
}
text_transformation {
priority = 2
type = "LOWERCASE"
}
positional_constraint = "CONTAINS"
}
}
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "CustomXSSBlock-Metric"
sampled_requests_enabled = true
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "ProductionWebACLMetric"
sampled_requests_enabled = true
}
}この設定のポイントは、カスタムルール側で URL_DECODE や HTML_ENTITY_DECODE といったテキスト変換（Text Transformation）を多重に適用している点だ。攻撃者がエンコードを何重に重ねようとも、WAF側で正規化（Normalization）を行ってからパターンマッチングを行うため、小細工は通用しない。
—
3. アプリケーション層での多層防御：WAFをすり抜けた攻撃を無力化するコード実装
どれほど優秀なWAFを構築しようとも、世の中にはゼロデイ脆弱性や、WAFの検査上限（AWS WAFであればボディ検査は最初の64KBまで等）を悪用した巨大なペイロード攻撃が存在する。
だからこそ、インフラ側（WAF）だけに依存せず、アプリケーション層でも徹底的にサニタイズとバリデーションを行う「多層防御」が不可欠だ。
ここでは、Python (Flask / SQLAlchemy) を用いたセキュアな実装サンプルを示す。SQLiやXSSをアプリケーション側で完全に無力化する鉄則を確認してほしい。
# セキュアな入力値検証とデータベースアクセスの実装例 (Python / Flask + SQLAlchemy)
from flask import Flask, request, jsonify, render_template_string
import re
html = Flask(__name__)
# 厳格な入力値バリデーション関数（ホワイトリスト方式の模範例）
def validate_search_query(query: str) -> str:
if not query:
return ""
# 許可する文字種を英数字、日本語、および一部の安全な記号のみに限定（ホワイトリスト検証）
# 悪意ある記号や制御文字（', ", -, ;, /*, */ 等）を一切排除する
if not re.match(re.compile(r'^[a-zA-Z0-9\sぁ-んァ-ン一-龥ー_-]{1,50}$'), query):
raise ValueError("無効な文字が含まれているか、文字数が長すぎます。")
return query.strip()
@app.route('/search', methods=['GET'])
def search_handler():
raw_query = request.args.get('q', '')
try:
# 1. 入力値の厳格な検証
clean_query = validate_search_query(raw_query)
except ValueError as e:
# 不正な入力は400 Bad Requestとして即座に弾く
return jsonify({"error": str(e)}), 400
# 2. データベースクエリの安全な実行（プレースホルダーの利用によるSQLi完全防御）
# ※直接文字列を結合するのではなく、ORMやパラメータ化クエリを必ず使用する
# results = User.query.filter(User.username.like(f"%{clean_query}%")).all()
# 3. 出力時のコンテキストに応じたエスケープ（XSS完全防御）
# テンプレートエンジン（Jinja2等）はデフォルトでHTMLエスケープを行うため安全だが、
# 生のデータをそのままsafeフィルター等で出力しないこと。
safe_html_output = f"<h1>検索結果: {clean_query}</h1>"
return render_template_string(safe_html_output)
if __name__ == '__main__':
app.run(debug=False) # 本番環境では必ずdebug=Falseに設定開発チームへの申し送り事項
1. プレースホルダーの徹底: 生のSQLクエリ文字列を組み立てるコード（cursor.execute("SELECT * FROM users WHERE name = '" + user_input + "'") など）を発見した場合は、即座にPull RequestをReject（差し戻し）すること。
2. 出力エスケープの確認: フロントエンド側（ReactやVue.jsなど）でデータを描画する際も、dangerouslySetInnerHTML や v-html などのDOM直接操作は原則禁止とする。どうしても使用する場合は、DOMPurify等のサニタイズライブラリを通すこと。
—
4. 運用・監視の勘所：ログの泥臭いアナリティクス
WAFを導入して終わりではない。むしろここからが本当の勝負だ。
CloudWatch LogsやAzure Monitorに流れてくるWAFのブロックログを毎日監視し、「正しくブロックできているか」「正当なユーザーを誤検知（False Positive）していないか」を確認する必要がある。
特に見るべきフィールドは以下の通りだ。
terminatingRuleId: どのルールがヒットしてブロックされたのかhttpRequest.clientIp: 攻撃元のIPアドレス（特定のボットネットからの集中攻撃であれば、AWS WAFのIPセットやAWS Shield/WAFのレートベースルール（Rate-based rule）で一網打尽にする）httpRequest.args: 実際に送信された汚染されたパラメータ
もし、社内の特定の正当な業務ツールやAPIクライアントからのリクエストが誤検知されているのを発見した場合は、慌ててマネージドルール全体を無効化するのではなく、「特定のルールIDのみを例外指定（Exclusion）」するか、「カスタムルールの条件をより厳密にスコープダウン」させること。
セキュリティは、一発の魔法のツールで完成するものではない。地道なログ分析、ルールチューニング、そしてアプリケーション層での泥臭いバリデーションの積み重ねだけが、システムの堅牢性を担保する。
手を抜くな。お前たちのコードとインフラを守れるのは、他の誰でもない、お前自身だ。
コメント