さて、ブログを書かなかった間にXSSからSQLインジェクションへ興味が移った、なんてことはありませんでしたので、今日もいつも通り大好きなXSSの話をしたいと思います！
最近、正規表現にユーザ入力を使っていることに起因するDOM based XSSに連続して遭遇しました。あまり見慣れていない注意が必要な問題だと思うので、この記事では、見つけたもの2つがどのように生じたか、また、問題を起こさないためにどうすればよいかを紹介します。
そのうちの1つはLINEのBug Bounty Programを通じて報告した問題です。
賞金と、"LINE SECURITY BUG BOUNTY"と書かれたシンプルなTシャツをもらいました。
LINEのバグの詳細は記事の後半にあります。
それでは見ていきます！
例1： zaif.jp にあったDOM based XSS
仮想通貨が盛り上がっていますね。僕は持っていないのですが、どんなものかとTwitterで話題にあがっていた取引所の zaif.jp のトップページをふと覗いたところ、以下のような興味深いコードを見つけました。(不要な部分は省略しています。)
$(".btn").on("click", function(e) {このコードは、URL中の#以降の文字を削除してリダイレクトする意図で書かれているように見えます。しかしながら、削除する方法が適切でないため、任意のスクリプトを実行できてしまいます。どこに問題があるかわかりますか？
var url = location.href;
var regExp = new RegExp( location.hash, "g" );
url = url.replace( regExp, "");
window.location.href = url;
});
正規表現を作っている部分に注目してください：
var regExp = new RegExp( location.hash, "g" );この書き方には問題があります。RegExpコンストラクタの第一引数には正規表現になる文字列がきます。したがって、この場合は
location.hashが正規表現として使われることになります。このコードでも、#aaaのように、#以降に英数字のみが含まれるようなURLであれば意図通りに#以降が削除されます。しかしながら、.や+など、正規表現の特殊文字が#以降に含まれていた場合に意図しない置換が起こってしまいます。例えば、次のようなURLからアクセスされた場合を考えてみてください：
https://zaif.jp/#|.+
location.hashから正規表現が組み立てられることにより、URL文字列は次のように置換されます。url.replace(/#|.+/g, "");これは、「#」か「改行文字以外の文字の連続」(
.+) のいずれかを空文字列に置換するという意味になります。.+はURL中のすべての文字列とマッチするので、すべての文字列が空文字列に置換されてしまいます。このように、正規表現の特殊文字をURLの#以降に指定することで、#以降の文字列以外も切り取ることができてしまいます。一見、小さなバグのようにも思えますが、このせいで任意のスクリプトの実行まで可能です。切り取られた文字列は
location.hrefに代入されるため、細工した正規表現を使って、javascript:スキームのURLとなる文字列を残せば、スクリプトを実行するURLへナビゲートできてしまいます。PoCを示します。次のようなURLからアラートを実行できます：
https://zaif.jp/#javascript:alert(1)//|.+\x23
このURLからは次のような置換が行われます。
url.replace(/#javascript:alert(1)\/\/|.+\x23/g, "");
.+\x23 (\x23は # をエスケープした形) によって、先頭から#までの文字列が削除されます。結果、残されるのはjavascript:alert(1)//|.+\x23というURLとなり、スクリプトの実行が可能となります。このXSSを再現できるページを用意しました。以下からスクリプトの実行を試すことができます：
https://vulnerabledoma.in/domxss_regex.html#javascript:alert(1)//|.+\x23
この問題は、2017年12月中旬に報告し、1週間程度で修正されました。現在は、正規表現を使わず、
location.href.split("#")[0]で#以降の文字列を除いているようです。例2： LINE のドメインにあったDOM based XSS
2017年4月頃にLINE Security Bug Bounty Programを通じて報告し、$500 の賞金を獲得したバグです。
以下に問題があったページを模したページを用意しました。どこにXSSがあるかわかりますか？
https://vulnerabledoma.in/domxss_regex2.html?id=123
<script id="template" type="text/template">まず、
<img src="https://example.com/img/{{id}}.png">
</script>
<script>
function parseQuery() {
var res = {};
var tmp;
var items = location.search.substr(1).split('&');
for (var i = 0; i < items.length; i++) {
tmp = items[i].split('=');
if (tmp[0]) {
res[tmp[0]] = decodeURIComponent(tmp[1]);
}
}
return res;
}
function renderHTML(data) {
var current = document.getElementById('template');
var template = current ? current.innerHTML : '';
for (key in data) {
var re = new RegExp('{{' + key + '}}', 'gm');
var safe = escapeHTML(data[key]);
template = template.replace(re, safe);
}
document.body.innerHTML = template;
}
function escapeHTML(src) {
var res = src;
var escapeMap = {
'&': '&',
'<': '<',
'>': '>',
'"': '"',
"'": ''',
'`': '`'
}
for (key in escapeMap) {
var re = new RegExp(key, 'gm');
res = res.replace(re, escapeMap[key]);
}
return res;
}
var params = parseQuery();
if (params.id) {
renderHTML(params);
}
</script>
parseQuery()でクエリの名前と値のペアのオブジェクトを作成しています。クエリはページ上部にあるtype="text/template"なscriptタグにあるHTMLのテンプレートのプレースホルダ(この例では{{id}})を置換するために使われます。置換処理部分を以下に抜粋します：
for (key in data) {data変数は
var re = new RegExp('{{' + key + '}}', 'gm');
var safe = escapeHTML(data[key]);
template = template.replace(re, safe);
}
parseQuery()で作成したクエリのオブジェクトです。ここでは、クエリと同名のプレースホルダがテンプレートに存在するかどうかにかかわらず、for...in文ですべてのクエリをプレースホルダとして置換しようとしています。今回は、ユーザ入力から正規表現を組み立てているだけでなく(new RegExp('{{' + key + '}}', 'gm')部分)、置換後の文字列もユーザ入力で指定できています(escapeHTML(data[key])部分)。例えば、id=123というクエリがあるとき、次のような置換処理が行われることになります。黄色部分がユーザ入力から設定されたものです：template.replace(/{{id}}/gm, '123');置換後の文字列を指定できるのなら、シンプルにクエリにHTMLタグを与えることでXSSできるのではと考えるところですが、置換後の文字列はescapeHTML関数によってエスケープされるため、次のようなURLからアクセスしてもXSSは発生しません：
https://vulnerabledoma.in/domxss_regex2.html?id="><s>aaa
どんな文字列を与えたらXSSが成立するでしょう？今回も、正規表現を細工することでXSSを起こします。加えて、今回は置換後の文字列も細工します。
PoCを先に示します。次のようなURLにアクセスするとスクリプトを実行できます：
https://vulnerabledoma.in/domxss_regex2.html?id=123&|(.)h|=$1a$1onerror%3Dalert(1)//
なぜスクリプトを実行できたか見ていきます。
置換前のテンプレート文字列は次のようになっています。
<img src="https://example.com/img/{{id}}.png">まず、クエリのid=123により、{{id}}の部分が123に置換されます。
あとに続く
|(.)h|=$1a$1onerror%3Dalert(1)//というクエリからも置換が行われます。実行される置換処理は次のようになります：template.replace(/{{|(.)h|}}/gm, '$1a$1onerror=alert(1)//');
このコードはテンプレート中にある「{{」または 「任意の1文字 + h」(
(.)h) または「}}」を、指定した文字列に置換しようとします。このうち、「任意の1文字 + h」はテンプレート中の以下の黄色部分で発見できます：<img src="https://example.com/img/123.png">この部分が、
$1a$1onerror=alert(1)//で置換されます。$1は()でくくった部分にマッチした文字列を配置するという意味で、ここでは"が取り出されます。したがって、テンプレート文字列は次のように置換されます：
<img src="a"onerror=alert(1)//ttps://example.com/img/123.png">見ての通り、imgタグにonerrorイベントハンドラが追加できてしまっています。この文字列が
document.body.innerHTML = template;でページに書き出されることによって、任意のスクリプトの実行が達成されるという訳です。修正後は、ユーザ入力から正規表現を組み立てるのではなく、以下のようにテンプレートに埋め込まれたプレースホルダを検索することによって置換を行うようになったようです。
template = template.replace(/{{(\w+)}}/gm, function($0,$1) {
return escapeHTML(data[$1]);
});
このような問題を防ぐには
どちらの問題も、ユーザ入力から"正規表現を組み立てていること"を失念しており、単に検索用の"文字列として"使われることを期待したことが原因で発生したように思います。いずれの修正も正規表現を組み立てない方法で書き直すことができているように、たいていの場合、ユーザ入力から正規表現を組み立てる必要はないはずです。
new RegExp(USER_INPUT,"")のようなコードを書いてしまったら、それは本当にやりたいことなのか、一度考え直してみるとよいかと思います。ユーザに正規表現を使わせたいとき以外、まず適切な書き方ではありません。以上、正規表現にユーザ入力を使っていることに起因するDOM based XSSの例を2つ紹介しました。
このような問題を避ける助けとなれば嬉しいです。
0 件のコメント:
コメントを投稿