I support a web based application which uses dots in the
filenames of very long filenames. These filenames are
randomly generated by users so its not predetermined when
they will occur. If the name defined by the user is over
20 characters long, then our software will truncate the
filename and insert dots in the path. This causes
urlscan to block the url when it is later requested by
the app. I find some customers are hesitant to configure
teh urlscan.ini file to accept these dits in the
filename. Has urlscan functionality been rolled into a
Microsoft SP? How large is the risk to the customers
server running this application i fthey do allow dots in
the filename?

Thanks,

Why on earth would you truncate a file name and create ambiguity by
performing an uncontrolled character replacement? That seems to me to be a
terrible idea, from an application security and generally sound coding
perspective. Which leads me to my next point...

Of course your customers are hesitant to allow dot sequences in the path!
There's a very good reason that URLScan, server proxies, firewalls, etc. are
set up to block these types of sequences. They're nothing but an invitation
for trouble. And, aside from your application, there's no legitimate for
them in any practical environment.

And to answer your questions:

Yes, IIS 6.0 incorporates a lot of the base functionality of URLScan into
the IIS core.

And the risk to them is substantial. This is not to say that they'll be
actively exploited the minute they turn it off. However, if they turn it
off and another exploit for the platform goes wild, they'll likely be sorry.

Bottom line: Your application needs to be fixed.

[quoted text, click to view]

On Wed, 14 Apr 2004 07:06:41 -0700, "Jay"
[quoted text, click to view]

Well, when your app depends on dots in the path, they have to allow it
or not run your app, so the security issues are moot. For many, dots
in the path are acceptable, and the biggest issue is probably a
malfromed URL that causes a type of DOS attack on the web server, but
even that is a minor issue for most systems.

Let me rephrase your question:
"I have an application which introduces possible canonicalization-based
attacks to my customers. URLScan is blocking these attacks, and my
customers are hesitant to reconfigure URLScan to allow my application to
operate".

Rolling URLScan functionality into an SP doesn't solve your problem; it is
only changing the delivery vehicle of the security functionality. This
application intrinsically introduces a canonicalization-based threat, which
the customer must handle in one of these ways:
1. Mitigate the threat by moving away from your application
2. Mitigate the threat by making you fix your application
3. Acknowledge the threat but lower security

Hmm... looks like the responsibility is all on your shoulders...

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
[quoted text, click to view]
I support a web based application which uses dots in the
filenames of very long filenames. These filenames are
randomly generated by users so its not predetermined when
they will occur. If the name defined by the user is over
20 characters long, then our software will truncate the
filename and insert dots in the path. This causes
urlscan to block the url when it is later requested by
the app. I find some customers are hesitant to configure
teh urlscan.ini file to accept these dits in the
filename. Has urlscan functionality been rolled into a
Microsoft SP? How large is the risk to the customers
server running this application i fthey do allow dots in
the filename?

Thanks,
Jay