アカウント名:
パスワード:
そりゃ問題は「手抜き」の方にある訳で、物自体が云々ってモンでは無いですよ。
まあ、その辺りを考えて作ってナンボのフレームワーク自体が、って点は確かに問題ですが、それだって「作った奴が問題」ってだけの事だし、内部使用しか考えて作られていないものであれば、それを「外部で使うと判断した者が問題」な訳だし。
#元々利便性の為に手抜きする為のモンみたいな物だしねぇ。それをトレンドだけで使うからイカンってだけだよなぁ。
なんかPDFでは二種類の脆弱性について述べている気がするんだけど 1.(セッションが残ってる状態で?)悪意のあるサイトからサービスを呼ばれたとき、サーバ側でノーチェックだとそのまま情報が抜かれる 2.クライアント側で無闇にevalすんなハゲ
僕の読解が正しければ、 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 も同様と書かれています。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
だから… (スコア: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で何でもやれるようにしましょう、
って流れにももっと噛みついたらいいのに(笑)