Hatena::ブログ(Diary)

ockeghem(徳丸浩)の日記 このページをアンテナに追加 RSSフィード

[PR]WAFの導入はHASHコンサルティング
 |  

2010-10-18

講演予告3題 講演予告3題を含むブックマーク

twitterで次のようにつぶやいたところ

PHPカンファレンスでやった文字コードの話を再演できる適当な場はないかな。まぁ、本書きで忙しい(はず and/or べき)ので、やりたいような、やらない方がいいような…とつぶやいてみる

http://twitter.com/#!/ockeghem/status/25955951747

ECナビの春山さん @haruyama と、セキュmemoの小島先生 @kjmkjm が反応してくださり、東京京都勉強会を開催することになりました。

東京の「第1回神泉セキュリティ勉強会」では、春山さんや、サイボウズラボの奥さん @kazuho 、竹迫さん @takesako にもお話し頂きますので、私自身とても楽しみです。

京都の「@random な勉強会」では、なんと京大の上原先生 @tetsutalow が、「岡崎図書館事件に見る自治体IT調達の問題点」という演題で講演されます。私も、LASDECのウェブ健康診断の仕様策定をお手伝いした関係などで自治体のIT調達には関心がありますので、楽しみです。

あと、Internet Week 2010で講演することになりましたのでお知らせします。。


第1回神泉セキュリティ勉強会

日時: 2010/10/26(火) 19:00〜

場所: 株式会社ECナビ

参加費用: 無料

タイトル:文字コードに起因する脆弱性とその対策

プログラム、申し込みはこちら


@random な勉強会

日時: 2010.10.30 (土) 13:00〜17:00

場所: 龍谷大学深草学舎 21 号館 406 室。

参加費用: 500円 (学生は無料)

タイトル: 文字コードに起因する脆弱性とその対策

プログラム、申し込みはこちら


Internet Week 2010

日時: 2010年11月24日(水) 13:00〜15:30

場所: 富士ソフト アキバプラザ

タイトル: S3 今日こそわかる、安全なWebアプリの作り方2010

5,000円の有料セッションです。

2.5時間の枠がありますので、Webアプリセキュリティの全体像をおさらいした後、以下の3テーマに深く切り込む予定です。

SQLインジェクション

文字コードの問題

携帯電話向けWebアプリセキュリティ

2010-09-22

PHPカンファレンス テックデイにて講演します PHPカンファレンス テックデイにて講演しますを含むブックマーク

PHPカンファレンス2010のテックデイ講演公募枠に応募して採用となりましたので、講演することになりました。9月25日(土)蒲田大田区産業プラザ PiOです。詳細は、講演プログラムをご覧ください。

タイトルは、「[T-6]文字コードに起因する脆弱性とその対策」ということで、現在の文字コードセキュリティのレビュー的な講演になります。専門家の方には目新しい話題はないかと思いますが、現状のまとめとしてお聞きいただければと思います。

講演の目玉として、「文字コードに起因する脆弱性のデモ6連発」を実演する予定です。

PHPカンファレンスですので全てのデモをPHPで記述したかったのですが、PHPでは再現しにくいものもあり、4つがPHP、2つがJavaによる記述です。

これさえ聴けば、あなたも文字コードセキュリティ通になれる…かもしれない…というわけでご期待ください。

カンファレンス申し込みはこちらから

=nat=nat 2010/09/23 09:20 残念。いきたいけど、海外です orz

トラックバック - http://d.hatena.ne.jp/ockeghem/20100922

2010-08-04

iモードブラウザ2.0のJavaScriptではiframe内のコンテンツを読み出せない iモードブラウザ2.0のJavaScriptではiframe内のコンテンツを読み出せないを含むブックマーク

iモードブラウザ2.0では、同一ドメインであっても、iframe内のコンテンツがJavaScriptにより読み出せないよう制限が掛かっていることを確認しましたので報告します。

【追記】元の内容には、重大な事実誤認がありました。正確には、同一ドメイン・同一ディレクトリであれば読み出せます。詳しくは追記2をご覧ください。

きっかけ

ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された - 徳丸浩の日記(2010-02-22)にて既に紹介したように、twitter.comの日本のケータイ向けフロントエンドであるtwtr.jpにDNSバインディング脆弱性があったことを確認・報告し、直ちに修正されました。このエントリの中に、以下のように書いています。

すぐに確認作業が終わるだろうと思っていたが、意外なところで失敗した。ログイン・リクエストのPOSTがうまくいかないのだ*1。早く確認を終わらせないと、もたもたしているうちに脆弱性を悪用されるとまずい。結局、XMLHttpRequestをあきらめ、IFRAME要素を用いることにした。

最初、IRAME要素をDOMで動的に作ったりしていたのだが、IFRAME内のFORMをうまくSUBMITできない。このため、以下のような構成にした。

 このうち、XMLHttpRequestでPOSTリクエストがうまくいかない理由は、 iモードブラウザ2.0のXMLHttpRequestでPOSTデータの扱いが困難になった - 徳丸浩の日記(2010-01-18)で報告したように、iモードブラウザ2.0ではsetRequestHeaderメソッドが殺されていたために、Content-Typeを設定できないことが原因でした。

 もう一つの、「IFRAME内のFORMをうまくSUBMITできない」件について、しばらく放置していましたが、この度検証しましたので報告します。その理由は、表題のように、iframe内のコンテンツに対してJavaScriptからのアクセスが禁止されたことでした。

検証用スクリプト

以下のコンテンツを用いて検証しました。ご覧のように、iframe内にdiv要素(id=innerdiv)があり、そのinnerHTMLを取得・表示するものです。

p.html(外側)

<html>
<body>
<script>
function get() {
  try {
     var n;
     n = 1; var iframe = document.getElementById("iframe01"); // HTMLIFrameElement
     n = 2; var cw = iframe.contentWindow;  // Window
     n = 3; var cd = iframe.contentDocument;  // HTMLDocument(使っていない)
     n = 3; var doc = cw.document;  // HTMLDocument
     n = 4; var x = doc.getElementById("innerdiv").innerHTML;
     n = 5; document.getElementById("output").innerHTML = x;
     n = 6;
  } catch (e) {
    document.getElementById('output').innerHTML = n + ':' + e.message;
  }
  document.getElementById('debug').innerHTML = 'cw=' + cw + '<br>cd=' + cd;
}
</script>
<input type="button" value="GET" onclick="get();"><br>
<iframe width=300 height=50 id="iframe01" src="pch.html"></iframe>
<div id="output"></div>
<div id="debug"></div>
</body>
</html>

pch.html(iframeの内側)

<html>
<body>
<div id="innerdiv">this is a pen.</div>
</body>
</html>

Chromeでの実行結果(FirefoxOperaSafariも同様)。

f:id:ockeghem:20100804001540p:image

IE7での実行結果

f:id:ockeghem:20100804002014p:image

Softbank 932SHでの実行結果

f:id:ockeghem:20100804003243j:image

iモードブラウザ2.0(P-07A)での実行結果

f:id:ockeghem:20100804003242j:image

ご覧のように、iモードブラウザ2.0のみiframe内のコンテンツを読み出せず、iframeのcontentWindowおよびcontentDocumentはundefinedに設定されています。

今度はiframe内コンテンツの別の読み出し方として、高木浩光氏の日記高木浩光@自宅の日記 - 共用SSLサーバの危険性が理解されていないで紹介されている方法を少し改変して試してみました。

<body>
<iframe src="/example.com/" name="foo"></iframe><BR>
<input type=button value="Get Cookie" onclick="getcookie();">
<script>
function getcookie() {
  try {
    var n = 0;
    n = 1; var doc = foo.document;
    n = 2; var x = doc.cookie;
    n = 3; document.getElementById("out").innerHTML = x;
  } catch(e) {
    document.getElementById('out').innerHTML = n + ':' + e.message;
  }
}
</script>
<div id="out"></div>
</body>

こちらの実行結果は以下のようになりました。

f:id:ockeghem:20100804003241j:image

先ほどとは違い、「operation is inhibited」という例外が発生しています。

iframe内要素を読み込めなくした理由は何か

iモードブラウザ2.0でiframe内コンテンツを参照できないように制限が掛けられていることがわかりました。しかし、他のブラウザには、そのような制限はないので、なぜ制限を掛けたのか、その理由が気になります。

一つ思い当たるのは、既にP-07AでもJavaScriptが再開され、あらたな制限がみつかった - ockeghem(徳丸浩)の日記で報告しているように、XMLHttpRequestで親ディレクトリのコンテンツを参照が禁止されたこととの関連です。以下のような仮説はどうでしょうか。

一例として、二つのコンテンツが同一ドメイン上の別ディレクトリに配置されているとします。

  • http://example.jp/~foo/
  • http://example.jp/~bar/

 上記に示したような、同一ドメイン上の別ディレクトリに配置された別のコンテンツについて、相互にJavaScript等でアクセスができないように制限したという仮説です。「XMLHttpRequestで親ディレクトリのコンテンツを参照が禁止された」件は、まさにこれに該当します。

 一方、iframeの方は一見関連がないように見えますが、先に参照した高木浩光@自宅の日記 - 共用SSLサーバの危険性が理解されていないで説明されているように、異なるディレクトリに配置されたコンテンツのCookie値を参照する方法として、iframeを使う手法があります。これを禁止したのではないかという仮説です。

 本当のところは分かりませんが、上記の仮説でつじつまが合うような気がします。しかし、PC向けブラウザではアクセスできるものが、iモードブラウザ2.0ではアクセスできことは、既存のJavaScript資産プログラマの知識が有効活用できないことになり、かつNTTドコモの公式ドキュメントにもこのような記述は見あたらないことから、もっと情報をオープンしていただきたいものです。

 また、ソフトバンクに関して言えば、私が検証した932SHは、正式にJavaScriptが搭載された機種ではないことから、正式にJavaScriptが搭載された944SH/945SHではどうなるかが気になります。検証環境を公開しますので、944SHあるいは945SHをお持ちの方は試して頂けないでしょうか。

http://www.tokumaru.org/p.html あるいはQRコードから検証コンテンツを閲覧ください。

f:id:ockeghem:20100804005425p:image

追記(2010/08/04 18:00)

 id:harupuさんからブクマコメントを頂戴しました。

普通にname属性使ってiframe_name.document.documentElement.outerHTMLとかで読めると思ったけど……。PC向けブラウザでもJavaScript自体まちまちな実装だし多少違いがあるのは仕方ないのでは。

私も最初は実装の違いかと思っていたのですが、iframe_name.documentを参照すると、「operation is inhibited」という例外が発生します(2番目のスクリプトの結果参照)ので、意図的に禁止されているものと推測します。また、ソフトバンクドコモは共にACCESS社のNetFrontブラウザを採用していることと、P-07Aより古い932SHがiframe内コンテンツにアクセスできて、新しいP-07Aはiframe内コンテンツにアクセスできないことからも、意図的な制限であることの傍証になると思います。

追記2(2010/08/04 20:15)

id:harupuさんから再度のコメントをいただきました。

ディレクトリ遡る話と混ぜてる?遡らなければN-06Aではできていりう。

確認したところ、確かにそうでした。親コンテンツと同一ディレクトリもしくは、親コンテンツのサブディレクトリのコンテンツであれば、

iframe_name.document.documentElement.outerHTMLなどで読み出せます(実際にはinnerHTMLで確認)。お詫びして訂正いたします。

すなわち、iframe自体はどのドメインディレクトリであっても作れますが、JavaScriptを使ってiframe内のデータにアクセスするためには、同一ドメインかつ、同一ディレクトリまたはサブディレクトリのコンテンツに限るという条件がつきます。これは、XMLHttpRequestでデータを読み出せる条件と一致します。

このため、実験の結論は間違ってしまいましたが、そうする理由の予測はかえって裏付けられたような気がします。ドコモは、何が何でも別ディレクトリのコンテンツをJavaScriptから読み出させたくないように思えます。だが、なぜ?

2010-07-30

オレ標準JavaScript勉強会発表資料 オレ標準JavaScript勉強会発表資料を含むブックマーク

Loading...での発表に用いた資料です。

お役に立つかどうかは心許ないのですが、ドキュメントの一部を希望されていた方もおられましたので、slideshareで公開します。

2010-07-26

携帯電話事業者に学ぶ「XSS対策」 携帯電話事業者に学ぶ「XSS対策」を含むブックマーク

NTTドコモソフトバンクモバイルは、フィーチャーフォン(いわゆるガラケー)にてJavaScriptの対応を始めています。JavaScriptに対応すると、クロスサイト・スクリプティング(XSS)脆弱性の懸念が高まりますが、両社は独自の手法によりXSS対策をしている(しようとしている)挙動が観測されましたので報告します。この内容は、オレ標準JavaScript勉強会でネタとして使ったものです。

NTTドコモに学ぶ「XSS対策」

まず、サンプルとして以下のようなXSS脆弱なスクリプトを用意します。

<?php
  session_start();
?>
<body>
こんにちは<?php echo  $_GET['p']; ?>さん
</body>

これを以下のURLで起動すると、IE7では下図のような表示になります。

http://example.com/xss01.php?p=山田<script>alert(document.cookie);</script>

f:id:ockeghem:20100726125316p:image:left


同じことをiモードブラウザ2.0で表示させると以下のようになります(P-07Aで検証)。

f:id:ockeghem:20100726130013j:image:left


見事にXSSが阻止されています…というのは早とちりで、iモードブラウザ2.0のJavaScript « mpw.jp管理人のBlogに報告されているように、iモードブラウザ2.0では、alert(やconfirm、prompt)は何もしない関数になっているのでした。このため、alert()の代わりに、document.write()を使うと、以下のようにCookieが表示されます。

f:id:ockeghem:20100726130628j:image:left


ソフトバンクに学ぶ「XSS対策」

こんどは、先ほどのalert版のURLソフトバンク端末で表示させると、やはりalertが動きません(932SHで検証)。ソフトバンクの端末ではalertは殺されていないはずなのに、不思議です。

f:id:ockeghem:20100726131024j:image:left


実はこれ、オレ標準JavaScript勉強会の準備中に見つけた現象で、しばらく悩みました。「ひょっとして、バンクさん、XSSフィルタを導入した?」、いやそんなはずは…

このときのWebサーバーのログを見ると以下のようになっています。

123.108.237.21 - - [26/Jul/2010:13:12:37 +0900] "GET /xss01.php?p=%8ER%93c HTTP/1.1" 200

「<」以降がすぱっと切られています。一種のサニタイジングというのでしょうか。なんか大胆な「対策」ですね。

でも、この「対策」、「<」や「>」をパーセントエンコードすると、以下のようにちゃんとXSSしてくれます。

f:id:ockeghem:20100726131830j:image:left


調査の結果、以下の現象が観察されました。

  • URLにおいて削除される特殊文字は、「<」、「>」、「"」の三種である。
  • SSLの場合は特殊文字はカットされない

これらから、ゲートウェイによって、上記の3種類の文字(およびそれ以降)を削除しているようです。これら三文字はURIに使えない文字なので、カットされても文句は言えないという考え方もあるでしょうが、現実には大抵の環境で使える文字ですので、ソフトバンクだけ違う挙動だととまどうと思います。

まとめ

NTTドコモおよびソフトバンクモバイルの端末がJavaScriptに対応したことにより、XSSリスクが高まっています。そのような状況で、両事業者は、典型的なXSS試験パターンを「一見動作しなくなる」という対応をしています。

しかし、これら「対策」は非常に表層的なもので、URLを少し変えるだけでXSS攻撃ができてしまいます。すなわち、XSS対策としての効果はほとんどなく、逆に副作用の方が大きいと思われます。オレ標準JavaScript勉強会でも、「alert殺したらデバッグが大変になるのでは?」という指摘がありましたが、私も同感です。

 |  
Google