COMMAND

	IE  HttpOnly  circumvention  via  http  TRACE  (that  requires   already
	elaborate access)

SYSTEMS AFFECTED

	IE 6 sp1

PROBLEM

	Jeremiah Grossman says : WhiteHat Security  has  released  a  new  white
	paper  discussing  a  new  class  of  web-app-sec  attack  (XST)   which
	potentially affects all web servers supporting TRACE.
	
	 White Paper Mirrors:
	  http://www.betanews.com/whitehat/WH-WhitePaper_XST_ebook.pdf
	  http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf
	  http://www.boarder.org/WH-WhitePaper_XST_ebook.pdf
	  http://www.forumgalaxy.com/whmirror/WhitePaper_screen.pdf
	
	 Press Release
	  http://www.whitehatsec.com/press_releases/WH-PR-20030120.txt
	
	
	Marc Slemko [marcs@znep.com] comments :
	
	--snip--
	
	Essentially what it boils down to is that Microsoft's "httponly"  cookie
	hack is half-assed, and doesn't really work very well  in  reality,  and
	that because MS has a horribly record of  cross  domain  security  holes
	that they refuse to patch in a timely manner then somehow this  hole  is
	a new all pervasive attack.
	
	Trying to pass all this  off  as  some  flaw  in  TRACE  is...  obscene.
	Combining existing holes that already have a huge exposure, then  adding
	in a few little new pieces appears to be a  strategy  designed  to  hype
	the importance of the issue.
	
	The only new thing here is that this provides a way to  get  HTTP  basic
	authentication  credentials  and,  while  this  is  indeed   a   notable
	discovery, it is unfortuante that is presented in the overhyped  way  it
	is. It has been possible to obtain basic auth credentials  in  the  past
	both from browsers that improperly  allowed  newline  characters  to  be
	embedded in fields in the request (allowing the authorization to end  up
	in the request body) and browsers that could be  tricked  into  thinking
	they are sending a request to site x while really  sending  to  site  y,
	but AFAIK those holes are all fixed in any  recent  versions  of  common
	browsers.
	
	The reality is that there  are  many  cases  where  the  server  returns
	information to the user that is confidential. TRACE is one of those.  Embedding
	session IDs in returned links is one (very commonly done on app  servers
	that support cookie based  session  tracking  with  a  fallback  to  url
	based). Returning a user's bank account number when they  their  account
	is another. I don't see trying to disable every way that the server  can
	send sensitive data to the browser as being a  very  effective  path  to
	try to take to solve such issues.
	
	The  bottom  line:  Why  do  you  even  need   to   steal   the   user's
	authentication token if you have full access to  get  their  browser  to
	submit requests and the ability to grab the  contents  of  the  results?
	And having access to those two things is exactly  what  this  whitepaper
	is assuming. Yes, there is a small incremental exposure  to  being  able
	to take the authentication token away with you and use it  yourself  but
	that is marginal compared to the exposure from the holes  being  assumed
	to be there before the new TRACE issue can be exploited.

SOLUTION

	n/a