パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

FlashによるXSS脆弱性の突き方」記事へのコメント

  • by Anonymous Coward on 2002年06月06日 17時17分 (#103718)

    ユーザがフラッシュをアップロードできて、かつサーバ管理者がそのフラッシュが機能するように object タグやら embed タグやらを付けて表示するようにしてると危険ってことでしょ?

    Flash が危険なのか、サーバ管理者が危険なのか。

    対策としては、swf を操作できるライブラリを使って、getURL 部分を削除するってくらいか。

    次に狙われるのは、ブラウザが持ってる、JPG, GIF, PNG なんかのローダかな?

    • 最近、問題が起こる起きないを無視して「XSSだ、危険!」って雰囲気が充満していて嫌ですね。

      正しくWebアプリケーションを組んで運用していれば、Cookieを盗まれようがJavaScriptを実行されようが何も問題が起きないのに、粋がってXSS話が飛び交うここ半年(とくにここ数カ月)に凄く違和感を感じています。
      • >>>Re:そもそもXSSを「脆弱性」とするのがヘン

        痛い人だね。この人。よほど
        脆弱性にイヤな思い出があるのだろう。

        言っておくが、世界中のセキュリティー専門家が
        【危険である】と判断しているのに
        この痛い人、それが、サッパリ理解できないので
        スネているのだ。

        もはや客観の世界での判定事項に
        文句ばかりを言っているだけである。

        そんなに自説が正しいと思うのなら
        英語でキッチリ論文書いて
        BUGTRAQあたりに掲載されてみるといい。

        そのときには、認めてあげよう。勇気を。

        絶対に掲載されないけどな。
        この痛い人のような、自説無謬の
        トンデモさんは。

        もっと個人を捨てて
        公で考えなさいっての。
        --
        | 慈愛こそ慈愛
        親コメント
      • どう組めば大丈夫なのか教えてください。懇願。
        • by tty77 (4123) on 2002年06月06日 23時48分 (#103919)
          たとえばパスワードを(暗号化しようとしまいと)クッキーに入れて焼いちゃうとか。
          クッキーだけに頼ってサーバ側で照会すべき情報を保存していないとか。

          ほかにもいろいろありそう。
          僕も知りたい。懇願2。
          親コメント
        • フォームだろうがCookieだろうが、盗まれて当たり前という認識を持つことが第一なのでは?
          で、盗まれた際の被害を防ぐにはどうすれば良いのかを考えるべき。
          • 過去に、 URL にセッションIDやユーザIDなどを埋め込んで、
            セッション管理を行うことは、URL が referer その他の
            比較的容易な方法で外部から獲得できることから、「そんな
            ところに書くのが悪い、URL は公開情報と考えろ」と
            いわれたものです。
            Cookie も同じだというなら、現在の HTTP ではもうセッシ
            ョン管理のすべがありません。
            (cookie と同程度に hidden も危険&hiddenだとPOSTしか
              使えなくなる。念のため)

            ぜひ安全な方法を教えてください。
            親コメント
        • まず、結果的に悪用されて困る情報を引けなけば問題が起き様が無いですね。
          たとえばSlashdotではID/Passwordの認証後はCookieの値で認証してますが、仮にこのCookieを第三者が取得して利用しても、引き出せる情報は何ら致命的なものはありません。せいぜい本当のメールアドレスぐらいですが、これが表に出ても問題になりません。問題になるのは問題のある行動を行っている人だけですから。
          # 「匿名性」が売りな仕組みなんかは相手にしないので知りません。
          # と言いつつACで書いてるオレ。

          仮にNet銀行とか重要っぽい情報を扱わなければいけない場合で且つCookieに
          • > 仮にNet銀行とか重要っぽい情報を扱わなければいけない場合で
            > 且つCookieにSession idを含ませたい場合は、Session idを毎回
            > 検証すべきです。具体的な検証方法としてはアクセス元のIP
            > addressとSession idのハッシュ値を埋め込み検証に使用するこ
            > と等があげられます。

            Cookie が盗めるなら IP address も同時に盗めますが?
            source IP spoofing では、情報を盗む系は実現出来ないけど、
            情報更新系の攻撃は成立しそうな。
            また、

            > マルチホームなネットワークからのアクセスで、たびたび出口の
            > アドレスが変わるから不可能、とよく問題にされますがそもそも
            > そういうネットワークがどれだけ存在するかリサーチした結果な
            > のか謎です。
                :
            > また、マルチホームなネットワークユーザへの対処として、予め
            > Gatewayのアドレスを複数登録できる仕組みを用意すれば十分です。

            IPアドレスが毎回変わりうることも問題ではありますが、別の人間が
            同一IPでアクセスしうるケースが多いことのほうが問題と思ってます。
            そういう場所からアクセスすれば、IP spoofing なしで乗っ取りが可能です。
            たとえば社内のむかつくあいつのセッションをハイジャックしてやろう、とか。

            アクセス制御方式が分かって、Cookie や BASIC認証情報のような
            クライアントを識別するための情報が盗まれたら、どうしたって
            攻撃手段が残ると思いますが?
            親コメント
            • > Cookie が盗めるなら IP address も同時に盗めますが?
              > source IP spoofing では、情報を盗む系は実現出来ないけど、
              > 情報更新系の攻撃は成立しそうな。

              そもそもTCPのコネクションが確立しないって罠
              ってゆーかTCP Wrapperその他の存在意義は何処。

              後半はもはや壱アプリケーションの問題ではなくなっている罠
              • いけね、SourceIP語っただけじゃ無理だけどTCPセッションハイジャックすれば可能か。まぁXSSみたくお手軽じゃないけど。
                ってこれも既にFlashが云々の話じゃなくなってる罠...

                まぁ+SSL組み合わせればいいんじゃないの?
              • > ってこれも既にFlashが云々の話じゃなくなってる罠...
                オフトピックすまんです_o_。
                「そもそもXSSを「脆弱性」とするのがヘン」に対する反論だったもので。この時点でオフトピック化してるわけで。

                > まぁ+SSL組み合わせればいいんじゃないの?

                まだSSLの知識が万全じゃないのであれですが、サーバ証明だけじゃ、
                前コメントの後半のパターンは防げないですよね?
                SSLセッションIDを常にチェックしていればいいわけですけど、
                *ずっと*張りっぱなしなんですっけ?
                ま、いいか。また調べます_o_。

                XSSはともかくとして、ブラウザのバグで漏れることを考えると、
                開発者側としては、「盗まれて当たり前」な意識も必要とは思う。
                でも、盗まれない保証がないと完全な防御も出来ないと
                今のところ思っている。なのでBASIC認証+SSL推奨。ということで。

                あと、ページ挿げ替えとか出来る点についてはどうなのかなぁ?
                既に過去のトピックで議論されてることだからいまさら
                突っ込まなくてもいいか…。
                というわけでこの話題終わり_o_。
                親コメント
          • > せいぜい本当のメールアドレスぐらいですが、これが表に出ても
            > 問題になりません。問題になるのは問題のある行動を行っている
            > 人だけですから。

            当人にとって何が漏れたら困る情報なのかは、あなたが決めることではない。実務経験のある人ならこんな事言えないはずだよね。

            > たびたび出口のアドレスが変わるから不可能、とよく問題にされ
            > ますがそもそもそういうネットワークがどれだけ存在するかリサ
            > ーチした結果なのか謎です。

            リサーチもなにも、現に事実じゃん。例えば富士通からのアクセスは
              t3.fujitsu.co.jp
              t2.fuji
      • >正しくWebアプリケーションを組んで運用していれば、Cookieを盗まれようがJavaScriptを実行されようが何も問題が起きないのに

         話が逆。痛すぎ。 正しく組まれたWebアプリはCookie盗まれたりJavaScriptを実行されたりしない。
      • >任意のファイルを第三者がアップロードできるような房臭いサイトは使わないし
        どうやって外部に向かってFTP開いてないサイトを見分けるのだろう?
        FTPが開いてるって事は第三者がアップロードできる環境でしょう
        実際にパスクラックされてアップロードされてるかどうかは別にして

        URL見つける度にポートスキャンかますのかな?

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

処理中...