See now this is something I can get behind, as that's a scenario where this attack can achieve something that arbitary js normally could not do, or at least I'm more uncertain if other methods would work in that situation, and its a situation that is going to be reasonably common and not some super niche scenario. So thanks.
As for OP, its sad if you don't care about the context of a vulnerability at all, but if that's your choice then fine but its gunna be your loss in the long run. On Jul 13, 2012 9:07 AM, "Tim" <[email protected]> wrote: > > I have not read the PoC. Nor do I care to. However, I do want to > point out one aspect of session fixation that I think many people > overlook, as I think has been indicated by some responses on this > thread. If this is not news to many of you, I appologize. Just > trying to raise awareness. > > Suppose an application runs solely over HTTPS and assigns cookies > with the secure flag. However, user sessions are assigned before > login and they don't refresh their session cookies upon user login. > In this case, users are still vulnerable to MitM: > > 1. An attacker gains access to view and modify unencrypted traffic > between a user and the application. > > 2. The attacker accesses the site (in this case: https://example.com/) > as an unauthenticated user and obtains a session cookie. > > 3. A victim's browser, at some point before the victim logs in to the > application, makes a request to any non-HTTPS web page. (This could > include web mail sites, search engines, etc) Let's call this site > third-party.example.org for the sake of argument. > > 4. Attacker injects into a HTTP response (coming from > third-party.example.org) which causes the victim's browser to > request some page under the non-SSL version of example.com. This > could happen through a redirect, injection of an image tag, or any > number of other things. Anything to force the victim's browser to > send one request to the HTTP version of example.com is sufficient. > > 5. Upon attempting to access the HTTP version of the vulnerable > application (which of course doesn't exist), the attacker again > intercepts this and replaces the HTTP response. In this response, a > Set-Cookie header is included which provides the victim's browser with > the application session that the attacker retrieved in step 2. > > 6. Later, the victim logs into the application normally. Even though > the session cookie was assigned over a faux HTTP version of the site > without the secure flag set, the victim's browser sends it along to > the HTTPS site without knowing the difference. The site can't tell > the cookie was set insecurely. > > 7. Since the attacker knows the session cookie, the account can be > easily hijacked once the victim establishes an authenticated session > with it. > > > This is complicated, but it's not that much more complicated than what > existing MitM tools, such as sslstrip, already do. > > Note that another variant of this attack is possible if the victim's > browser silently accepts third-party cookies (which most do by > default) and is able to convince a user to visit any malicious site. > In this case, no MitM is necessary. > > > Using HTTP cookies for session authentication is, and always has been, > a bad idea. They are simply not designed for this application. We > need something better. > > tim >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
