Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

IIS 5.0 Does Not Correctly Process Escape Characters in a URI (Q311470)

0 views
Skip to first unread message

DMorris

unread,
Jul 5, 2002, 7:21:44 AM7/5/02
to
We are having the problem this Q article refers to on our WIN2K ADV
production servers.
However on one of our standard WIN2K development servers there is no
problem.

We are running exactly the same web application - both machines are running
with SP2

We have a test link
http://www.tri-portal.com/test/subfolder1/test%20%26%20%23%20%25%20test.htm
which returns a 404

This link works on our development server.

The Q article says there is a problem but any ideas why we have it working
on one and not the other?

Thanks

David


David Wang [MS]

unread,
Jul 5, 2002, 11:33:06 PM7/5/02
to
URLScan is installed on any of those machines?

--
//David

"DMorris" <mor...@comsiant.com> wrote in message
news:O31y#WBJCHA.1168@tkmsftngp13...

DMorris

unread,
Jul 6, 2002, 10:09:08 AM7/6/02
to
David

It was on the WIN 2K ADV server but we were aware of the problems with
URLScan and escape characters so removed it, (we used it as part of
IISLockdown tool) but to no effect.

David

"David Wang [MS]" <som...@online.microsoft.com> wrote in message
news:#CMN72JJCHA.1596@tkmsftngp13...

David Wang [MS]

unread,
Jul 7, 2002, 4:50:00 PM7/7/02
to
URLScan does not have problems with escape characters. If anything, URLScan is
trying to protect your server by rejecting requests with certain restricted
characters/sequences which have few uses next to being part of an attack. You
can configure URLScan to not reject them, but then you are knowingly increasing
the attack surface of your server.

There are several things about that URL which URLScan would object to:
1. %26 decodes to '&' , which is a restricted character
2. %25 decodes to '%' , which does not preceed any other numbers (not
normalized) and also a restricted character

You really should keep URLScan installed. Your URL is really contrived and
contain candidates for attack.

When you say "Removed URLScan" did you uninstall it and restart IIS or did you
just remove the URLScan filter? Since it is an ISAPI Filter, you must restart
IIS after removing/uninstalling/configuring it. Running the URLScan uninstall
should have prompted you to restart IIS.

--
//David

"DMorris" <mor...@comsiant.com> wrote in message

news:uH5XKZPJCHA.2372@tkmsftngp12...

DMorris

unread,
Jul 10, 2002, 5:22:50 AM7/10/02
to
David

Thanks for this - we found that although we had un-installed IISLockdown we
found that the URLScan ISAPI filter was still listed on IIS. We
un-installed this and the problem was solved. Could this be because we had
installed previous version of URLScan prior to applying IISLockdown ?

Also thanks for your comments about the URL(s). Our application is purely
intranet based
and allows staff to publish documents from their desktop the Intranet.

David


"David Wang [MS]" <som...@online.microsoft.com> wrote in message

news:ueRpBffJCHA.2604@tkmsftngp11...

David Wang [MS]

unread,
Jul 10, 2002, 3:59:39 PM7/10/02
to
Odd. I'm almost certain that scenario should have been tested - IIS Lockdown
and URLScan installing/uninstalling as a unit.

However, keep in mind that they are separate tools. Also, URLScan is an ISAPI
Filter, meaning that if you declined to restart IIS during uninstall for some
reason, it would not be able to uninstall (it's similar to declining to reboot
Windows after removing some system component that was in current use).

In any case, I would still install URLScan but instead put it into "monitoring"
mode where it does nothing except logs what it would have rejected given its
current configuration. Do this over a trial period to see how a particular
URLScan configuration works out.

--
//David
This posting is provided "AS IS" with no warranties, and confers no rights.
//


"DMorris" <mor...@comsiant.com> wrote in message

news:u2jyxL$JCHA.2580@tkmsftngp11...

0 new messages