パスワードを忘れた？ アカウント作成
Close
2436 story

Apache+mod_perlのCSS予防法 22

ストーリー by Oliver
ユーザを信じるな 部門より

k3c 曰く、 "CSSといってもカスケーディングスタイルシートではありません。最近なにかと話題を巻き起こしているクロスサイトスクリプティング脆弱性の方です。Apache+mod_perlで運用しているWebサイトにおいてこの脆弱性を予防する方法がperl.comの記事で紹介されています。Apache::Requestモジュールの代わりにApache::TaintRequestモジュールを使えば、フォームのインプットから自動的に<や>や"やその他アヤシゲな文字をエスケープしてくれるんだそうです。
Apache+mod_perlなWebサイトが増えつづけているようですが、そのうちどれほどがこういう対策に労力を割いているんでしょうか。"

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

Apache+mod_perlのCSS予防法 More

  • この対処法は本当に使いものになるのか？ (スコア:3, すばらしい洞察)

    by jbeef (1278) on 2002年03月02日 19時59分 (#68048) 日記
    Apache::Requestモジュールの代わりにApache::TaintRequestモジュールを使えば、フォームのインプットから自動的にや"やその他アヤシゲな文字をエスケープしてくれる
    入力に対してフィルタリングするのかな？と読めたのですが、そうではなく、出力時にエスケープ処理を施すのですよね。で、全部をエスケープしてしまうと、タグ自身を書き出す部分で困るので、Perlのtaintモード機能を活用して、入力に依存している変数をprintするときだけエスケープするようにしたと。

    この方法では次の問題が考えられるのではないでしょうか。

    • 出力したいタグ文字列に、入力文字列を連結して、変数に入れている場合に、それをprintしようとすると、タグ部分も含めてエスケープされてしまい、正常に動作しなくなる。
    • FORMからの入力だけでなく、データベースから取得してきたデータに対してもエスケープが必要だが、それもtaintモードでtaintedと認識されるのか？
    私がおすすめする対策は以下のものです。
    • HTMLにおける文字列出力は、基本は、すべてをエスケープしながらするものと考える。
    • 例外的に、タグそのものを出力するときだけ、エスケープしないようにコーディングする。
    一から開発するときは、これはけっこう簡単なことだと思います。セキュリティ問題以前に、元々こうするべきことなのですし。

    問題なのは、クロスサイトスクリプティングのことを考えずに一旦作ってしまったモノに対して、後から緊急に対策をする場合です。入力値に依存しそうなところだけ目を皿にして探して対策するのでは、必ず見落としが出てくるでしょう。そういうときの緊急避難に使えるのが、今回ネタにたれ込まれた方法と言えるかもしれません。がしかし、上に述べたように、必要以上にエスケープしてしまったり、不完全だったりして、使えないのではないでしょうか。

    やはり、緊急対策の場合も、すべての文字列出力をエスケープするようにする（タグを出力するところだけ目を皿にして探す）のが妥当のように思えますが、いかがか。

    • perl.comの記事にこのモジュールの使用例があるのですが、
      use Apache::TaintRequest;

      my $apr = Apache::TaintRequest->new(Apache->request);

      my $text = $apr->param('text');

      $r->content_type("text/html");
      $r->send_http_header;

      $r->print("You entered ", $text);

      $text =~ s/[^A-Za-z0-9 ]//;
      $r->print("You entered ", $text);
      ということで（説明になってないか…）、入力をフィルタリングしてから変数に格納する、というのがこのモジュールの機能です。
      既にデータベースに格納されているものに対しては対策にならない、というのは、その通りです。それはデータベースから引き出す窓口をなるべく少なくして、その部分で除染するとか、そういう対策が必要でしょう。
      しかし少なくとも、このモジュールを通しておけばタグはみんなエスケープされる、というものがあれば、その後の設計はかなり楽になると思います。入力はみんな片っ端からそのモジュールを通せばいいわけですから。

      あと、当然のことですが、タグだけエスケープしてクロスサイトスクリプティングだけ防げば他の対策は何もしなくていいというわけではないですよね。バッファオーバーフローだって気を付けなきゃいけないし、他にもいろいろありますよね…。

      私がこれを紹介したのは、クロスサイトスクリプティング対策の一つとしてこんなのどうですか？というつもりでした。もちろんこれだけでいいというつもりは毛頭ありません。Apache::TaintRequestを使って、かつ出力側でも対策すれば、さらにデータベースの書き込み・読み出しも対策すれば、より心強いのは言うまでもありません。あとからソースコードに手を入れる人がApache::TaintRequestを使わずにApache::Requestを使ってしまう可能性だってあるわけですから。

      ちょっと言い訳がましいですが、ワタシの意見としてはこんなところです。
      シェア
      親コメント

  • CSSという略（微妙におふとぴ） (スコア:2, 参考になる)

    by oddmake (1445) on 2002年03月02日 14時33分 (#67960) 日記
    クロスサイトスクリプティングをCSSと略すとカスケーディングスタイルシートと紛らわしく感じます。
    このトピックスもひょっとしてApacheでカスケーディングスタイルシートの適用を予防すると勘違い･･･する人はいないか。流石に。
    ＃でもCSS対処法って書いたらあるいはperlでスタイルシートを生成することだと･･･思わないか。
    で、個人的にはXSSって呼んでみたらいいんじゃないかなと思うんですがどうでしょうね。使われて広まわらなければどうしようもないですが。
    --
    /.configure;oddmake;oddmake install

    • XSS (スコア:2, 参考になる)

      by yourCat (4820) <yourcatNO@SPAMusers.sourceforge.jp> on 2002年03月02日 18時20分 (#68021) ホームページ 日記
      で、個人的にはXSSって呼んでみたらいいんじゃないかなと思うんですがどうでしょうね。使われて広まわらなければどうしようもないですが。
      XSSも結構使われ出していますよ。HotWiredでもXSSと書かれました [lycos.com]し、/.JでもXSSと書いてしまっていいともいます。少しはXSSという言葉を広める手助けになるのでは。

      Googleで"Cross Site Scripting"を検索すると、コメント執筆段階で;

      • +CSS [google.co.jp]: 2130件
      • +XSS [google.co.jp]: 69件
      なので、CSSの方が通りがいいようですが、「CSS: Cascading Style SheetじゃなくてCross Site Scripting」という註をいれる必要があるくらいなら「XSS: Cross(X) Site Scripting」と入れる方がスマートですよね :)。
      シェア
      親コメント

      • Re:XSS (スコア:1)

        by k3c (4386) on 2002年03月03日 1時00分 (#68148) ホームページ 日記
        えー、タレコミ本人です。
        ご指摘ありがとうございます。タイトルの文字数には制限があるようで、ここでタイトルにクロスサイトスクリプティングと書くと過去の経験から言ってタブン制限を越えてしまうと思ったので、タイトルではCSSと書き、本文で注釈を付けました。

        XSSというのは思いつきもしませんでした。うむ、これからはそう略することにします。でも、どっちにしても、当分、本文で一度は「クロスサイトスクリプティング」と注釈せねばならぬのでしょうね…そもそもメディアに全然出ないもんなあ、この言葉…ぶつぶつ…。
        シェア
        親コメント

      • Re:XSS (スコア:1)

        by atrib (5512) on 2002年03月03日 1時00分 (#68149)
        "CSSV"ではダメなのでしょうか？？
        シェア
        親コメント

      • Re:XSS (スコア:1, 参考になる)

        by Anonymous Coward on 2002年03月03日 1時01分 (#68150)

        "XSS"って呼称はいいですね。自分も使おうっと。

        HotWiredでもXSSと書かれました[lycos.com]

        これは、日本語訳 [hotwired.co.jp]もあります。 クロスサイトスクリプティング問題の説明としても優れたものだと思います。

        シェア
        親コメント

  • /.は大丈夫？ (スコア:1)

    by naa (162) on 2002年03月02日 11時56分 (#67929) 日記
    クロスサイトスクリプティングですか。
    ここ（slashdot）もPerlを使っていると思いますが、対策は十分なのでしょうか？

    >そのうちどれほどがこういう対策に労力を割いているんでしょうか。

    という言葉は、/.にも向けられるべきと思うが、いかがかな？

    #/.は対策をしていないとはどこにも書いていないが、対策済みとも書いていないんだよな。ちょっと不安。
      • その後の書き込みを見ると、office氏が単なるセキュリティ・ゴロ
        という疑いを拭いきれない。
        /.-Jにご執心のようですね。
        ＃Tea Roomは毎日拝見しております。
        • これだわね。 [sourceforge.net]

          SourceForge の見られ方とか、責任分岐点のあり方とか、
          かなりの意識の違いがあるとしか思えない。

          /.-Jも/.もスクリプトを前提としてはいないでしょ。
          「なもの、ブラウザの責任だ」といいたいに違いない。
          勝手にデータを渡すのは、ブラウザだよ?
          「IE(NN/NC)よ、そんなけったいな要求を通してくれるな」と
          考えるのが普通では無かろうか。

          けったいな要求を通すものを前提として動くなら、
          それなりの対策は必要でしょうが。
          シェア
          親コメント

          • 免責 (スコア:3, 参考になる)

            by jbeef (1278) on 2002年03月02日 17時44分 (#68010) 日記
            /.-Jも/.もスクリプトを前提としてはいないでしょ。 「なもの、ブラウザの責任だ」といいたいに違いない。 勝手にデータを渡すのは、ブラウザだよ?
            デフォルト設定でブラウザスクリプトが動作するのが通常なのだから、その言い逃れはできないでしょう。もしそれを主張するなら、最低限でも次の免責条項を目立つところ（ユーザ登録画面など）に掲示しておく必要があるでしょう。

            当サイトではJavaScriptなどのブラウザスクリプトを使用していないため、スクリプトをオフに設定しても正常に動作します。また、利用者がスクリプトをオフにしていることを前提として、安全対策をしているため、スクリプトをオンにしていることによって生ずるいかなる事故についても、当サイトは責任を負いません。当サイトをスクリプトをオンでご利用される方は自己責任でお願いします。

            シェア
            親コメント

            • Re:免責 (スコア:1)

              by naka64 (4590) on 2002年03月03日 0時30分 (#68136) 日記
              そこが「言わずもがな」の内側か外側かというのが、最初と現況とで変わっていると言うことなんでしょうね。
              ScriptKidの感情論を演じてみたと言うことでお許し下さい
              シェア
              親コメント

            • Re:免責 (スコア:1)

              by tix (7637) on 2002年03月06日 0時26分 (#69185) ホームページ
              このような免責条項を載せることは賛成ですが、これを載せたとしてもやっぱり多くのユーザを抱えるサイトである以上、 XSS が見つかったら直してほしいことは直してほしいです。社会的責任とか言うつもりはなく、単にぼくが嬉しいというか何というか :-)

              それと、
              JavaScriptなどのブラウザスクリプトを使用していないため
              JavaScript は使われています。 JavaScript がオフでも正常に動作するというのは正しいですが。

              ぼくはスクリプトを見て、スクリプトの目的は HTML ファイルがキャッシュに入っていても広告だけは毎回ダウンロードし直させることだと思いましたが、違う意図かもしれません（失礼、 SLASH のコードを読んだことはありません）。

              （スレッド違いますが） XSS という略語は紛らわしくなくていいですね。今まで CSS と書くのも躊躇して、結局毎回「クロスサイトスクリプティング」と書いていたので、 XSS 採用決定。広まって定着してほしいです（世の中に XSS という略語が広まるより、 XSS がなくなってくれたほうが格段に嬉しいですが、現実的なほうで……）。
              --
              鵜呑みにしてみる？
              シェア
              親コメント

          • Re:/.は大丈夫？ (スコア:3, 参考になる)

            by jbeef (1278) on 2002年03月02日 19時00分 (#68029) 日記
            これだわね。 [sourceforge.net]
            そこから引用すると、
            This is a bug, but not a vulnerability, as there is no exploit. It may be possible for a logged-in user to send his or her own cookie to a website of his or her choice, by cleverly concocting an email address with quote and angle bracket. But the user had to have his or her own cookie already, to be logged-in, so there is no new information revealed, and no escalation of privileges.
            取り急ぎ訳：
            これはバグではあるが、exploitが無いので、脆弱性ではない。 ログイン中のユーザは、 彼/彼女の選択のもと、どこかのWebサイトに、 彼/彼女の所有するcookieを送信することが、 「"」や「<」を含めて器用に作り上げられたメールアドレスによって、 可能かもしれない。 しかし、そのユーザは、ログインのために、 彼/彼女の所有するcookieを既に持つ必要があったのだから、 何も新しい情報が露わになるわけでなく、何ら特権の拡大があるわけでもない。
            どうやら、slashcodeの開発者は、このときまで、クロスサイトスクリプティング脆弱性を正しく理解なさっていなかったようです。

            （それ以前にも、 パターンA [sourceforge.net]、 パターンB [sourceforge.net]、 パターンC [sourceforge.net] と3回も指摘があったにもかかわらず。さらに言うと、jbeefがslashdot.jpに連絡した2件 [srad.jp]はこれらとも別パターンなので、少なくとも5パターンが過去にあったのかな。）

            そして、その修正から6時間後、さらに新たにクロスサイトスクリプティング脆弱性が指摘 [sourceforge.net]されています。 このときようやく問題点を正しく理解なさったようで、このときは、

            Please send security-related issues to us privately (malda@slashdot.org is a good place) and give us a chance to fix them before posting exploits.
            という反応があり、そして、 ご本人からBUGTRAQへ報告がなされる [securityfocus.com]こととなったようです。
            [SA-2002:01] Slashcode login vulnerability
            RISK FACTOR: HIGH
            The attacker can then take over the user's account. If the user is an administrator of the victim Slash website, the attacker can take nearly full control of that site (post and delete stories, edit users, post as other users, etc.).
            取り急ぎ訳：
            そして攻撃者はユーザのアカウントを乗っ取ることができる。 もしそのユーザが、その被害者Slashサイトの管理者であるならば、 攻撃者はそのサイトのほぼ完全な制御を奪うことができる （ストーリを投稿したり削除したり、ユーザを編集したり、 別のユーザとして投稿したり、など）。
            シェア
            親コメント
typodupeerror

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson