Article delegate-en/1805 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:<_A1787@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Delegate.org のクロスサイトスクリプティング脆弱性
02 Aug 2002 03:08:41 GMT office <p6edabdyi-f4q452rxwj3r.ml@ml.delegate.org>


佐藤豊 様

officeです

ご丁寧なメールありがとうございます。修正方針等が示されて安心しました。

また

Article delegate-en/1785
http://www.delegate.org/mail-lists/delegate-en/1785
や、
Article delegate-en/1787
http://www.delegate.org/mail-lists/delegate-en/1787

のメールで、貴重なご意見を戴いていたにもかかわらず、忙しくてお答えする
ことができませんでした。申し訳ありません。

On Fri, 2 Aug 2002 01:24:12 +0900 (JST)
Article delegate-en/1800
http://www.delegate.org/mail-lists/delegate-en/1800
feedback@delegate.org (Yutaka Sato) wrote:


> (A) ブラウザによっては、HTTPのエラーメッセージを解釈する際、それが
>  text/plain型でも、text/html型と解釈してしまい、解釈・実行してしまう。
>  HTTPサーバ側でリクエスト中の文字列を、text/plainの中に生でエコー
>  している場合にも悪用可能となる。

> (A)(4) <plaintext>「タグ」を応答(plain)テキストの先頭に挿入 (http.c)
>  とっくに規格から外されたタグですが、実装上はほとんどのブラウザに通じます

http://memo.st.ryukoku.ac.jp/archive/200206.month/4078.html
で述べられている手法ですね。

> (2)については、www.delegate.org ではリクエストを受信した時点でURL中の
> '" 'や "<" を無効にしてしまうようにして回避しています。これは実際、
> ほとんどのサイトで副作用なく、ほとんどのクロスサイトスクリプティング
> を簡単に無効にできる方法だと思いますので、DeleGateの次のメジャー版では
> 標準の仕様として簡単に設定できるようにしようと思っています。

佐藤様が御自身で

> "<" をこのように生で書くことは、URLの定義上禁止されていると
> 思いますが[RFC2396:2.4.3. Excluded US-ASCII Characters]、実際のところ
> 広く許容されてしまっているようです。

と書いていらっしゃるように、URLに使用できないはずの文字ですから、この
対処は適切だと私も思います。

> (B) HTTPサーバ側でリクエスト中の文字列を、タグ中の属性値として(ブラ
>  ウザに解釈されない)クォート文字列内にエコーしている場合に、リク
>  エスト中に含まれるクォート文字を生でエコーしている場合に悪用が可能
>  となる。

> (B)(3) 入力リクエストを解釈する前にクォート文字を削除 (gacl.c)

検索対象によっては、これで十分な対策ですが、一般的にはWebページとしての
出力時にクォート文字を &quot; に変換するのがよいようです。
そうすればクォート文字を含んだ文字列も適切に検索することが可能となります。

> --(5)
>  |【脆弱点その5】
>  |delegateの設定権限を持つAdmin用の入り口とおぼしき
>  |http://www.delegate.org/-/admin/authenticate
> ...
>  |http://ID:pass@autehticated../
>  |方式のアクセスによるExploit方法が使用可能です。

> なお、このtext/html応答の中でユーザ名がエコーされるのは、そのユーザ名が
> 認証に成功しながら、アクセスは不許可の場合に限ります。(アクセスは不許可
> なので、401応答が返り、ユーザは自分が送信させられたユーザ名をダイアログ
> ボックスに見ることになりますね)
> www.delegate.orgがこの異常なユーザ名をエコーしてしまうのは、それが認証に
> は成功してしまうからです。それは、www.delegate.orgの認証サーバとして使って
> いるFTPサーバが、どのようなUSER+PASSに対してもログイン成功を返すという、
> 特殊なものだからです(anonymous以外は実際にはログインしただけで何もでき
> ない)ので、これは配布されているDeleGateに一般に起こる問題ではありません。

なるほど、報告したあと、他のDelegateサーバでいくつか試したところ、
認証を受け付けてもらえないところばかりなので、www.delegate.orgだけが特殊な
設定なのだろうなとは思っていました。了解しました。

しかし、今回のこの例は、今までにないパターンの脆弱点、Exploitであったので、
非常に興味深かったです。

> --(6)
> On 07/25/02(10:27) in <_A1782@delegate-en.ML_>
>  |http://www.delegate.org/><form/method="post"/action="http://www.office.ac/webform.cgi">...</form><!--
> 
> MSIEでも、<! は > で閉じてないとでコメントアウトにならないようですが。。。
> また、エコーする以前に何らかのエラーメッセージが出るのが通例(この場合
> Not Found:)なので、そのあたりまで消せないと異様な画面になりそうでは
> あります。

これは<form>を使ったExploit例を示したというだけですので、もっとできの
良い偽ページはいくらでも作れます。

<! を使っているのは、これは同じフォームが2回現れますが、その間に余計な
ものが表示されないようにするためだけに、適当に使っただけです。

例えば、
<script DEFFER>document.body.innerHTML=' 〜 '</script>
と組み合わせれば、ページの表示を全替えできます。

またこの辺りはソーシャルハッキングの領域にはいってきてますので、
例えNot Found: が表示されていようと、その後ろにうまい文言を付け加えて
騙す方法など、解決方法は色々あります。


細かい所をごちゃごちゃ書いてしまいましたが、そんなことより、修正して頂け
るということで大変有り難く思い感謝しています。今後とも宜しくお願いします。
--
office
p6edabdyi-f4q452rxwj3r.ml@ml.delegate.org
http://www.office.ac/

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