Insecure Cookies and You: Perfect Together

Who uses the secure cookie flag? Web developers who don't want their user's cookies being leaked out over non-SSL protected sockets. These developers realize that protecting user credentials on the wire is only half the battle. If an attacker can sniff a user's cookie off the wire when it's sent in plain text, who cares if the credentials are protected? The attacker still gets access to the application.

Who doesn't use the secure flag? Yahoo! Mail. Microsoft Live Mail. GMail and Google apps. All of these sites, and many others, protect the transmission of credentials using HTTPS. Unfortunately, immediately after you authenticate to one of these sites and get a valid session cookie, the browser is redirected to a plain text HTTP interface of the site. Google at least gives users the option of protecting their entire session with SSL. Others do not. If these companies start setting the secure flag on their cookies, their sites will break.

The "Secure" cookie flag is just a patch for a poorly implemented browser Same Origin Policy. Essentially, it allows a web application to opt-in to a strict interpretation of SOP on the client side that will prevent cookies from being leaked over insecure protocols. Why do we have to do extra work to be secure?

I propose a new cookie flag, called the "insecure" flag. Use of the insecure flag would allow web sites that don't care about protecting session cookies to opt-out of a strict interpretation of SOP, thus exposing their session cookies to the world and allowing their applications to work. If you want to protect your users' credentials over HTTPS, but then expose their sessions over HTTP, this will be the flag for you!

Imagine that. Secure by default. No extra work to do things right. What a concept!

Ah, wishful thinking :-)

NYS CSCIC Conference

Last week I presented at the NYS cyber security conference in Albany. My talk was about attacks that leverage publicly available information, such as data indexed in search engines and/or stored in social networks. I also showed how this data can be used in highly targeted spear phishing attacks. My spear phishing demo used my netextender ssl vpn exploit, since it is usually trivial to find a companies SSL VPN gateway. Once you find the ssl vpn gateway, some passive recon of the system can reveal a tremendous attack surface on the victim (client) machine.

At the end, I touched on some problems with commercial PKI, but I didn't really get into it. I'm saving that for some up coming blog posts. I got some great feedback at the end, and also met a bunch of cool folks. Thanks for listening. Slides are available here.

I couldn't stick around for both days of talks, but I managed to see the two key notes on day one. The second one was by Phil Reitinger, Deputy Under Secretary, National Protection and Programs Directorate (NPPD) U.S. Department of Homeland Security.

/me lets his fingers recover from typing that title

During his talk, Mr. Reitinger offered up five priorities for the US as we move forward with our new cyber security initiatives. I'm paraphrasing here, and I didn't take great notes. That's because I'm just some dude with a blog, and not a journalist.

1. We need to build our capacity. DHS needs people. We also need to work with academia to build programs that churn out people with the right skills and knowledge.

2. Establish relationships between public and private sector. Mr. Reitinger joked about the infinite loop of meetings where public & private sector folks agree that they are both willing to share data - starting at the next meeting.

3. Develop (and follow) a standard incident response & recovery plan.

4. Streamline Identity Management. In addition to managing user identities, he also mentioned something to the effect of "being able to better identify who we're connecting to." Maybe this means we'll eventually get something better than SSL site validation.

5. Metrics. Specifically, he mentioned software quality metrics. One thing that keeps popping into my head is the fact that the airforce got a locked-down version of XP. How did the air force quantify the improved security? And when will everyone else benefit?