Azure Application Gateway（AGW）でWAFを運用していると、昨日まで動いていたのに、急に特定のユーザーだけログインできなくなった」という謎のトラブルに遭遇することがあります。
ログを解析してみると、犯人はシステムへの攻撃ではなく、皮肉にも「セキュリティのために暗号化されたログインCookie」でした。今回は、WAFの誤検知（False Positive）との戦いと、その解決策についてまとめます。
1. 発生したトラブル：ログインボタンを押すと「403 Forbidden」
システム開発の最終盤、受入テストを目前に控えたタイミングで、一部のユーザーから「ログインできない」という報告が上がりました。
ブラウザのデベロッパーツールで確認すると、ログインリクエストに対して 403 Forbidden が返されています。アプリ側のログには何も残っておらず、どうやらアプリに到達する前の「WAF（Web Application Firewall）」で遮断されているようでした。
2. 原因：暗号化されたCookieがSQLインジェクションに見えた
Azureのログストリーム（または診断ログ）を調査したところ、以下の不穏な検知ログが見つかりました。
• 検知されたパターン: ?:/*!?|*/|[';]--|--[\s\r\n\v\f]|--[^-]*?-
• 検知対象: REQUEST_COOKIES:.システムで利用しているソリューション名
なぜこれが「攻撃」と判定されたのか？
ASP.NET Coreの認証システムが発行するCookieは、セキュリティを担保するために強力に暗号化されています。その結果、中身は CfDJ8Iwnl6yp... といったランダムな英数字・記号の羅列になります。
しかし、このランダムな文字列の中に、運悪く --（ハイフン2つ） が含まれてしまうことがあります。WAFの標準ルール（OWASP規則など）は、この -- を 「SQLのコメントアウトを悪用した攻撃コード」 と見なして、通信を即座にブロックしてしまったのです。
つまり、「セキュリティを高く保とうとした暗号化Cookieが、セキュリティ製品（WAF）に攻撃と間違えられた」という皮肉な構図です。
3. 解決策：特定のCookieを監視対象から除外する
全てのSQLインジェクション対策をオフにするわけにはいきません。そこで、「この名前のCookieだけは安全だから、チェックを通す」というピンポイントな除外設定（Exclusion）を行います。
Azure Portal での設定手順
1. WAF ポリシーのリソースを開きます。
2. 左メニューの [設定] ＞ [管理ルール] を選択します。
3. 上部のタブから [除外] をクリックし、[追加] を押します。
4. 以下の通り設定します。
• 対象: 要求クッキー名 (Request cookie name)
• 演算子: 等しい (Equals)
• セレクター: . （※ご自身のシステムの認証Cookie名）
5. [保存] をクリックして適用します。
これで、WAFは「このCookieの中身がどうあれ、SQLインジェクションのチェックは行わない」という挙動になり、誤検知によるブロックが解消されます。
4. まとめ：WAFは「導入して終わり」ではない
今回の件で痛感したのは、WAFは導入後のチューニングが不可欠であるということです。
特にASP.NET CoreやJava Springなどのフレームワークを使っている場合、フレームワークが自動生成するCookieやトークンがWAFのルールに抵触することは珍しくありません。
「403エラーでログインできない」という報告を受けたら、まずはWAFのログを疑ってみてください。正しく「除外設定」を行うことで、鉄壁の守りとスムーズなユーザー体験を両立させることができます。