Comments on: Surf Jacking Secure Cookies

By: Matt

Matt — Mon, 09 Nov 2009 16:48:12 +0000

A cookie with both the secure flag and the httponly option will resist this attack. Browser won’t send cookie in header and won’t allow JS to access it.

By: L’uomo nel mezzo tutto vede e tutto può - Appunti Digitali

L’uomo nel mezzo tutto vede e tutto può - Appunti Digitali — Thu, 12 Mar 2009 17:08:40 +0000

[...] in attesa che un utente sprovveduto si colleghi ad un sito non protetto da SSL (benché esistano attacchi ben noti anche per siti protetti con SSL!) e fornisca le sue credenziali in chiaro come token [...]

By: xssniper

xssniper — Tue, 24 Feb 2009 18:17:31 +0000

True… there is a warning in Internet Explorer, however every other browser I tested did NOT have a mixed content or the warning was given AFTER the mixed content was loaded.

But you are right… even with a warning its difficult for a regular user to make an informed decision.

By: jasper

jasper — Tue, 24 Feb 2009 17:16:57 +0000

My concern is the “warning” that the page is loading secure and insecure items. Most people would click “yes” to this prompt – boom! Pwned!

By: wheelq

wheelq — Sat, 18 Oct 2008 19:58:49 +0000

Hi,

can u contact me at my mail please? I’ve made a post on our website but didn’t get an answer, and it’s quite important for me.

thanks

By: xssniper

xssniper — Wed, 24 Sep 2008 18:45:49 +0000

@barbsie and @x-tense: I completely agree… this is basically a way to “inject” XSS into an SSL site without presenting the user a SSL cert/mixed content warning (on most browsers). Starbux wi-fi just got a little more dangerous (not that it isn’t dangerous enough)

@Andre and @Sandro: I agree with you both. I think SECURE cookies are a solid mitigation… but the current state of implementation weakens the protections significantly

By: x-tense

x-tense — Wed, 24 Sep 2008 14:46:52 +0000

The attack presented is more XSS than surf jacking doesn’t it ?

By: Sandro Gauci

Sandro Gauci — Wed, 24 Sep 2008 14:36:59 +0000

Yes this sort of thing makes the secure flag useless. An attacker can do virtually anything, from stealing the secure cookie (as you described), to controlling the victim’s browser remotely, to stealing page contents, install a js keystroke logger.

Referencing js scripts on HTTP from an HTTPS site is such a bad idea. Yet I’m sure that there are a lot of sites that do it.

And I think there’s other issues to consider apart from cookie stealing. For example, most HTTPS connections are actually started from a link on an HTTP site. Are you thinking what I’m thinking?

Dan went through this in his BH talk.. and probably others did as well. At this point I think that the way that we do “secure HTTP” is so broken..

By: barbsie

barbsie — Wed, 24 Sep 2008 14:31:10 +0000

Nice. There’s tons of stuff you can do with MitM attacks. It’s IMHO way more efficient to target the client instead of the server with MitM.
What about injecting CSRF and XSS with beef ( http://video.google.com/videoplay?docid=-7578708518522997029&hl=en). Collecting hits, clickfraud etc…

By: Hugo

Hugo — Wed, 24 Sep 2008 12:19:17 +0000

Your SIDENOTE confuses me. If you say, that document.cookie is not accessable for SECURE cookies, how can you steal it?

Perhaps you could rephrase that SIDENOTE to not confuse