[WEB SECURITY] Re: OT URLScan was [WEB SECURITY] cross site trace

["Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>]

OT [URLScan] James -- I think some people are resistant
to using URLscan.

The first version (the glued-on thingy to .NET issued
in response to an encoded directory traversal attack
a number of us published about the same time in 03)
created very negative performance impact.

This made some folks gunshy and adverse to the
technology. And then some folks are naturally (and
justifiably) sensitive to anything that sits between the
end user and the business that is potentially mucking
about with transactions. For some folks in security
transaction mucking puts one's career on the line.

That said....

The first *full* version of URLscan seemed to cause
minimal performance degradation under load, and I have
not seen nor heard anything negative about later versions,
though I stopped using Windows for web servers.

MS made the HTTP request processing engine a kernel
component in W2K3, and the filters are probably wired
up very closely so it may perform just fine.

MS offers a free web DDOS script kit. Easy enough to
throw a bunch of configs into URLScan, crank up the
HTTP load in a test region, and find out if URLscan breaks
or slows things:

http://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx?mfr=true


(and let us know what you find out if you try this, please)


-- 
-- 
Arian J. Evans.
Software. Security. Stuff.




On Tue, Jul 22, 2008 at 10:13 AM, James Landis <jcl24@xxxxxxxxxxx> wrote:
> While you're at it you'll also want to measure your users for
> vulnerable versions of Flash and malicious ActiveX as well. Maybe dig
> through your logs and look for evidence of TRACE attacks (other than
> your scanner, of course). Or you can just *patch and save time
> debating the risk of the issue*.
>
> XST is not the only reason you'll want the ability to do protocol
> validation and filtering before requests reach your application code.
> Why the resistance to URLScan? It gives you verb tampering protection,
> encoding enforcement, extension filtering, URL canonicalization,
> length restrictions, etc. etc. etc. and it's free. I understand it
> takes some time to push changes through the release process, but
> you've undoubtedly got other patches to push at the same time. It
> might actually *improve* performance of the site to be able to reject
> malicious traffic before your app has to process it (if it even has
> the chance to do this at all).
>
> The statistical evaluation Arian is talking about is the exposure
> metric. If you don't trust the recommendation you got from your
> vendor/scanner, your damage metric will basically come down to this:
>
> Does TRACE expose header data (most likely cookies or Flash cookies)
> that the attacker can't already get access to in some easier way (XSS,
> browser vuln, etc.)?
>
> -j
>
> On Mon, Jul 21, 2008 at 11:18 AM, Arian J. Evans
> <arian.evans@xxxxxxxxxxxxxx> wrote:
>> In terms of business case it seems you would want
>> to evaluate this risk statistically.
>>
>> e.g.-- How many IE 6 users(?), pulse/frequency of
>> IE 6 user access, etc.
>>
>> This would give the business a better notion of
>> relative attack surface. If your user base is 100%
>> deprecated IE 6 (say in the case of an intranet
>> app and legacy internal users) this might be a
>> justifiably high risk issue. Where conversely a
>> Mac-oriented website might find the risk to be
>> much lower. (100% browser != IE)
>>
>> Qualys moved this down to a "medium" several
>> years ago after vigorous debate with them, but
>> it seems most vendors keep this as "high"
>>
>> Makes sense though. Much easier to find the
>> "TRACE" method enabled on a web server
>> to pad your reports with "High" vulns than
>> to find most of the things we actually see attackers
>> exploiting in the wild (on webapps). ;)
>>
>> Happy Monday,
>>
>> --
>> --
>> Arian J. Evans.
>> Software. Security. Stuff.
>>
>>
>>
>>
>>
>> On Fri, Jul 18, 2008 at 5:10 PM, Raymond Forbes <rforbes@xxxxxxxxxxxxxx> wrote:
>>> Scanners always rate it as a high or critical.  PCI auditors consider it a
>>> "PCI" issue because it is tied with cross-site scripting.  I am in the
>>> process of making a justification about not prioritizing these as high as
>>> other XSS vulns and was curious what is the general consensus.
>>>
>>> -Raymond
>>> ----- Original Message ----- From: "Brian Shura" <bshura@xxxxxxxxxxxxx>
>>> To: "'Raymond Forbes'" <rforbes@xxxxxxxxxxxxxx>; <websecurity@xxxxxxxxxxxxx>
>>> Sent: Friday, July 18, 2008 4:58 PM
>>> Subject: RE: [WEB SECURITY] cross site trace
>>>
>>>
>>>> Raymond,
>>>> IE 6 is the only major browser that still supports TRACE, so I would agree
>>>> that this is a low risk vulnerability.  What does your scanner rate it as?
>>>>
>>>> -Brian
>>>>
>>>> -----Original Message-----
>>>> From: Raymond Forbes [mailto:rforbes@xxxxxxxxxxxxxx]
>>>> Sent: Friday, July 18, 2008 12:44 PM
>>>> To: websecurity@xxxxxxxxxxxxx
>>>> Subject: [WEB SECURITY] cross site trace
>>>>
>>>> So, this vulnerability keeps coming up on scans and audits.  Considering
>>>> the number of clients that even support trace has dramatically shrunk
>>>> this would seem to me to not be a serious issue anymore.  Not that I am
>>>> saying it isn't worth fixing but when prioritizing with other
>>>> vulnerabilities this ends up on the low side.
>>>>
>>>> Am I off base here?
>>>>
>>>> -Raymond
>>>>
>>>>
>>>>
>>>>
>>>>
>>>

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA