こんにちは。ネットワークの底流で蠢くパケットの機微に魅せられて幾星霜、今日もどこかの本番環境でヒヤリとするトラブルシューティングに立ち会っているシニアエンジニアの私です。
Webアプリケーションのセキュリティ診断や脆弱性アセスメントのレポートを見ていると、時折「HTTP TRACEメソッドの有効化」という項目がハイリスク（あるいは中リスク）として指摘されているのを目にします。「なんだか地味なメソッドだな、GETやPOSTじゃないし放っておいてもいいか」なんてスルーしていませんか？
甘い。実にあまいと言わざるを得ません。
この一見無害に見える `TRACE` メソッド、実は適切に封じ込めておかないと、現代のWebフロントエンドが抱える脆弱性と組み合わさることで、認証クッキーやセッション情報をいとも簡単に奪い去られる「XST（クロスサイトトレーシング）攻撃」という悪夢の扉を開いてしまうのです。
今回は、この `TRACE` メソッドがなぜ生まれ、どうして現代のインフラでは「即座に無効化すべき悪者」とされているのか、そのパケットレベルの挙動から具体的な無効化設定、そして実務での確認方法まで、たっぷりと解説していきましょう。
—
1. TRACEメソッドの本来の仕様と「自己反射」のメカニズム
HTTP/1.1（RFC 7231 / RFC 9110）の仕様書をめくると、`TRACE` メソッドは次のように定義されています。
> 「TRACE メソッドは、リクエストメッセージの遠隔的なアプリケーション層によるループバックテストを開始するために使用される。リクエストの受信者は、受信したメッセージを最終的な受信者から `message/http` ボディとしてクライアントにエコーバック（そのまま返送）しなければならない。」
要するに、クライアント（ブラウザやデバッグツール）がサーバーに対して「今、私が送ったリクエストヘッダーやボディが、途中のプロキシやロードバランサーをどう通過してそっちに届いたか確認したいから、そのままオウム返ししてよ」と頼むためのデバッグ用機能です。
通信フロー（シーケンス）のイメージ
通常の `GET` や `POST` は、サーバーがリクエストを解釈して処理結果（HTMLやJSON）を返しますが、`TRACE` は以下のように「鏡」のようにそのまま返します。
[Client / ブラウザ] [Reverse Proxy / Nginx等] [Origin Server]
| | |
|— HTTP TRACE /foo HTTP/1.1 ——–>| |
| Host: example.com |— (リクエストを転送) ——–>|
| X-Custom-Debug: test-val | |
| | |
|<-- 200 OK (エコーバック) ------------|<-- (そのまま送り返す) -------|
| Content-Type: message/http | |
| | |
| [レスポンスボディの中身] | |
| TRACE /foo HTTP/1.1 | |
| Host: example.com | |
| X-Custom-Debug: test-val | |
一見すると、インフラエンジニアが「お、プロキシが意図通りヘッダーを書き換えているか？」を確認するのに便利そうに見えますよね。しかし、ここに大きな落とし穴があります。
---
2. なぜ悪用されるのか？クロスサイトトレーシング（XST）の脅威
かつて、Webブラウザの `XMLHttpRequest`（現在の Fetch API の祖先）には、同一オリジンポリシー（CORS）の制限をバイパスして別ドメインにリクエストを送れるものの、`HttpOnly` 属性がついたセッションクッキーは JavaScript から読み取れないという鉄則がありました。
しかし、攻撃者が以下のようなシナリオを描いたとき、状況が一変します。
1. 攻撃者が巧妙なスクリプトを仕込んだ悪意あるサイトをユーザーに踏ませる。
2. そのスクリプトが、ターゲットの脆弱なWebサーバーに対して `TRACE` リクエストを非同期で発行する。
3. ブラウザは、そのドメインに対する有効な認証クッキー（`HttpOnly` がついていようが何だろうが！）を自動的にリクエストヘッダーに付与して送信する。
4. サーバーは `TRACE` メソッドの仕様通り、受信したリクエスト（＝認証クッキーが含まれた生のHTTPリクエスト全体）をそのままレスポンスボディとしてクライアントに返す。
5. 攻撃者のスクリプトは、そのレスポンスボディを読み取ることで、本来JavaScriptからは絶対に見えないはずのセッションクッキーや認証トークンをいとも簡単に取得してしまう。
これが、XST（Cross-Site Tracing）攻撃のメカニズムです。
現代のモダンブラウザやAPIクライアントでは、スクリプトからの `TRACE` メソッドの発行自体が制限される傾向にあります。しかし、インフラストラクチャやAPIサーバー側でこのメソッドを生かしたままにしておくことは、いわば「鍵の壊れた裏口をあえて開けておくようなもの」です。セキュリティ監査の基準（PCI DSSや各種セキュアコーディングガイドライン）においても、`TRACE` メソッドの無効化はほぼ必須項目となっています。
—
3. 実務での確認方法：手元でTRACEの挙動を暴く
では、今あなたが管理しているサーバーや、テスト環境のWebサーバーが `TRACE` を受け付けてしまう状態にあるかどうか、手元の環境からサクッと確認してみましょう。
プログラミング言語やコマンドラインツールを使った具体的な検証スニペットをいくつか紹介します。
curlコマンドによる確認
もっとも手っ取り早いのは、おなじみ `curl` を使う方法です。`-X TRACE` を指定してリクエストを投げ、サーバーが `200 OK` とともにリクエスト内容を返してくるか確認します。
テスト対象のエンドポイントに対してTRACEメソッドを投げる
curl -i -X TRACE https://api.example.com/debug-test \
-H “X-My-Custom-Header: Hello-Trace-World”
【危険な状態のレスポンス例】
HTTP/1.1 200 OK
Date: Wed, 25 Oct 2023 12:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: message/http
TRACE /debug-test HTTP/1.1
Host: api.example.com
User-Agent: curl/7.68.0
Accept: /
X-My-Custom-Header: Hello-Trace-World
サーバーがこのレスポンスを返してきた場合、あなたのサーバーは `TRACE` を野放しにしています。直ちに対策が必要です。
Python (requests) による確認
Pythonスクリプトで定期的なセキュリティスキャンを内製している場合、以下のようなコードで一括チェックできます。
import requests
def check_trace_method(target_url):
try:
# TRACEメソッドでリクエストを送信
response = requests.request(“TRACE”, target_url, timeout=5)
# ステータスコードとレスポンスヘッダーをチェック
if response.status_code == 200 and “message/http” in response.headers.get(“Content-Type”, “”):
print(f”[!] 警告: {target_url} は TRACE メソッドを受け付けています（脆弱性あり）”)
print(f”— エコーバックされた内容 —\n{response.text[:300]}…”)
else:
print(f”[+] 安全: {target_url} は TRACE を適切に拒否または無効化しています (Status: {response.status_code})”)
except Exception as e:
print(f”[-] エラー発生: {e}”)
if __name__ == “__main__”:
check_trace_method(“https://api.example.com/health”)
—
4. 各種Webサーバー・プロキシでの無効化設定（実践レシピ）
見つかった脆弱性は、速やかに塞ぎましょう。主要なWebサーバーやリバースプロキシにおける具体的な設定変更手順を解説します。設定ファイルをいじる際は、必ず構文チェック（テストコマンド）を行ってからリロードしてください。
① Nginx の場合
Nginxは、デフォルトの状態では `TRACE` メソッドに対するハンドラーを持たないため、通常は `TRACE` リクエストを受けると `405 Not Allowed` を返します。しかし、何らかの設定ミスやカスタム設定で意図せず通してしまう場合があります。
もし明示的にすべて弾きたい、あるいは `map` ディレクティブ等で制御したい場合は、サーバーブロック内で次のように記述します。
server {
listen 80;
server_name api.example.com;
# TRACEメソッドが飛んできた場合は強制的に405を返す
if ($request_method = TRACE) {
return 405;
}
location / {
proxy_pass http://backend_upstream;
# その他のプロキシ設定…
}
}
② Apache HTTP Server の場合
Apache（httpd）は歴史的経緯もあり、デフォルトで `TRACE` が有効になっているバージョンが多々あります。Apacheで `TRACE` を無効化するには、設定ファイル（`httpd.conf` や `apache2.conf`、またはバーチャルホストの設定）に `TraceEnable` ディレクティブを記述します。
グローバル、またはバーチャルホストのコンテキストで設定
Offに設定することで、TRACEリクエストに対して405 Method Not Allowedを返す
TraceEnable Off
※設定変更後は必ず `apachectl configtest` で構文を確認し、`systemctl reload apache2`（または `httpd`）を実行してください。
③ IIS (Internet Information Services) の場合
Microsoft IISの場合、URL書き換えモジュール（URL Rewrite Module）や、リクエストフィルタリング機能を使って `TRACE` メソッドをブロックするのが最も確実です。
Web.config に以下のように記述します。
—
5. シニアエンジニアからの実務アドバイス
本番環境のインフラを堅牢化する際、単に「ガイドラインに書いてあるから設定を変える」のではなく、「なぜその設定が必要なのか」をチーム全体で共有することがトラブルを防ぐ最大の近道です。
1. 上流のロードバランサーやWAF（AWS WAFやCloudflare等）でもガードする
アプリケーションサーバー単体で `TRACE` を無効化するのは当然ですが、エッジ側（CDNやWAF）のルールでも `TRACE` や `TRACK` といった不正なHTTPメソッドを一律でブロック（あるいは `403 Forbidden`）するようにルールを設定しておくと、多層防御として非常に強固になります。
2. 脆弱性スキャナーの誤検知に注意する
たまにあるのが、自動脆弱性診断ツールが「`TRACE` が有効です」とアラートを出したものの、よく調べてみると自前のAPIゲートウェイが独自のカスタムエラーページを `200 OK` で返しているだけで、実際のメッセージボディはエコーバックしていない（安全な状態）というケースです。必ず自分で `curl` などを叩いて、本当にリクエストの中身が丸見えになっていないか（実害があるか）を目視で確認する「ひと手間」を惜しまないでください。
ネットワークの挙動は、細部（エッジの細かい設定やメソッドの仕様）に神ならぬ「脆弱性」が宿ります。一つひとつのプロトコル仕様に向き合い、安全で堅牢なインフラを構築していきましょう。それでは、また次回の現場でお会いしましょう！
コメント