[VulnDiscuss] Re: TRACE used to increase the dangerous of XSS.

On Thu, 2003-01-23 at 04:14, Sverre H. Huseby wrote:
> Jeremiah,
> 
> I'm sorry for all the heat you have taken for your white paper.

Happens I guess.

> Personally, I read two important points in it: One down-to-Earth
> advice for the web site administrator, and one rather abstract
> observation for the web programmer.
> 
> 
> For the admin
> -------------
> Disable TRACE requests either in the firewall or in the web server,

I am not familiar with any HTTP aware network based firewalls which have
the ability to see inside of an HTTP request looking for TRACE and then
deny. Likely because its too much overhead per request. But hey, I could
be wrong, maybe there is one.


>  as
> the users' credentials _may_ be stolen.  Some people may probably have
> fun logging such requests as well.
> 
> If I understand the article correctly, credentials between a user and
> a web site may be stolen if at least _one_ of the following is true,
> as long as TRACE requests are honored:
> 
>   * The site is open to Cross-site Scripting
>   * The user has a buggy browser
> 

close...I'll give some examples.

A user visits Site A. Site A has XST code and uses a functional browser
domain-by-pass bug.  Site A owner may use TRACE to get access to Site
B's cookies and htauth creds without the need for Site B to have
vulnerable web app present anywhere. 


Now, lets back up a moment and say there is no domain-bypass issue and
the cookies are protected using httpOnly within Domain A. Also, a user
is able post HTML pages on anywhere domain A as many portal sites allow.
Corporations allow similar activities as well for their employees.


If someone visits a page hosted anywhere on Domain A, using XST, the
page owner may now access cookies and basic auth credentials from
*.domainA.tld. But, restricted to that domain without further help. The
argument may be made on why you would need to go beyond that domain
anyway for access.



> For the programmer
> ------------------
> The article shows quite clearly that one should not try to solve a
> class of security problems by _adding_ artificial "solutions" rather
> than _removing_ the real problem.  The problem we are talking about is
> Cross-site Scripting (XSS).  The artificial solution added on top of
> it is httpOnly cookies.  Lazy (and ignorant) programmers may think
> that if they use httpOnly, they need not pay attention to XSS.  Your
> article shows that the lazy ones are wrong.  Creative people tend to
> find ways around the add-ons.


Many of us have spent countless hours dealing with and mitigating XSS,
generally through input/output filtering. In the meantime, hoping
someone would find some way to easily deal with the problem generically.
For the programmer, XSS is just too easy to forget about or not know
about. The best hope we had at the time was httpOnly or some variant.


Personally, I really liked the httpOnly add-on. I found it amazingly
difficult to circumvent while testing. Thor mentioned something in his
post that that could do that same (bypass httpOnly) requiring 3
technologies. Man if that method works, I'll be highly impressed. Going
to try it out when I get some time.


> Don't get me wrong: The add-ons give us defense in depth, but only if
> we try to solve the real problem as well.


amen brother.