comments (not for humans)

There are a lot of security headers out there, and due to a recent scanby @einaros we can now build some statistics on the use of these headers in Norway. The result is disappointing.

Data

In the the list at http://dotno.indev.no/ there seems to be about 83,000 Norwegian domains. The website provides a search interface giving the number of hits for the queried headers. The UI allows search for header names and substring matches for values. To search for apache servers you could use the query "server:apache".

Clickjacking

Clickjacking is (partially) mitigated by using the X-Frame-Options header. This header was introduced in IE8, but is now supported across the most popular modern browsers.

X-Frame-Options0.69%569

Clearly a very disappoitning number.

X-XSS-Protection

Modern browser (at least IE and Chrome) have built-in filter intended to stop XSS-attacks. These filters can be controlled by using the X-XSS-Protection header. A value of 0 means disable. A value of 1 means enable. Additional a mode can be set instructing the browser how to handle a detected attack.

Sites setting X-XSS-Protection0.78%643
Sites setting X-XSS-Protection:10.66%544
Sites setting X-XSS-Protection:00.12%99

A very low percentage of sites are actually setting the header, and 15.4% of those setting it, actually disable the filters. Out of the sites setting the header to 1, all set mode to "block".

Content-Security-Policy

This is a modern header allowing the server to set a policy for the browser. It instructs the browser whether it's allowed to run inline JavaScript, which domains it can download images, script, css etc. from and more. Finding a proper policy for a site, can be challenging.

Sites setting Content-Security-Policy0%0

None. Zero. Null.

Cross Origin Resource Sharing (CORS)

The Access-Control-* headers allow JavaScript in browser to load data across origins. This is normally regulated by the Same Origin Policy, but these headers provide a way to relax this policy. If a server sends "Access-Control-Allow-Origin: example.com" in a response, tells the browser that if the current URI has a domain name of "example.com", it is allowed to access data from that domain. Specifying "Access-Control-Allow-Origin: *" allows any domain to use the data. "Access-Control-Allow-Credentials: true" tells the browser it's allowed to include cookies in the request.

Sites setting Access-Control-Allow-Origin0.62%511
Sites setting Access-Control-Allow-Origin:*0.56%462
Sites setting Access-Control-Allow-Credentials:true0.06% 49
Sites setting Access-Control-Allow-Origin:* and Access-Control-Allow-Credentials:true0.05%41

The last combination is insecure and disallowed by the spec. It means any site can access data on the given domain using the currently logged in user's cookies.

Cookie flags

There are two cookie flags that are interesting from a security perspective. If the Secure flag is included in a response over HTTPS, the browser is instructed to only send the cookie over HTTPS connections. The HttpOnly flag instructs the browser to hide the cookie from JavaScript. This is intended to stop XSS attacks from stealing the cookie.

Sites setting cookies44.46%36652
Sites with cookie name containg session 17.58%14493
Sites using the HttpOnly flag11.99%9884
Sites setting cookies over SSL1.01%833
Sites setting the secure flag0.3%247

68% of sites setting a session (based on query for cookies with a name containing session) are using the HttpOnly flag. Out of the sites setting cookies over SSL, only 30% use the Secure flag.

Conslusions

All in all these are disappointing results. Especially the use of the cookie flags and the clickjacking header is much lower than expected.

comments powered by Disqus