mhattaによる
2007年04月04日 7時30分の掲載
マッシュアップのような穴部門より。
マッシュアップのような穴部門より。
本家/.でも話題に。JavaScript Hijackingは「an entirely new kind of web-based attack」とのこと。ITmediaの記事 Fortify、Ajaxのセキュリティ問題に警鐘 によれば、Fortify Software社が12種類(13バージョン)のAjaxフレームワークを調査したところ、「JavaScript乗っ取り」という特定の脆弱性について対抗策を講じていたものは一つしかなかったという。この脆弱性が悪用されると、ウェブサイトのユーザの機密情報が第三者に盗まれる危険がある。Fortify社のアドバイザリ(PDF)によれば、調査対象フレームワークは以下の通り: Dojo, DWR 1.1.4, DWR 2.0, GWT, jQuery, Microsoft Atlas, MochiKit, Moo.fx, Prototype, Rico, Script.aculo.us, xajax, Yahoo! UI。このうち対抗策があると言えるのはDWR 2.0のみ。またRicoとxajaxはJSON未対応のため、他より少しだけ安全であるとしている。この種の脆弱性は、過去にGoogleのGmailで発見修正されたことがあるなど、決して稀なリスクではない。安全策の早期普及が望まれる。
関連ストーリー
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
だから… (スコア:1, 参考になる)
最近はいつのまにかSpywareやtrojanを突っ込まれたりとか「よくあること」になってしまっているのに、よくAjaxのように（よほどブラウザの弱点を熟知した上で上手に作らないと）リスキーな側面を孕んでいる技術を使うもんが無闇に使われてるよな…とか思っていましたが…(;´Д`)
一年…とまではいかないまでも半年はアドバイザリ出すのが遅かったような気がするんですが(;´Д`)
--暮らしの中に修行あり。
blogはじめました。 [hatena.ne.jp]
開発プロセスによる対策 (スコア:2, 興味深い)
> プログラマーが故意に仕組むセキュリティホール（バックドアの類）の調査方法や対策
について考察するんでしょう（ここで情報が漏れるとこんだけの大きなビジネスリスクがあるからネットワークを監視するツールを別に仕込んでおこう、とかね）。
親コメント
Re:だから… (スコア:4, 参考になる)
どう注意すれば良いのかがすごく気になるのでタレコミからリンクされていたpdfを読んでみたんですが、 なんかものすごい泥縄のような・・・。
結局、
>The Web browser will send up the appropriate session cookie with the request.
ってことなんですね。cookieまで渡しちゃうとは思ってませんでした。
- HTTPXMLRequestを使ったクロスサイトAjaxは危険だから禁止された
- だけど<script>タグは例外的にクロスサイトも許可された
- 一方で、データをJavascriptのソースコードとしてやりとりする、JSONという規格が出来た
- 使いやすかったり、例外なのが便利だったりして、みんな使うようになった(?)
- JSONを不正なHTMLがクロスサイトから叩こうとしても、
- と思いきや、JavaScriptは、Objectのコンストラクタの一部を再定義することでフックできるので、上記のような配列が作られた瞬間にデータを奪うことが可能
ってことでしょうか。{"重要な", "秘密の", "データ"};
みたいなコードが実行されるだけなので(その配列はどこにも代入されない)、不正なHTML中から、その「重要な秘密のデータ」にアクセスする手段が無くて安全そう
で、対策は、(1)CookieだけじゃなくRefererも見る(いまいち安全ではない)、もしくは、 (2)正しいアクセスなら得られたJSON形式のソースコードを加工してから実行できるけど、 クロスサイトの側はただ実行することしかできないのを利用する(冒頭に"while(1);"を付けて、正しいアクセスの時はそれを削除する。不正アクセスは削除する機会が無く実行するのでハマる)。
親コメント
Re:だから… (スコア:5, 参考になる)
- XMLHttpRequestはクロスサイト禁止
- それ以外(scriptタグやimgタグのsrcなど)はクロスサイトでもGETリクエストなどでデータ取得が可能(ブラウザはそのデータを取ってくるかも知れないけど、危険HTMLページ内の危険スクリプトなどからそのデータを読みに行く方法が無いので安全)
- (a)HTML内に<script src="http://hogehoge">と書いて、hogehogeが"X={"foo","bar",baz};"という文字列を返すようにしておくと、scriptタグが解釈された時点でこの文字列がスクリプトとして実行され、データ"foo","bar","baz"の配列が、オブジェクト"X"に代入され、スクリプトからデータとして利用可能になる(実際は完了通知が必要なのでコールバック関数などを使ってやりとりする。これはクロスサイト規制外なので、クロスサイトAjaxでデータを取ってくる唯一の方法(?))
- (b)サーバは"{"foo","bar",baz};"だけを返すようにしておき、これをXMLHttpRequestで取ってきてevalで解釈する方法もある(この方法はクロスサイトではXMLHttpRequestオブジェクトがリクエストを許可しない)
- bの方法だから安心。正規ユーザが悪い人が書いたデータ強奪コードが仕込まれたサイトをブラウザで開いてしまっても、
XMLHttpRequestはクロスサイトなリクエストは遮断してくれるし、scriptタグを使って不正にクロスサイトアクセスしようとしても、「オブジェクトが生成されてどこにも代入されず消えるスクリプトが実行される」だけなので大丈夫、と思っている諸君、大丈夫じゃないよ。その実行前にフックを仕込む方法があるよ。
ですね。# だいたい、HTTPXMLRequestって何だよorz
# 新たな技が出てくる度、話がややこしくなってきて付いていくのがやっと・・・。
親コメント
Re:だから… (スコア:3, 参考になる)
僕の読解が正しければ、 Fortify の文書で扱われているのは 1 のことであり、 2 は 3 ページの脚注 4 で軽く触れられているだけです。文書中で JavaScript Hijacking と名付けているのも 1 のことです。
Prototype.js などのクライアントサイドのライブラリーが 9 ページの表に含まれている意味は、その前のページに書いてあります。 Prototype.js で JSON を使うと、サーバーから取ってきたデータを読み取るだけなので、 Prototype.js を使う限り、サーバー側では「先頭に while(1); を付ける」とか「全体を /* */ で囲む」といった JavaScript Hijacking への対処法が使えません。そのため、「Prevents JavaScript Hijacking?」の欄が No になっています。 Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, MochiKit も同様と書かれています。
親コメント
気になったのでまとめ（添削よろしく） (スコア:1, 興味深い)
前提
影響
- 秘密情報が盗まれる。
攻撃シナリオ- JSONを使用しているサイトによって、ユーザが認証される。
- 認証状態にあるユーザが悪意あるサイトを訪れる。
- 悪意あるサイトに設置されたJavaScriptにより、JSONデータが盗まれる。
回避策- (サーバサイド)HTTP REFERERをチェックし、期待したドメインでないときはデータを送出しない。
- (サーバサイド＋クライアントサイド)JSONデータに細工を施し、<script src="JSONのURL">で読み込んだときに正しく動作しないようにする。
- JSONをやめてXMLにする。
ユーザとしての回避策＃ この程度にJavaScript Hijackingと名付けるのは羊頭狗肉に思える。
＃ せいぜいCross-site JSON Robberyくらいでいいじゃないだろうか。