Security

How Common Are HTTP Security Headers Really?

A recent issue of the German iX magazin featured an article on improving end user security by enabling HTTP security headers

  • X-XSS-Protection,
  • X-Content-Type-Options MIME type sniffing,
  • Content-Security-Policy,
  • X-Frame-Options,
  • and HSTS Strict-Transport-Security.

The article gave the impression of all of them quite common and a good DevOps being unreasonable not implementing them immediately if the application supports them without problems.

This lead me to check my monthly domain scan results of April 2014 on who is actually using which header on their main pages. Results as always limited to top 200 Alexa sites and all larger German websites.

Usage of X-XSS-Protection

Header visible for only 14 of 245 (5%) of the scanned websites. As 2 are just disabling the setting it is only 4% of the websites enabling it.

Website Header
www.adcash.com X-XSS-Protection: 1; mode=block
www.badoo.com X-XSS-Protection: 1; mode=block
www.blogger.com X-XSS-Protection: 1; mode=block
www.blogspot.com X-XSS-Protection: 1; mode=block
www.facebook.com X-XSS-Protection: 0
www.feedburner.com X-XSS-Protection: 1; mode=block
www.github.com X-XSS-Protection: 1; mode=block
www.google.de X-XSS-Protection: 1; mode=block
www.live.com X-XSS-Protection: 0
www.meinestadt.de X-XSS-Protection: 1; mode=block
www.openstreetmap.org X-XSS-Protection: 1; mode=block
www.tape.tv X-XSS-Protection: 1; mode=block
www.xing.de X-XSS-Protection: 1; mode=block; report=https://www.xing.com/tools/xss_reporter
www.youtube.de X-XSS-Protection: 1; mode=block; report=https://www.google.com/appserve/security-bugs/log/youtube

Usage of X-Content-Type-Options

Here 15 of 245 websites (6%) enable the option.

Website Header
www.blogger.com X-Content-Type-Options: nosniff
www.blogspot.com X-Content-Type-Options: nosniff
www.deutschepost.de X-Content-Type-Options: NOSNIFF
www.facebook.com X-Content-Type-Options: nosniff
www.feedburner.com X-Content-Type-Options: nosniff
www.github.com X-Content-Type-Options: nosniff
www.linkedin.com X-Content-Type-Options: nosniff
www.live.com X-Content-Type-Options: nosniff
www.meinestadt.de X-Content-Type-Options: nosniff
www.openstreetmap.org X-Content-Type-Options: nosniff
www.spotify.com X-Content-Type-Options: nosniff
www.tape.tv X-Content-Type-Options: nosniff
www.wikihow.com X-Content-Type-Options: nosniff
www.wikipedia.org X-Content-Type-Options: nosniff
www.youtube.de X-Content-Type-Options: nosniff

Usage of Content-Security-Policy

Actually only 1 website in the top 200 Alexa ranked websites uses CSP and this lonely site is github. The problem with CSP obviously being the necessity to have a clear structure for the origin domains of the site elements. And the less advertisments and tracking pixels you have the easier it becomes...

Website Header
www.github.com Content-Security-Policy: default-src *; script-src https://github.global.ssl.fastly.net https://ssl.google-analytics.com https://collector-cdn.github.com; style-src 'self' 'unsafe-inline' 'unsafe-eval' https://github.global.ssl.fastly.net; object-src https://github.global.ssl.fastly.net

Usage of X-Frame-Options

The X-Frame-Options header is currently delivered by 43 of 245 websites (17%).

Website Header
www.adcash.com X-Frame-Options: SAMEORIGIN
www.adf.ly X-Frame-Options: SAMEORIGIN
www.avg.com X-Frame-Options: SAMEORIGIN
www.badoo.com X-Frame-Options: DENY
www.battle.net X-Frame-Options: SAMEORIGIN
www.blogger.com X-Frame-Options: SAMEORIGIN
www.blogspot.com X-Frame-Options: SAMEORIGIN
www.dailymotion.com X-Frame-Options: deny
www.deutschepost.de X-Frame-Options: SAMEORIGIN
www.ebay.de X-Frame-Options: SAMEORIGIN
www.facebook.com X-Frame-Options: DENY
www.feedburner.com X-Frame-Options: SAMEORIGIN
www.github.com X-Frame-Options: deny
www.gmx.de X-Frame-Options: deny
www.gmx.net X-Frame-Options: deny
www.google.de X-Frame-Options: SAMEORIGIN
www.groupon.de X-Frame-Options: SAMEORIGIN
www.imdb.com X-Frame-Options: SAMEORIGIN
www.indeed.com X-Frame-Options: SAMEORIGIN
www.instagram.com X-Frame-Options: SAMEORIGIN
www.java.com X-Frame-Options: SAMEORIGIN
www.linkedin.com X-Frame-Options: SAMEORIGIN
www.live.com X-Frame-Options: deny
www.mail.ru X-Frame-Options: SAMEORIGIN
www.mozilla.org X-Frame-Options: DENY
www.netflix.com X-Frame-Options: SAMEORIGIN
www.openstreetmap.org X-Frame-Options: SAMEORIGIN
www.oracle.com X-Frame-Options: SAMEORIGIN
www.paypal.com X-Frame-Options: SAMEORIGIN
www.pingdom.com X-Frame-Options: SAMEORIGIN
www.skype.com X-Frame-Options: SAMEORIGIN
www.skype.de X-Frame-Options: SAMEORIGIN
www.softpedia.com X-Frame-Options: SAMEORIGIN
www.soundcloud.com X-Frame-Options: SAMEORIGIN
www.sourceforge.net X-Frame-Options: SAMEORIGIN
www.spotify.com X-Frame-Options: SAMEORIGIN
www.stackoverflow.com X-Frame-Options: SAMEORIGIN
www.tape.tv X-Frame-Options: SAMEORIGIN
www.web.de X-Frame-Options: deny
www.wikihow.com X-Frame-Options: SAMEORIGIN
www.wordpress.com X-Frame-Options: SAMEORIGIN
www.yandex.ru X-Frame-Options: DENY
www.youtube.de X-Frame-Options: SAMEORIGIN

Usage of HSTS Strict-Transport-Security

HSTS headers can only be found on a few front pages (8 of 245). Maybe it is visible more on the login pages and is avoided on front pages for performance reasons, maybe not. That would require further analysis. What can be said is only some larger technology leaders are brave enough to use it on the front page:

Website Header
www.blogger.com Strict-Transport-Security: max-age=10893354; includeSubDomains
www.blogspot.com Strict-Transport-Security: max-age=10893354; includeSubDomains
www.facebook.com Strict-Transport-Security: max-age=2592000
www.feedburner.com Strict-Transport-Security: max-age=10893354; includeSubDomains
www.github.com Strict-Transport-Security: max-age=31536000
www.paypal.com Strict-Transport-Security: max-age=14400
www.spotify.com Strict-Transport-Security: max-age=31536000
www.upjers.com Strict-Transport-Security: max-age=47336400

Conclusion

Security headers are not wide-spread on website front pages at least. Most used is the X-Frame-Option header to prevent clickjacking. Next following is X-Content-Type-Options to prevent MIME sniffing. Both of course are easy to implement as they most probably do not change your websites behaviour. I'd expect to see more HSTS on bank and other online payment service websites, but it might well be that the headers appear only on subsequent redirects when logging in, which this scan doesn't do. With CSP being the hardest to implement, as you need to have complete control over all domain usage by application content and partner content you embed, it is no wonder that only Github.com has implemented it. For me it is an indication how clean their web application actually is.

Overview on Automated Linux Package Vulnerability Scanning

I got some really helpful comments on my recent post Scan Linux for Vulnerable Packages. The suggestions on how to do it on Debian and Redhat made me wonder: which distributions provide tools and what are they capable of? So the goal is to check wether each distribution has a way to automatically check for vulnerable packages that need upgrades.

Below you find an overview of the tools I've found and the distributions that might not have a good solution yet.

Distribution Scanner Rating Description
Debian debsecan superb Easy to use. Maintained by the Debian testing team. Lists packages, CVE numbers and details.
Ubuntu debsecan useless They just packaged the Debian scanner without providing a database for it!
And since 2008 there is a bug about it being 100% useless.
CentOS
Fedora
Redhat
"yum list-security" good Provides package name and CVE number. Note: On older systems there is only "yum list updates".
OpenSuSE "zypper list-patches" ok Provides packages names with security relevant updates. You need to filter the list yourself or use the "--cve" switch to limit to CVEs only.
SLES "rug lu" ok Provides packages names with security relevant updates. Similar to zypper you need to do the filtering yourself.
Gentoo glsa-check bad There is a dedicated scanner, but no documentation.
FreeBSD Portaudit superb No Linux? Still a nice solution... Lists vulnerable ports and vulnerability details.

I know I didn't cover all Linux distributions and I rely on your comments for details I've missed.

Ubuntu doesn't look good here, but maybe there will be some solution one day :-)

Scan Linux for Vulnerable Packages

How do you know wether your Linux server (which has no desktop update notifier or unattended security updates running) does need to be updated? Of course an

apt-get update && apt-get --dry-run upgrade

might give an indication. But what of the package upgrades do stand for security risks and whose are only simple bugfixes you do not care about?

Check using APT

One useful possibility is apticron which will tell you which packages should be upgraded and why. It presents you the package ChangeLog to decided wether you want to upgrade a package or not. Similar but less details is cron-apt which also informs you of new package updates.

Analyze Security Advisories

Now with all those CERT newsletters, security mailing lists and even security news feeds out there: why can't we check the other way around? Why not find out:

  1. Which security advisories do affect my system?
  2. Which ones I have already complied with?
  3. And which vulnerabilities are still there?

My mad idea was to take those security news feeds (as a start I tried with the ones from Ubuntu and CentOS) and parse out the package versions and compare them to the installed packages. The result was a script producing the following output:

screenshot of lpvs-scan.pl

In the output you see lines starting with "CEBA-2012-xxxx" which is CentOS security advisory naming schema (while Ubuntu has USN-xxxx-x). Yellow color means the security advisory doesn't apply because the relevant packages are not installed. Green means the most recent package version is installed and the advisory shouldn't affect the system anymore. Finally red, of course meaning that the machine is vulnerable.

Does it Work Reliably?

The script producing this output can be found here. I'm not yet satisfied with how it works and I'm not sure if it can be maintained at all given the brittle nature of the arbitrarily formatted/rich news feeds provided by the distros. But I like how it gives a clear indication of current advisories and their effect on the system.

Maybe persuading the Linux distributions into using a common feed format with easy to parse metadata might be a good idea...

How do you check your systems? What do you think of a package scanner using XML security advisory feeds?

Syndicate content