A Study of HTTPOnly and Secure Cookie Flags for the Top 1000 Websites

A study of HTTPOnly and SECURE cookie flag settings for the top 1000 websites serving HTTPS content

A basic HTTPS request was sent to to the top 1000 websites. The HTTP responses were investigated to observe the usage of HTTPOnly and SECURE cookie flags. Here is what was found:

Unique Domains Responding: 162
    Domains responding to https://www.<site>: 141
    Domains responding to https://<site>: 88

Total Cookies Gathered: 559
    Cookies from https://www.<site>: 373
    Cookies from https://<site>: 186

HTTPOnly Flag
Total unique count of cookies using secure flag: 26
    Cookies from https://www.<site>: 25
    Cookies from https://<site>:11
    Note: 10 of the 11 sites from https://<site> were duplicated within the https://www.<site> results

SECURE Flag
Total unique count of cookies using secure flag: 15
    Cookies from https://www.<site>: 15
    Cookies from https://<site>: 0

Session Cookies
Cookies containing the word "session": 91
    Total unique count of these cookies marked HTTPOnly: 12
    Total unique count of these cookies marked SECURE: 8
    Total unique count of these cookies marked SECURE & HTTPOnly: 1 (https://www.clickbank.com)

HTTPOnly & SECURE
Total number of cookies marked HTTPOnly & SECURE : 7
    6 from https://www.paypal.com
    1 from https://www.clickbank.com

Raw data can be found at the following link.

Conclusion:

I was surprised to see such low numbers. The top 1000 sites includes the most frequented sites on the web. Since the sites responded to HTTPS requests, I would have hoped that these sites would also be leveraging the additional security benefits of the HTTPOnly and SECURE flags.  It was also interesting to see that of the 91 cookies that could easily be identified as session related cookies, only 1 cookie was marked as both SECURE and HTTPOnly. Clearly these cookies should be rotated after an actual login, but why establish a session at all if you aren't going to protect it with these basic cookie flags?


Notes on this test:

HTTPOnly and SECURE flags are used as an extra layer of security and are most often used with sites that support logins. It is unclear what number of the sampled sites support logins and thus would be good candidates to implement these additional controls.  Therefore the results should not be construed as a sampling of sites that should be using the HTTPOnly and SECURE flags.

When the HTTPOnly and SECURE flags are used on a website it is likely that they would be used throughout the site. Therefore if any of the sites were to use these flags I would expect them to be used on the page requested for the test. Therefore I believe the presence, or lack thereof, of the HTTPOnly and SECURE flags accurately represents the use of these flags at the tested sites.


-Michael Coates - @_mwc

Django's Built In CSRF Defense for AJAX

How django safely bypasses a random CSRF token for AJAX requests.

Django will allow AJAX requests that contain the following header without the need for any CSRF token: X-Requested-With: XMLHttpRequest

See: http://docs.djangoproject.com/en/dev/ref/contrib/csrf/

While its true that an individual user could tamper with their own headers, it is not possible to modify another user's headers in a cross domain attack such as CSRF. See discussion here

Testing?

Intercept a request and remove the X-Requested-With header.
You should get a 403 FORBIDDEN response if the CSRF defense is working correctly.


-Michael Coates - @_mwc

Securely Storing Opt-Out Email Addresses

Walgreens was just compromised and an attacker got the master list of email addresses that also included email addresses of people who had opted-out of receiving Walgreens emails. The attacker promptly sent phishing attacks to all of the email addresses in an attempt to elicit private user data.

This brings up an interesting design issue.  On one hand you need to store the email addresses of people that have opted out of email, otherwise you may inadvertently re-add them in the future from other sources or users actions, but on the other hand, storing all of these email address is increasing the damage if the list is compromised.

Solution?  Hashing.  For every email address that is in your "opt-out" list, simply store the hash of the email address instead of the actual email address.  When you get a new email address compare the hash against your list of the "opt-out" email addresses. If you have a match, then its an opt-out. Throw away that email address.  For new opt-outs, simply add the hash of their email address to the "opt-out" hash store and discard the plain text email address.

This way you get the benefits of not inadvertently re-adding users that have previously opted-out while also ensuring that a compromise won't disclose the huge number of people who really don't want any of your emails anyway.

Note: Don't hash your "opt-in" email addresses or your normal mail functionality won't work at all.

-Michael Coates - @_mwc

One Click Application Security - How did we get here?

As you are looking towards next year and are reviewing your application security plan please remember that there is no single magic tool to solve all of your application security issues.  Any product that is touted to "automate" your security review process  or "find all security problems in your application" is just fluff.  The sales person will tell you that their product is the latest and greatest, that it can perform "deep packet inspection" or "successfully detects all X top attack techniques". But remember, this is all just talk.

The reality is this. Your application is a custom piece of software that supports unique functionality and is designed in a unique way.  However, the security product is a single piece of software and is claiming to be able to detect flaws in any custom web application. Here lies the problem. A generic piece of security software cannot reliably detect security issues in custom designed software.  A generic scanner does not understand your application's workflow or access control - two areas where critical vulnerabilities are often located.

Why do we even think that one-click security is possible to begin with? Let's step back about 10 years. At this point web applications were static and boring. You were lucky (or unlucky) to find a page that even had scrolling marquee text going across the screen. At this time, attackers focused on network and operating system attacks because this is where the sensitive data was at.  Most often attackers exploited poorly configured or outdated networking devices and Windows based servers/desktops.  This created a great market for security vendors and tools. Vendors created tools that would scan for known vulnerabilities in the most commonly deployed products (Cisco routers, Windows servers/desktops, firewalls, etc) and then issue a vulnerability report to the user. The security team then took this report and patched or reconfigured the vulnerable devices. Presto! The security product has solved the company's security concerns.

Fast forward to the present. Now attackers have shifted to web applications. Why the shift? For one, network security got a heck of a lot better. Its not as easy for the attacker to get in through this attack vector. Second, and more importantly, why bother trying to get in to the network when the data you want is accessible through the vulnerable web application that is sitting right on the Internet?

Security vendors realize that application security is the next great security frontier and have begun creating new products with their old scan and report approach. Unfortunately we've conditioned ourselves to accept that this antiquated approach works for all security issues. It worked for networks right?  But the reality is that this approach can only catch the most common issues in web applications.  (Read: Most Web Application Scanners Missed Nearly Half Of Vulnerabilities) All of the deeper (and more critical issues) are going to require custom testing to detect.  This is the problem. People buy web scanning tools believing the tools is easy to use and that it will result in secure web applications.  The reality is that the tool is easy to start up, difficult and time consuming to interpret the results, and will likely only find some common security issues in the application.

A scanning tool does have its place in a robust application security program, but it is only to double check that the most basic security issues have been addressed.  Any reliance on a generic scanning tool as your primary security control is nothing more than a false sense of security and a disaster waiting to happen.

-Michael Coates - @_mwc

Advertisers vs Privacy - How You Are Tracked And Tools To Protect

It's no secret that many websites leverage an advertising based funding model to derive revenue from viewers. But the game is getting much bigger than just showing advertisements. Now its all about customizing ads to the particular user viewing the site.  The company that can best profile a user can offer the most targeted ad and demand the highest payment for this service.

Unfortunately it is becoming increasingly difficult for a user to control what pieces of information are stored by sites they visit.   The dominant methods of profiling users in the past were tracking beacons and cookies that could be used to centrally record a user's activity across various websites. These could be used to build a pretty powerful picture of a user's habits and interests.

But advertisers ran into a problem. Sometimes people would clear their cookies - either for security reasons or to specifically stop this type of tracking.  No worries. The tracking companies are upping their game and are using flash cookies, local storage and any other storage tactic they can figure out.  These new techniques are mostly unknown to the average web users and survive through most normal cookie clearing efforts. (Read more about the evercookie research to get an idea of all the possible storage methods.)

Now, we have another company that is jumping in with an even better approach (better for ad companies that is). They wish to profile your device. From the WSJ.com article:

 Mr. Norris is building a "credit bureau for devices" in which every computer or cellphone will have a "reputation" based on its user's online behavior, shopping habits and demographics. He plans to sell this information to advertisers willing to pay top dollar for granular data about people's interests and activities.

I haven't seen the details, but I'm guessing this approach leverages the different pieces of information a browser sends when visiting a site - headers, screen resolution, language support, etc. In the end this can be quite a bit of different data.  A research project was released by the EFF to highlight this issue and it shows just how easy a site could uniquely identify a user based on his or her browser profile.  This profiling technique, combined with a beacon on multiple websites, creates an effective tracking method that is tricky for the average user to overcome.  Now the user has to figure out how to make his or her browser signature less unique to avoid being individually tracked by this new technique.

It's your choice what information you wish to share. Want to keep a tighter lock on your data when browsing? Here are some helpful tools:

Recommended For All:

• Ghostery Plugin - Like Ad Blocker but for common tracker cookies and beacons
• Ad Blocker - Ads can be dangerous, this blocks them all
• Better Privacy Addon  - Allows you to delete those pesky flash cookies
• Browser - Clear Private Data: Clear out most data that has been stored from websites
• Clear Flash Cookies - You have to do this from a widget on Adobe's website
• Private Browsing Mode - Note: This is not "anonymous" browsing. I only mention it because it separates out your cookies and makes sure they are cleared after each session. You could also just configure your browser to clear all cookies when closed.

Recommended For Those Willing To Work A Bit

• Tor + TorButton - Does tons, you should read about the gains and limitations of this.
• Request Policy Plugin - Granular control of all cross domain requests per page. Awesome plugin.

What's missing? What do you use?


-Michael Coates - @_mwc