パスワードを忘れた? アカウント作成
15065 story

Fortify、Ajaxのセキュリティ問題に警鐘 28

ストーリー by mhatta
マッシュアップのような穴 部門より

vn 曰く

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で発見修正されたことがあるなど、決して稀なリスクではない。安全策の早期普及が望まれる。

本家/.でも話題に。JavaScript Hijackingは「an entirely new kind of web-based attack」とのこと。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • だから… (スコア:1, 参考になる)

    by Artane. (1042) on 2007年04月04日 8時25分 (#1136985) ホームページ 日記
    一昔前に流行ったシンクライアント構想よろしく、WEBブラウザで何でもやれるようにしましょう。っていうポリシー自体が現状のWEBブラウザなどのアプリケーションの品質管理技術のレベルでは危険過ぎるのは、何度もJavaScriptやらActiveXやらの脆弱性やそれらのシステムとの密着度の高さとの相関関係で指摘されていたし、
    最近はいつのまにかSpywareやtrojanを突っ込まれたりとか「よくあること」になってしまっているのに、よくAjaxのように(よほどブラウザの弱点を熟知した上で上手に作らないと)リスキーな側面を孕んでいる技術を使うもんが無闇に使われてるよな…とか思っていましたが…(;´Д`)
    一年…とまではいかないまでも半年はアドバイザリ出すのが遅かったような気がするんですが(;´Д`)
    • Re:だから… (スコア:1, 興味深い)

      by Anonymous Coward on 2007年04月04日 9時49分 (#1137031)
      > 熟知した上で上手に作らないと)リスキーな側面を孕んでいる技術を使うもんが
      > 無闇に使われてるよな…とか思っていましたが…(;´Д`)

      あなたは知らないかもしれませんが、
      地方銀行ですが業務系のシステムをVB6辺りで素人同然のプログラマーがシコシコ作った
      システムが動いていたり
      某大手企業でも中国人に依頼して動作テストのみを行ったプログラムを平気で使ったりしています

      今後問題になりそうな事柄として、
      プログラマーが故意に仕組むセキュリティホール(バックドアの類)の調査方法や
      対策が今後増えると思います(特に作りっパで逃げそうな中国人等)
      安いからといって顧客の国を敵国として認識しているような人種に仕事出すのは如何なものかな…

      親コメント
      • by superfox (31908) on 2007年04月04日 11時36分 (#1137097)
        自分の知識だとプロセスによる対策としては工程FMEA [wikipedia.org]が近いかな?この中で

        > プログラマーが故意に仕組むセキュリティホール(バックドアの類)の調査方法や対策

        について考察するんでしょう(ここで情報が漏れるとこんだけの大きなビジネスリスクがあるからネットワークを監視するツールを別に仕込んでおこう、とかね)。
        親コメント
    • by Anonymous Coward
      他の煽りコメントと一緒で、そこまでなら猿でも言えると思います。
      以下の部分を具体的に述べない限り、意味はないでしょう。

      >よほどブラウザの弱点を熟知した上で上手に作らないと
      • by Anonymous Coward
        「よほどブラウザの弱点を熟知したところで、問題なく作る事は不可能だ。」という主張ですか?
        それとも、「よほどブラウザの弱点を熟知するという事など不可能だ。」という主張ですか?

        # 猿でもいえるには同意しますが、意味がないとはどういう事?
        • by Anonymous Coward
          元コメントの主とは違いますが、「不可能だ」なんてどこに書いてありますか?
          「『上手に』の内容を具体的に書かないと意味がない」という主張でしょう。
    • by Anonymous Coward
      本来は注意深く実装する必要がある物を、手抜きしちゃって居る物があるってだけの話だと思いますが。

      そりゃ問題は「手抜き」の方にある訳で、物自体が云々ってモンでは無いですよ。

      まあ、その辺りを考えて作ってナンボのフレームワーク自体が、って点は確かに問題ですが、それだって「作った奴が問題」ってだけの事だし、内部使用しか考えて作られていないものであれば、それを「外部で使うと判断した者が問題」な訳だし。

      #元々利便性の為に手抜きする為のモンみたいな物だしねぇ。それをトレンドだけで使うからイカンってだけだよなぁ。

      • Re:だから… (スコア:4, 参考になる)

        by s02222 (20350) on 2007年04月04日 11時34分 (#1137096)
        >本来は注意深く実装する必要がある物を、手抜きしちゃって居る物があるってだけの話だと思いますが。

        どう注意すれば良いのかがすごく気になるのでタレコミからリンクされていたpdfを読んでみたんですが、 なんかものすごい泥縄のような・・・。

        結局、
        >The Web browser will send up the appropriate session cookie with the request.
        ってことなんですね。cookieまで渡しちゃうとは思ってませんでした。
        • HTTPXMLRequestを使ったクロスサイトAjaxは危険だから禁止された
        • だけど<script>タグは例外的にクロスサイトも許可された
        • 一方で、データをJavascriptのソースコードとしてやりとりする、JSONという規格が出来た
        • 使いやすかったり、例外なのが便利だったりして、みんな使うようになった(?)
        • JSONを不正なHTMLがクロスサイトから叩こうとしても、
            {"重要な", "秘密の", "データ"};
            みたいなコードが実行されるだけなので(その配列はどこにも代入されない)、不正なHTML中から、その「重要な秘密のデータ」にアクセスする手段が無くて安全そう
        • と思いきや、JavaScriptは、Objectのコンストラクタの一部を再定義することでフックできるので、上記のような配列が作られた瞬間にデータを奪うことが可能
        ってことでしょうか。

        で、対策は、(1)CookieだけじゃなくRefererも見る(いまいち安全ではない)、もしくは、 (2)正しいアクセスなら得られたJSON形式のソースコードを加工してから実行できるけど、 クロスサイトの側はただ実行することしかできないのを利用する(冒頭に"while(1);"を付けて、正しいアクセスの時はそれを削除する。不正アクセスは削除する機会が無く実行するのでハマる)。
        親コメント
        • Re:だから… (スコア:5, 参考になる)

          by s02222 (20350) on 2007年04月04日 14時57分 (#1137210)
          読みながら書いたらいまいち正確じゃなく見通しの悪い文章になっていたので自己訂正補足。

          • 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
          # 新たな技が出てくる度、話がややこしくなってきて付いていくのがやっと・・・。
          親コメント
        • by Anonymous Coward
          >(冒頭に"while(1);"を付けて、正しいアクセスの時はそれを削除する。不正アクセスは削除する機会が無く実行するのでハマる)。

          googleもやってますね
      • Re:だから… (スコア:1, 参考になる)

        by Anonymous Coward on 2007年04月04日 11時43分 (#1137104)
        注意深くしても現状では絶対安全なのは無理じゃないのかな。
        そもそも今となってはHTTPセッションが癌のように思うし。

        なんかPDFでは二種類の脆弱性について述べている気がするんだけど
        1.(セッションが残ってる状態で?)悪意のあるサイトからサービスを呼ばれたとき、サーバ側でノーチェックだとそのまま情報が抜かれる
        2.クライアント側で無闇にevalすんなハゲ

        12種類のフレームワークについて調査したとか言ってるけど、1についてはクライアントサイドだけでどうにかなる話じゃないので
        DWR、GWT、Microsoft Atlas、xajax以外はあんまり関係ない話だと思うんだけど、何を思ってごっちゃに調査したのかな。
        JavaScript Hijackingなどと一つの名前で語ることじゃないような。
        親コメント
        • Re:だから… (スコア:3, 参考になる)

          by fcp (32783) on 2007年04月04日 13時46分 (#1137180) ホームページ 日記

          なんか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 も同様と書かれています。

          親コメント
    • by Anonymous Coward
      なんで対象がWEBブラウザだからってそんなことを言うのかな。
      インターネットで何でもやれるようにしましょう、PCで何でもやれるようにしましょう、
      って流れにももっと噛みついたらいいのに(笑)
  • by Anonymous Coward on 2007年04月04日 23時12分 (#1137421)

    前提

    • JSONでデータをやりとりしている。
    • データ中に秘密情報が含まれる。

    影響

    • 秘密情報が盗まれる。
    攻撃シナリオ
    1. JSONを使用しているサイトによって、ユーザが認証される。
    2. 認証状態にあるユーザが悪意あるサイトを訪れる。
    3. 悪意あるサイトに設置されたJavaScriptにより、JSONデータが盗まれる。
    回避策
    • (サーバサイド)HTTP REFERERをチェックし、期待したドメインでないときはデータを送出しない。
    • (サーバサイド+クライアントサイド)JSONデータに細工を施し、<script src="JSONのURL">で読み込んだときに正しく動作しないようにする。
    • JSONをやめてXMLにする。
    ユーザとしての回避策
    • 信頼できるサイトでのみJavaScriptを使用するようにブラウザを設定する。


    # この程度にJavaScript Hijackingと名付けるのは羊頭狗肉に思える。
    # せいぜいCross-site JSON Robberyくらいでいいじゃないだろうか。

    • サーバサイドでの対策として、
      ・CSRFの対策と同じように、Cookieの内容をパラメータとして送信したリクエストにしか応答しない
      ・POSTにしか応答しない
      ってのも書いてあります。

      あと、手元で試した所、Firefox2.0.0.3では
      var objectArray = [];
      function Object()
      {
          objectArray.push(this);
      }
      って感じのコードでHookできました。

      例示されているsetterの記法はIE6.0では有効にならず、上記のコードでも取れませんでした。
      IEでは動作しないんですかね?

      親コメント
      • > Note that this example, as well as the rest of the examples in
        > 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はペーパーに示されていませんが可能なのでしょう。
      • 他所でポピュラーに使われている記法が動かない事はないかと。

        一例 [p2b.jp]
        >SafariでもIE6でもFirefoxでもきちんと動く
        • ??? それはメソッドの上書きなのであって、今回の件とは関係なくない?

          JSON がフィールドとして使うことがわかっている名前に setter を忍ばせておくことによって、JSON を「実行」させるときにフックできる、という話なので、その setter が IE6.0 では使えないというのであれば、確かに IE6.0 ユーザーには及ばない脆弱性、ということになるんだと思うのですが。

          Firefox は Object のコンストラクタ定義だけでもいけちゃうってことなのね (IE6 はダメ?)。これは。。。あとで試してみますか。

          --
          むらちより/あい/をこめて。
          親コメント
    • 回避策には、「POST のみ受け付けるようにし、GET は受け付けないようにする」も含まれるみたいです。

      --
      むらちより/あい/をこめて。
      親コメント
    • >この程度にJavaScript Hijacking
      ってあなた。
      これだけできれば、ちょっと考えれば。。。
      あまりこの手のことに首を突っ込まないことをおすすめします。
      すこし勉強してから投稿したほうがピントはずれにならないでしょう。
    • Ajaxの解説とか入門とか見ると、どれもJSONの使用をプッシュしていて、そのJSONのパースはevalで行っているというのが問題の根幹だと思う。
      昔、CGIをperlで書く場合の注意事項として、evalは使うなって言われてた気がするが、どの解説書でもevalを使っているんだよね。perlじゃ駄目だけどJavaScriptだと良いってのがわけ分からん。
      JSONがRFCに登録されたのも拍車を掛けている気がする。JSON自体に罪は無いんだが。

      あと、JavaScriptのプログラマってセキュリティに対して関心が無いように見える。WEBデザイナからの転向組が多いせいなの?
      • サーバサイドでevalすることと、クライアントサイドでevalすることの意味は全然違いますよ。

        サーバサイドでevalするのは、クライアントからの悪意ある指示をサーバ上で実行できてしまう危険性があります。

        クライアントサイドでevalしても、悪意ある指示があっても実行するのはクライアントの中だけです。そもそも今回の危険性はサーバから任意のクライアントに秘密情報が渡されるということですから、evalとは何の関係もないです。

        「evalだからダメ」だと、単なる思考停止です。
  • by Anonymous Coward on 2007年04月04日 9時20分 (#1137017)
    危険だからJavaScriptはOFF!!
    →数年後に新しい技術っぽく見える形で再浮上

    っていう一連のアレですか?
  • by Anonymous Coward on 2007年04月04日 16時47分 (#1137261)
    原因:webアプリにセキュティを期待するのが間違いです
    対策:sshでvnc
       そしてvncサーバからajaxとか(ォィ
  • by Anonymous Coward on 2007年04月05日 2時48分 (#1137489)
    JSONPだと指定したコールバック関数を呼んでくれる形になるので、小細工無しでゲットできてしまうような。
typodupeerror

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

読み込み中...