Fortify、Ajaxのセキュリティ問題に警鐘 28
ストーリー by mhatta
マッシュアップのような穴 部門より
マッシュアップのような穴 部門より
本家/.でも話題に。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のように(よほどブラウザの弱点を熟知した上で上手に作らないと)リスキーな側面を孕んでいる技術を使うもんが無闇に使われてるよな…とか思っていましたが…(;´Д`)
一年…とまではいかないまでも半年はアドバイザリ出すのが遅かったような気がするんですが(;´Д`)
Re:だから… (スコア:1, 興味深い)
> 無闇に使われてるよな…とか思っていましたが…(;´Д`)
あなたは知らないかもしれませんが、
地方銀行ですが業務系のシステムをVB6辺りで素人同然のプログラマーがシコシコ作った
システムが動いていたり
某大手企業でも中国人に依頼して動作テストのみを行ったプログラムを平気で使ったりしています
今後問題になりそうな事柄として、
プログラマーが故意に仕組むセキュリティホール(バックドアの類)の調査方法や
対策が今後増えると思います(特に作りっパで逃げそうな中国人等)
安いからといって顧客の国を敵国として認識しているような人種に仕事出すのは如何なものかな…
開発プロセスによる対策 (スコア:2, 興味深い)
> プログラマーが故意に仕組むセキュリティホール(バックドアの類)の調査方法や対策
について考察するんでしょう(ここで情報が漏れるとこんだけの大きなビジネスリスクがあるからネットワークを監視するツールを別に仕込んでおこう、とかね)。
Re:だから… (スコア:0)
以下の部分を具体的に述べない限り、意味はないでしょう。
>よほどブラウザの弱点を熟知した上で上手に作らないと
Re:だから… (スコア:0)
それとも、「よほどブラウザの弱点を熟知するという事など不可能だ。」という主張ですか?
# 猿でもいえるには同意しますが、意味がないとはどういう事?
Re:だから… (スコア:0)
「『上手に』の内容を具体的に書かないと意味がない」という主張でしょう。
Re:だから… (スコア:0)
そりゃ問題は「手抜き」の方にある訳で、物自体が云々ってモンでは無いですよ。
まあ、その辺りを考えて作ってナンボのフレームワーク自体が、って点は確かに問題ですが、それだって「作った奴が問題」ってだけの事だし、内部使用しか考えて作られていないものであれば、それを「外部で使うと判断した者が問題」な訳だし。
#元々利便性の為に手抜きする為のモンみたいな物だしねぇ。それをトレンドだけで使うからイカンってだけだよなぁ。
Re:だから… (スコア:4, 参考になる)
どう注意すれば良いのかがすごく気になるのでタレコミからリンクされていたpdfを読んでみたんですが、 なんかものすごい泥縄のような・・・。
結局、
>The Web browser will send up the appropriate session cookie with the request.
ってことなんですね。cookieまで渡しちゃうとは思ってませんでした。
{"重要な", "秘密の", "データ"};
みたいなコードが実行されるだけなので(その配列はどこにも代入されない)、不正なHTML中から、その「重要な秘密のデータ」にアクセスする手段が無くて安全そう
で、対策は、(1)CookieだけじゃなくRefererも見る(いまいち安全ではない)、もしくは、 (2)正しいアクセスなら得られたJSON形式のソースコードを加工してから実行できるけど、 クロスサイトの側はただ実行することしかできないのを利用する(冒頭に"while(1);"を付けて、正しいアクセスの時はそれを削除する。不正アクセスは削除する機会が無く実行するのでハマる)。
Re:だから… (スコア:5, 参考になる)
# だいたい、HTTPXMLRequestって何だよorz
# 新たな技が出てくる度、話がややこしくなってきて付いていくのがやっと・・・。
Re:だから… (スコア:0)
googleもやってますね
Re:だから… (スコア:1, 参考になる)
そもそも今となってはHTTPセッションが癌のように思うし。
なんかPDFでは二種類の脆弱性について述べている気がするんだけど
1.(セッションが残ってる状態で?)悪意のあるサイトからサービスを呼ばれたとき、サーバ側でノーチェックだとそのまま情報が抜かれる
2.クライアント側で無闇にevalすんなハゲ
12種類のフレームワークについて調査したとか言ってるけど、1についてはクライアントサイドだけでどうにかなる話じゃないので
DWR、GWT、Microsoft Atlas、xajax以外はあんまり関係ない話だと思うんだけど、何を思ってごっちゃに調査したのかな。
JavaScript Hijackingなどと一つの名前で語ることじゃないような。
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 も同様と書かれています。
Re:だから… (スコア:0)
インターネットで何でもやれるようにしましょう、PCで何でもやれるようにしましょう、
って流れにももっと噛みついたらいいのに(笑)
気になったのでまとめ(添削よろしく) (スコア:1, 興味深い)
前提
影響
# この程度にJavaScript Hijackingと名付けるのは羊頭狗肉に思える。
# せいぜいCross-site JSON Robberyくらいでいいじゃないだろうか。
Re:気になったのでまとめ(添削よろしく) (スコア:1)
・CSRFの対策と同じように、Cookieの内容をパラメータとして送信したリクエストにしか応答しない
・POSTにしか応答しない
ってのも書いてあります。
あと、手元で試した所、Firefox2.0.0.3では
var objectArray = [];
function Object()
{
objectArray.push(this);
}
って感じのコードでHookできました。
例示されているsetterの記法はIE6.0では有効にならず、上記のコードでも取れませんでした。
IEでは動作しないんですかね?
Re:気になったのでまとめ(添削よろしく) (スコア:0)
> this paper, are written for Mozillabased
> browsers. We have taken this approach for brevity and clarity.
> All of the examples in the
> paper could be adapted to work under Internet Explorer too,
> meaning that the great majority of
> web browsers in use today will permit JavaScript Hijacking.
と書いてるので、具体的なexploitはペーパーに示されていませんが可能なのでしょう。
Re:気になったのでまとめ(添削よろしく) (スコア:0)
一例 [p2b.jp]
>SafariでもIE6でもFirefoxでもきちんと動く
Re:気になったのでまとめ(添削よろしく) (スコア:1)
??? それはメソッドの上書きなのであって、今回の件とは関係なくない?
JSON がフィールドとして使うことがわかっている名前に setter を忍ばせておくことによって、JSON を「実行」させるときにフックできる、という話なので、その setter が IE6.0 では使えないというのであれば、確かに IE6.0 ユーザーには及ばない脆弱性、ということになるんだと思うのですが。
Firefox は Object のコンストラクタ定義だけでもいけちゃうってことなのね (IE6 はダメ?)。これは。。。あとで試してみますか。
むらちより/あい/をこめて。
Re:気になったのでまとめ(添削よろしく) (スコア:1)
回避策には、「POST のみ受け付けるようにし、GET は受け付けないようにする」も含まれるみたいです。
むらちより/あい/をこめて。
Re:気になったのでまとめ(添削よろしく) (スコア:0)
ってあなた。
これだけできれば、ちょっと考えれば。。。
あまりこの手のことに首を突っ込まないことをおすすめします。
すこし勉強してから投稿したほうがピントはずれにならないでしょう。
Re:気になったのでまとめ(添削よろしく) (スコア:0)
Re:気になったのでまとめ(添削よろしく) (スコア:0)
昔、CGIをperlで書く場合の注意事項として、evalは使うなって言われてた気がするが、どの解説書でもevalを使っているんだよね。perlじゃ駄目だけどJavaScriptだと良いってのがわけ分からん。
JSONがRFCに登録されたのも拍車を掛けている気がする。JSON自体に罪は無いんだが。
あと、JavaScriptのプログラマってセキュリティに対して関心が無いように見える。WEBデザイナからの転向組が多いせいなの?
Re:気になったのでまとめ(添削よろしく) (スコア:0)
サーバサイドでevalするのは、クライアントからの悪意ある指示をサーバ上で実行できてしまう危険性があります。
クライアントサイドでevalしても、悪意ある指示があっても実行するのはクライアントの中だけです。そもそも今回の危険性はサーバから任意のクライアントに秘密情報が渡されるということですから、evalとは何の関係もないです。
「evalだからダメ」だと、単なる思考停止です。
歴史は繰り返す (スコア:0)
→数年後に新しい技術っぽく見える形で再浮上
っていう一連のアレですか?
原因と対策 (スコア:0)
対策:sshでvnc
そしてvncサーバからajaxとか(ォィ
JSONPだと (スコア:0)