2003年5月8日(木曜日)

IIS のログ改竄(その2)

以前、IIS のログが改竄されている話をしましたが、もっと酷い例を発見しました。

たとえば /foo/ に default.aspx というファイルを置いてあったとすると、/foo/ に対するアクセスで /foo/default.aspx の内容が返ります。このとき、クライアントは /foo/ をリクエストしているのに、サーバ内部のログには GET /foo/Default.aspx というログが残るという……。しかも何故か先頭大文字。

確かに内部的にはその内容を返しているのでしょうが、ログとしてはクライアントが送ってきたデータを生のまま保存しておかないとあまり意味がありません。たとえば不正アクセスの追求をしようと思ったとき、ログに残っている文字列が IIS によって加工されている可能性を考慮しなくてはいけませんし、証拠としても弱くなるでしょう。

このへん、IIS6 だと良くなっているのかしら……。

「IIS のログ改竄(その2)」にコメントを書く

関連する話題: Web / httpd / Microsoft / IIS / サーバ

2003-05-08 00:00:53 219.96.196.58 - 211.16.234.154 80 GET /bakera/hatomaru.aspx - 500 Mozilla/5.0+(Windows;+U;+Win98;+en-US;+rv:1.2b)+Gecko/20021016+Sylera/1.1.10 Field+blocked+by+Outpost+(http://www.agnitum.com)

500 Internal Server Error が発生しています。何で？と思ってよく見ると、"Referer: Field blocked by Outpost (http://www.agnitum.com)" というフィールドが送出されています。Referer に URI じゃないものを入れているなんて聞いたことがありません。RFC2616 を見て確認してみると、Referer の書式はこうなっています。

Referer = "Referer" ":" ( absoluteURI | relativeURI )

以上、RFC2616 14.36 Referer より

Referer の値として指定できるのは絶対 URI あるいは相対 URI のみです。URI の後ろにコメントを書くことも出来ません。……というか、"(" と ")" は URI に使える文字なので、単純に URI の一部とみなされるでしょう。

※ちなみに "absoluteURI" の書式は RFC2616 では定義されておらず、RFC2396 を参照しています。つまり、ここでの "absoluteURI" "relativeURI" は RFC2396 の "absoluteURI" "relativeURI" であり、それらは絶対 URI および相対 URI の書式そのものです。

"Field blocked by Outpost (http://www.agnitum.com)" という文字列には URI に使用できない ASCII SPACE が思いっきり含まれていますから、URI として不正です。

このことから得られた教訓 : Agnitum: Taking care of your security (www.agnitum.com) で紹介されている Outpost とかいうソフトウェアは RFC2616 の仕様を満たしていません。イントラネットなどの閉じられたネットワークで使うならともかく、これでインターネットにアクセスすることはちょっとオススメできません。

※まあ rfc-ignorant.org (www.rfc-ignorant.org) ではないので、RFC に反していると言うだけでアクセス拒否したりはしませんが。

しかし、RFC 違反の Referer を送出されたというだけで 500 になってしまうというのもそれはそれでショボイと思うので、何とかしたいですね……。

「Refererの書式」にコメントを書く

関連する話題: Web / http / サーバ / altba.com / hatomaru.dll

不正な Referer 対策

というわけで不正な Referer 対策。

ASP.NET では、Referer の値は System.Web.HttpRequest 型の Request というオブジェクトの UrlReferer プロパティにアクセスすることで得られます。プロパティの値は System.Uri 型です。つまり、Referer の値は ASP.NET の内部処理によっていったん System.Uri 型の値に変換されているわけです。

この変換は結構良くできていて、頭にスキームがなければ相対 URI とみなされるし、Referer に空白が含まれているような場合でも、勝手に %20 に変換してくれます。たいていの場合は何とかなるのですが、問題のケースでは括弧書きの中に URL が入っているのがまずいのか、Request.UrlReferrer の値を参照しようとした瞬間に System.UriFormatException が発生します。ToString() メソッドを呼ぼうとしても駄目ですし、null と比較しようとしただけでも駄目です。

しようがないので UrlReferer プロパティは封印して、代わりに Request.Headers["Referer"] で取得することに。これで何とかなる……といいなぁ。

「不正な Referer 対策」にコメントを書く

関連する話題: プログラミング / C# / ASP.NET / hatomaru.dll

404応答

hatomaru.dll が生成する 404 や 500 のページのステータスコードが 200 になっていたので修正。前回ちょっと修正したときにバグを埋め込んだ模様。

他人のこと言えないし。

「404応答」にコメントを書く

レインボーグッキー

アンリミテッド:サガ (www.amazon.co.jp)。ジュディ編、「ナクルの地上絵」にてランダム宝箱をあさっていたら、レインボーグッキー発見！

移動時の表示は黄色になっていなかったのに「獣」がいて、しかも全然襲ってくる気配がありません。「？」と思ってこちらから戦いを挑んでみると、それがレインボーグッキーでした。※初見のはずですが、名前判明していました。

姿形は、ジュディに「うわぁ、可愛い」と言われてしまうグッキーやモルケクスと同じなのですが、これが激強。なんか 7回くらい行動している上に、ステータス異常攻撃がきついこときついこと。しかも 3連携を当てても全然 LP が削れなかったりしたため、勝利を断念。

……3連携と言っても、それが「炎の払いくらべ」では論外な感じですね。でもそのくらいが限界で、しかも相手はこれだけ強いのに、こちらは技を全然ひらめかない！この強さだと騎士団廟の巨人もまだ辛そうですし、サーベルタイガーあたりで修行して出直しますか……。

「レインボーグッキー」にコメントを書く

関連する話題: 出来事 / ゲーム / スクウェア / Sa・Ga / アンリミテッド:サガ

前(古い): 2003年5月7日(Wednesday)のえび日記
次(新しい): 2003年5月9日(Friday)のえび日記

水無月ばけらのえび日記