Most of you probably manage various web applications that use cookies and possibly SSL to provide security for connectivity. If so, you need to know how your applications handle any cookies that are set during an SSL connection. If you haven't secured the cookies, your entire application could be vulnerable to session hijacking attacks.

When a web application sets a cookie, at least a few parameters are required, including a path relative to the website, the site domain name, and an expiration date. Other parameters can be provided, including a 'secure' flag that defines whether the cookie should be sent only over SSL connections. If that flag isn't set, then a browser could be tricked into sending the cookie over a regular clear-text HTTP connection, at which point anyone sniffing network traffic might be able to harvest the cookie and use it however they see fit. That's exactly the type of attack outlined by Sandro Gauci of EnableSecurity in his Surf Jacking paper, available at the URL below.
http://resources.enablesecurity.com/resources/Surf%20Jacking.pdf

In a nutshell, an attacker scenario works like this: A user opens website "ABC" in a browser window and logs in over an SSL session. Website ABC sets a session cookie without the secure flag set. The user then opens a new browser window and goes to website "XYZ." Website XYZ sends a redirect message telling the browser to go back to Website ABC, but instead of instructing the browser to connect using HTTPS the redirect instructs the browser to use regular HTTP. When the browser connects to site ABC using HTTP, it sends its session cookie. An attacker sniffing traffic grabs the cookie, adds it to his or her owner browser, and is then able to connect to site ABC posing as the legitimate user. That's obviously not good.

One might think that surely major web service providers have taken steps to prevent such an attack, but as it turns out that's not the case across the board. According to Gauci, several sites were vulnerable to the attack at the time he published his paper. Those sites included Google Gmail, Salesforce.com, Skype, GoDaddy, a couple of unnamed banks, and one online bookstore. Wow.

Gauci developed some example code, written in the Python scripting language, that you can download and try out for yourself. The script works over wired and wireless networks. You can get a copy of the script at the URL below.
http://code.google.com/p/surfjack

So how do you determine whether the code in your web applications sets the secure flag for cookies? One way is to somehow examine the source code, depending on what tools you have available. What you need to look for depends on the programming language. If your code is written in PHP, look for instances of the session_set_cookie_params() function, which might look something like the following example:

session_set_cookie_params(0, $cookie_path, $cookie_domain, 'secure');

You can find more info about that particular PHP function at the URL below.
http://us2.php.net/session_set_cookie_params

For JavaScript, look for instances of the cookie object, which might appear in relation to the document object, similar to this:

document.cookie = "name=value; expires=date; path=path; domain=domain; secure";

Mozilla's developer website, at the URL below, has useful documentation regarding the cookie object.
http://developer.mozilla.org/en/docs/DOM:document.cookie

And, if your applications are written in Visual Basic (VB), C#, C++, J#, or JScript, head over to Microsoft's website at the URL below, where you'll find cookie-related examples for all of those languages.
http://msdn.microsoft.com/en-us/library/system.web.httpcookie.secure.aspx