|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: New Web Vulnerability - Cross-Site Tracing (fwd)
Date: Thu Jan 23 2003 - 14:49:50 EST
On Wed, 22 Jan 2003, Jeremiah Grossman wrote:
> > And having access to those two things is exactly what
If you already have a cross domain restriction bypass bug in the browser (which is a major bug and any vendor who doesn't immediately fix such bugs when they are discovered should be ashamed of themself... just like any vendor that has their corporate email system bouncing back posts to bugtraq saying the list doesn't exist on their system) you can perform whatever actions you want on behalf of the user using their browser, and can grab the results. The holy grail is not the credentials, it is the application itself and whatever operations it allows and data it contains.
You don't need the credentials if you can control the application through the user's b rowser. Sure, grabbing the credentials makes things a little easier. But not all that much, since they are often only good for the session anyway.
If you do not have a cross domain restriction bypass , then this "flaw" doesn't add anything. Nonsense about having some other way to create content on the server is irrelelvant; if you can do that, then see the previous paragraph.
To summarize what is new and either notable or laughable in this paper:
- a more widespread way than previously known to grab HTTP basic auth credentials. This is new and quite interesting, yes. There were some ways a few years back to do this with certain browsers, but it was not widespread and has long been fixed. You will find, however, that few sensitive apps use HTTP basic auth for a multitude of reasons. Being able to steal this information can be very valuable for an attack against sites that do use it though, since HTTP basic auth credentials normally are not session based and remain valid for long periods of time... which is one of the multitude of reasons it isn't normally used for sensitive apps. Even worse, some systems use a system login and password in this which can be exploited to gain further access to a system, even if the access to the web application is inconsequential.
Many people, including myself, have always suggested that HTTP basic authentication is not a very secure mechanism even when used over SSL. It is often the easiest one though.
2. the ability to bypass the non-standard "httponly" cookie hack that exists in a few versions of one particular web browser. This is somewhat interesting, but has few practical implications since this hack is not in widespread use and even with this hack in place, it does nothing to prevent an attacker from simply controlling the user's browser to do what they want or get the information they want even without getting the credentials.
The whole problem with the httponly hack in IE is that it doesn't really change anything in the bigger picture. It prevents cookies only from being read directly by javascript in particular browsers if the flag is explicitly set. I am as guilty as the next person in using demonstration exploits that show stealing the cookie using javascript as "what cross site scripting does", but realize that is just a convenient easy to understand example of one type of web application security. You don't need the credentials, protecting them is a handy thing but nothing more than that.
3. a bunch of hype that comes from claiming that this, combined with previously known cross domain restriction bugs, results in a very serious flaw. It is actually true that it does result in a very serious flaw, but the flaw was already there without any of this new information by the very nature of the cross domain restriction hole.
4. The most amusing press release I have read in a while. It is a "pandemic" and a "SERIOUS SECURITY FLAW AFFECTING ALL WEB SERVERS WORLDWIDE" that is present in "a vast majority of commercial web sites". And this is something that White Hat Security has to accept full responsibility for, it is their press release.
As for what "the fix" is...
Note that I do think that the XMLHTTP control should probably know about the httponly hack if the httponly hack is something Micorosft wants to support. The httponly hack is documented as marking cookies as "scriptless". The HTTP spec defines the TRACE method as returning a message body of a content type message/http that contains the headers from the original request.
The httponly hack says the cookie shouldn't be accessible from script. Therefore, IE better ensure it isn't accessible using the TRACE method. I'm not sure that I would call this a bug in the XMLHTTP control, but more a missing feature (ie. lack of explicit TRACE support) and a bug in how the httponly hack was thought through since it requires the cooperation of every component that can plug into the browser that provides access to data.
Contrast this with being able to exploit something similar using a printenv CGI script. In that case, it isn't reasonable for the browser to prevent access to the returned cookie from scripts because there is nothing in the HTTP spec telling it that the response contains the cookie. It isn't a bug in the printenv script that it returns the cookie (although certainly you may well wish to choose not to have such scripts available on your production servers for a variety of reasons), it isn't reasonable for the browser to filter it out (although it could; it could filter out anything matching the cookie value that is present in the response... lets hope you never make a httponly cookie with a value of "http" or any such)... it is just a limitation in the basic concept of the httponly hack and an example of why I think it is half-assed. Received on Thu Jan 23 16:16:33 2003
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:47 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |