[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[port139:00751] Re: URLScan の [DenyUrlSequences]
- To: port139@xxxxxxxxxxxxx
- Subject: [port139:00751] Re: URLScan の [DenyUrlSequences]
- From: Hideaki Ihara <hideaki@xxxxxxxxxxxxx>
- Date: Mon, 22 Oct 2001 16:01:46 +0900
Port139 伊原です。
Hideaki Ihara さんは書きました:
>としても URLscan が拒否しないので、? 以降の文字列をチェック対象にして
>いないと思われます。
ということで、この件について secure@xxxxxxxxxxxxx から返答が
ありました。
結論からいくと、URLscan ではクエリ文字列については検査対象に
ならないってことみたいですね。
#KB に詳しく書いておいて欲しいぞ
-----Original Message-----
From: Microsoft Security Response Center
Sent: Thursday, October 18, 2001 6:29 PM
To: 'Hideaki Ihara'
Cc: Microsoft Security Response Center
Subject: RE: URLscan [DenyUrlSequences] [msrc lt]
Hi,
Thank you very much for your note. We really appreciate the feedback.
UrlScan does care about the whole URL. However, it *does not* care
about the query string.
Each of the examples below demonstrates something in the query string
that the customer is expecting to be rejected. Specifically, it looks
like the customer is trying to use UrlScan to deal with IE's cross site
scripting problems. This is a problem that cannot be reasonably fixed
in any kind of filter running on the server (this is a scenario that IE
has enabled, and they are the only ones that can truly fix it).
Specifically, UrlScan (and even IIS itself) does not canonicalize or
process the query string because the data contained there is private to
the target of the URL. If we were to modify it in any way, it could
result in unpredicatable behavior by whatever component is processing
it. There is no specification or set of rules to which it must conform
(except that it cannot contain a space or NULL). Finally, if an
attacker really wanted to exploit IE's cross site scripting
vulnerability, they could simply change their request from a GET to a
POST and include the problem string in the entity body, where it would
be safely out of reach of UrlScan or any other filter. Any suggestion
that *anything* in IIS can fix this client problem will result in a
false sense of security.
If you have additional feedback or feel that we have missed something,
please let us know. Your feedback is important.
Again, thank you very much for your email and I hope that this helps to
answer your question.
Regards,
Secure@xxxxxxxxxxxxx
---
Hideaki Ihara <hideaki@xxxxxxxxxxxxx>
Port139 URL: http://www.port139.co.jp/
PGP PUBLIC KEY: http://www.port139.co.jp/pgp/