Re: TRACE used to increase the dangerous of XSS.

On Thu, 2003-01-23 at 04:14, Sverre H. Huseby wrote:
> Jeremiah,

Happens I guess.

> Personally, I read two important points in it: One down-to-Earth

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

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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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

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

amen brother. Received on Thu Jan 23 19:33:15 2003