水無月ばけらのえび日記

DOM万歳(XSS大王つづき)

いろいろいじっていて、こういう exploit を思いつきました。

フォームは本物なのですが、その送り先だけを DOM なスクリプトで改竄するという荒技です。method は書き換えなくても良いのですが、http://altba.com/ が GET しか受け付けないのでこうしてみました。あとは GET にすると入力値が URL として表示されますので、漏洩していることがわかりやすいというメリットもあります。もちろん、実際の犯行時は POST のままの方がバレにくいです。

……こんなのが何処で使えるのかはいちおうナイショにしておきますが、要するにまだ残っているということです。

※というか、実は office さんに教えてもらったところだったり……。

これの良いところ (!?) は、他の脆弱なフォームにも応用が利いてしまうという点です。ターゲットの form の場所に応じて [1] を [0] にしたりするだけで、ほとんどのフォームに応用できます。普通のフォーム捏造だと本物を隠したりするのが面倒だったりするのですが、これならその心配全くなし。文字列の中に空白が含まれていないのもポイント高いです。ただし DOM に対応していないブラウザだとか、スクリプト無効環境では効果がないのが難点ではあります。

……まあ、ちょっと悪ふざけが過ぎる感じもしますが、「こんなこともできてしまうので警戒しましょうね」ということでひとつ。

• 「DOM万歳(XSS大王つづき)」へのコメント (29件)

関連する話題: Web / セキュリティ / ニフティ / XSS大王 / DOM

とりまとめてください

更新: 2009年5月15日19時0分頃

こんなログが。

取りに来るのは良いのですが、同じリソースを何度もゼロ間隔でというのはちょっと。たぶんアンテナに登録しているユーザの数だけリクエストしているのだろうと思いますが、一回にまとまらないのかしら。

応答のステータスが全部 416 になっていますが、これはサイズ 0 のリソースに Range つきリクエストをしているためです。サイズ 0 でも 0バイト目から取得すれば 200 なり 204 なり 206 なりになるのでは、などと思うかもしれませんが、実は Range の範囲は 1バイト目からのオフセットなのです。たとえば、次のようなフィールドを含む GET リクエストを送ったとします。

範囲が 0～0 なので空文字列が得られる……なんてことにはならなくて、これは最初の一文字を得る結果になります。

※206 応答ができるサーバならば、ですが。Range 指定があっても 200 で応答して内容全部を送ってくるサーバもあり得ます。

そんなわけで、もともとのサイズが 0 であれば Range つきリクエストは必ず 416 になってしまいます。これは IIS だけでなく、Apache でもやはりそうなります。仕様的にも正しいのですが、サイズ 0 だったら 204 で応答してくれたほうが嬉しいような気もしますね……。

※2009-05-15追記: 現在ではrobots.txtへのリクエストには204(No Content)で応答するようにしています。

• 「とりまとめてください」へのコメント (3件)

関連する話題: サーバ / UA / HTTP

s/出来ます/できます/g

時期を外したコメントですが、わたやんさんの不定期戯言 (homepage2.nifty.com)を読んでいて。

ありますね。というか、変換後のデフォルトで漢字になったりしませんか。

私なども「出来ます」ではなく「できます」を、「無い」ではなく「ない」という表記を使うように心がけているつもりなのですが、いつの間にか漢字になっていることがあるのですよね。

あと IT Pro の記事読んで思ったのですが、「脆弱性」なんてのは「脆弱性(ぜいじゃくせい)」という具合に読み仮名をつけた方が良かったりするのでしょうね。アクセシビリティとかいろいろ生意気なことを言っている割に、自分がちゃんとできていないという……。

• 「s/出来ます/できます/g」にコメントを書く

関連する話題: 思ったこと / 言葉

XSS大王さらにその後

「ITPro ニュース:@niftyの電子掲示板に「クロスサイト・スクリプティングぜい弱性」，緊急メンテナンスを実施 (itpro.nikkeibp.co.jp)」という記事が出ていますね。

気になった点をいくつか。

うーん、微妙に混同しているような……。べつに「掲示板にスクリプトを書いて捏造フォームに誘導する」必要はなく、「掲示板にスクリプトを書いてセッション Cookie を盗む」こともできましたし、「掲示板に(スクリプトを含まない)リンクを書き込んで捏造フォームに誘導する」こともできました。

• 掲示板に任意のスクリプトが書き込める
• フォームが捏造できる

という二つの別々の問題があって、これはそれぞれ単独でセキュリティホールとして成立します。それを合わせ技のように解説しているのがちょっと変な感じですね。しかも後者は Webフォーラムの書き込みとは何ら関係ありません。ログインフォーム自体が持っていた脆弱性です。

※細かいですけど、ログインパスワードを求められる画面はダイアログじゃないです……。

「問題の存在に気づかなかった」のではなく、「問題の重大性を理解していなかった」というのが正確なところではないかと思量します。根拠など詳しいことはちょっと書けないのですが、オープン直後にこの問題を認識していた人がいるのは確かで、おそらくニフティは報告を受けていたでしょう。ただ、理解はしていなかったのだと思います。

余談ですが、この問題が存在することは、昨年の 10月時点で既に公になっていました。りゅうさんの偽偽夜食日記 (rryu.sakura.ne.jp)に、以下のように書かれています。

では何故今になって「迅速な対応」をしたのかというと、その理由の一つには、「具体的な exploit コードが既に公開されていた」という点があるのでしょう。

※って、他人事のように言っていますが公開したのは他ならぬ私です、はい。ニフティのフォーラム部と関わるのが嫌だったというのが理由ですが、動きの鈍いニフティのお尻を叩く効果もあったようで、最終的には良い結果を招いたと思います。

それから引用が前後しますが、一番気になったのがこの見出し。

「現在までに実害はなし」と、どうして断言できるのかが本当に謎です。私は、とあるメールでこういうことを書きました。

そういうことで、簡単に「被害がない」と断言することはできないはずなのです。

今までの全ログを綿密に調査すればクロスサイトスクリプティング脆弱性を利用したリクエストがあったかなかったかは調査できるかもしれません。しかし、本当にそれを行ったのなら、「被害がない」という結論は出ないはずなのです。なぜなら、私は脆弱性を利用したリクエストを実際に行って exploit コードが動作することを確認しているわけで、過去に「捏造フォーム」が作られた事実は確実に存在しています。それがテストのためのものなのか、実際に ID とパスワードが盗まれたのかは、その送信先のサーバのログを見ない限り分からないはずです。

ちなみに、私が公開していた exploit は http://altba.com に GET メソッドでデータを送信するものでした。altba.com には、その捏造フォームからデータが送られてきたログが 4件残っています。そのうち 2件は私のテストなので問題ありませんが、あとの 2件は私のテストではないので、複数のサーバから複数回の捏造フォーム作成が行われていたことは間違いありません。

ニフティ側のログには、「http://altba.com に GET でデータを送る偽フォームが作られた」痕跡が少なくとも 4回以上はあるはずです。そしてニフティは、altba.com にユーザ ID やパスワードが漏れたかどうかについて問い合わせてきていません (私の知る限りでは)。記事が「実害なし」と言っているのは、単にニフティが「実害なし」と主張しているからに過ぎず、その主張にも裏付けはないと考えた方が良いでしょう。

それで、この記事の最大の問題点なのですが……それは、「メンテナンスを実施」してとりあえず危機は回避されたかのように読めてしまうこと。実は、このセキュリティ問題はまだ解決していないのですよね。まあ、それを悟れというのも無理な話なので、ある意味しようがないのですが。

• 「XSS大王さらにその後」へのコメント (2件)

関連する話題: Web / セキュリティ / ニフティ / XSS大王