Comments on: Security Headers on the Top 1,000,000 Websites

By: Jaap

Jaap — Wed, 21 Nov 2012 05:16:02 +0000

Great work, Isaac!

It would be awesome if you open source the code you used to do this research. This research got me thinking about building a Burp plugin which automatically scans for incorrect Security header declarations. It would be great to be able to re-use your code if you are at all interested.

Cheers.

By: Krupa

Krupa — Tue, 20 Nov 2012 12:45:27 +0000

The data gathered here must be pretty large. Were you gathering headers only, or was the body of the website(home page only) also saved along with it? Also, to complete the full download in 3-4 hours, u require very fast internet service, even when you are gathering headers by sending concurrent requests. What was the speed of your data connection & average download speed?

By: Stefan Arentz

Stefan Arentz — Sat, 10 Nov 2012 18:01:52 +0000

This is great research. To see the HSTS results in better context, do you have numbers on how many of the sites you tested actually support https and how many redirect from http to https?

By: Sid

Sid — Thu, 08 Nov 2012 16:13:59 +0000

Possibly where the X-Frame-Options “GOFORIT” probably orignated:
http://stackoverflow.com/a/6767901

Briefly: when your web host is adding x-frame-options to the pages you’re creating, you can invalidate it by adding another, invalid token like “GOFORIT”.

By: Isaac Dawson

Isaac Dawson — Wed, 07 Nov 2012 15:53:15 +0000

Hello Pete,
Recently, I’ve changed my position to be not convinced one way or the other yet on if these new HTML specifications are more or less risky for the web. While any new addition in functionality can increase attack surface, some of these new security mechanisms clearly help and have little to no negative impact. (X-Frame-Options is a great example). For me — and as I think my results show — the biggest risk is people implementing things incorrectly and being falsely led to believe they are more safe. The amount of typos was quite astounding.

For CORS, I can’t say “increasing risk” because it totally depends on the nature of the resource being requested. Keep in mind you can’t send credentials to a resource that is set to a wildcard origin and read the response. So that really limits what an attacker can do in terms of stealing sensitive or protected information. The problem all boils down to how it gets implemented. If the remote server is sending session identifiers in the URI then yes that site will most certainly have problems when combined with the power of CORS. In my opinion, the biggest “issue” with CORS is how easily it becomes to ex-filtrate data once you’ve found an XSS issue, or for how you can take advantage of sites which don’t properly sanitize user input for the url part of a call to the XMLHttpRequest object.

Other ways of “message passing” (which I think is what you mean?) would be the Web Messaging APIs take a look at the specification from w3: http://www.w3.org/TR/webmessaging/.

I think CSP is still going through its infant stages, I think it’s best to watch the specification and how the browser vendors develop it further. I really love the idea of Report Only mode so you can try it out and see what shakes loose.

By: Isaac Dawson

Isaac Dawson — Wed, 07 Nov 2012 15:40:59 +0000

Hey Odin,
Awesome stuff, I threw together my tests to confirm my suspicions of how CORS worked in the various browsers, good to see there are more formal ones in w3c :). As for CSP it seems like people are still waiting to see how the browsers end up implementing some of the directives.

By: Pete

Pete — Wed, 07 Nov 2012 14:30:32 +0000

Nice work. One of the things I believe will help in the debate btwn whether HTML5 increases or decreases risk is to get an understanding of how much of this stuff replaces workarounds.

For CORS, it looks like 80% of sites are increasing their risk by explicitly allowing anyone to access it. And 20% are defining a same-origin policy so the effect must be compared to their previous susceptibility to same-domain bypass (xss).

Do you know of any alternatives to CORS that could do this? Maybe some sort of server-side API?

WRT CSP, do you intend to f/u with deeper analysis of the 69 sites that use it? Since this is an existence test, I can’t assess how the defined policy might compare with existing environment.

Thanks,

Pete Lindstrom

By: Odin Hørthe Omdal (odinho)

Odin Hørthe Omdal (odinho) — Wed, 07 Nov 2012 10:13:47 +0000

Nice work :-)

If you have any more conformance tests for CORS, where the current ones reside is http://w3c-test.org/webappsec/tests/cors/submitted/ — opera/staging/ has some nice ones that I’ll ask for approving for shortly.

CSP needs much more W3C conformance tests (they’re rather easy to write!), so that the faults that Joe talked about doesn’t happen. BTW, repository is dvcs.w3.org/hg/ — although we’re moving some test repositories to github as well: http://github.com/w3c/

Another problem for CSP-reach is the reporting being flooded with useless reports, often because of user-js or extensions etc.

By: Stomme poes

Stomme poes — Wed, 07 Nov 2012 09:03:00 +0000

Honestly, a Headers-Lint program (maybe one exists) to check things like value typos and name-value mismatches would be awesome. Not only for those who know nothing (yes, I know, sec people hate that, but it is reality) but also for those who do know better but are human.

By: Andy Steingruebl

Andy Steingruebl — Wed, 07 Nov 2012 01:34:32 +0000

Can you explain your concerns about HSTS and subdomains overriding the parent setting? Do you think this opens a security hole? It would be nice if you have comments that you’d post them to the IETF websec mailing list which is the best place for discussions of it.