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

[DeleGate-En] Re: Delegate.org のクロスサイトスクリプティング脆弱性
02 Aug 2002 06:10:35 GMT feedback@delegate.org (Yutaka Sato)


 |> (A)(4) <plaintext>「タグ」を応答(plain)テキストの先頭に挿入 (http.c)
 |>  とっくに規格から外されたタグですが、実装上はほとんどのブラウザに通じます
 |
 |http://memo.st.ryukoku.ac.jp/archive/200206.month/4078.html
 |で述べられている手法ですね。

うーん、皆考える事は同じというわけですね。思い付いた時は、あんまりかなと
思ったんですが。

 |> (B)(3) 入力リクエストを解釈する前にクォート文字を削除 (gacl.c)
 |検索対象によっては、これで十分な対策ですが、一般的にはWebページとしての
 |出力時にクォート文字を &quot; に変換するのがよいようです。
 |そうすればクォート文字を含んだ文字列も適切に検索することが可能となります。

DeleGate自身の応答出力に関してはそうするのが適切ですし、同封したパッチでは
簡略のために省略しましたが、今回指摘して頂いた箇所についても実際そのように
修正もしています。ただこの箇所(GACL)の実装は全般にかなりやばくて他にも問題
がありましたし、クォートの要求入力が無効なことはわかっている箇所なので、
その入口で削除して問題を元から断ってしまうという対策を取りました。

この他に「(2)B 外部検索エンジン」のように、DeleGateが(リバース)プロキシ
として動作する時に、問題のあるサーバの応答出力(これはDeleGateでは変換が困難)
に対処する場合も含めて、何かうまい方法が無いかと考えたのですが、一般的に
通じる方法は原理的に無さそうです。DeleGateには以前から要求URL中の'"'を"%22"
に変換するよう設定する(HTTPCONF='urlesc:"')機能がありますが、これは有効
範囲が思ったほど広くない事が今回わかりました。実際この(2)B には効きません
でした(結局'"'と同じに扱われ生エコーされてしまう)。

 |> (2)については、www.delegate.org ではリクエストを受信した時点でURL中の
 |> '" 'や "<" を無効にしてしまうようにして回避しています。これは実際、

実はこの「無効にする」というのは、「入力中の」'"'を"&quot;"に(実際には
"%26quot%3B"に)置き換えてしまうという処理になっています(そのために
HTTPCONF=urlescを拡張しています)。実はここで使っている検索エンジンは、
検索文字列中の&quot;も'"'にマッチさせる(がエコーは&quot;とする)という
変わりもので、これにより、
<URL:http://www.delegate.org/db/search?UI=kenko&NAME=feedback&SEARCH=%22ftp%22> 
というような検索が可能になっています。

 |> ほとんどのサイトで副作用なく、ほとんどのクロスサイトスクリプティング
 |> を簡単に無効にできる方法だと思いますので、DeleGateの次のメジャー版では
 |> 標準の仕様として簡単に設定できるようにしようと思っています。
...
 |URLに使用できないはずの文字ですから、この
 |対処は適切だと私も思います。

DeleGateはプロキシとして使われることがほとんどですし、その場合にいかに
任意のサーバの脆弱性からクライアントを守ることができるかという点に
技術的な興味はあります。
リクエストURL中で"%22"のようにエスケープされていても、生の'"'と同じ
ように問題を起こしてしまう上記 (2)B のような例もありますので、正当にエス
ケープされたクォートにも対処する必要が出て来ますが、さすがにこれは一般
には通じないですね。副作用無しにまとめて入口で処置をすることは難しいよう
です。
あとは要求と応答のパターンを照合して、怪しげなエコーを検出して無効化する
ということも考えられなくも無いですが、これはそれこそ本当に火を見るまでは
やる気にならないといいますか(^^;


 |> --(6)
...
 |これは<form>を使ったExploit例を示したというだけですので、もっとできの
 |良い偽ページはいくらでも作れます。
...
 |例えば、
 |<script DEFFER>document.body.innerHTML=' 〜 '</script>

この(6)は「ブラウザでJavaScriptを無効にしても対処出来ないケース」として
出されたものです。スクリプト言語を使わずにHTMLだけで、どうやって人間を
だますかという話ですので、確かに、

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

そういう領域だと思います。

これへの対処方法としては、ブラウザの実装において「これはエラーメッセージ
の表示である。異常を示す応答である」という事をもっとはっきりユーザに解る
ように設計するということが考えられます。その点では、MSIEの「エラーの簡易
表示」というのは割と良い線なのかも知れない、とも思えます。

Cheers,
Yutaka
--
  @ @ Yutaka Sato <y.sato@delegate.org> http://www.delegate.org/y.sato/
 ( - ) National Institute of Advanced Industrial Science and Technology (AIST)
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller

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