TheReg effect…
When I checked "hide results", I didn't expect it to hide the results from _me_ and giving me a blank page instead.
Now you can easily see if a site's HTTP headers are insecure, beams dev
A new coding tool aims to do the same for HTTP response headers as Qualys SSL Labs has done for secure server configurations. The securityheaders.io site allows users to scan to get a grade between A+ to F for response headers. The free service is primarily designed to allow sysadmins to test their own sites, much like the …
-
-
Tuesday 26th January 2016 12:15 GMT JetSetJim
Re: Hall of Shame
Not there now for me (12:14 GMT), but still scoring an F (removed link as it doesn't seem to work inside html tag, but works fine in copying/pasting from a browser address bar)
Interesting that lots of banks don't score very well on this metric. Can we have more detail to the uninitiated as to the risk exposed by these?
-
-
Tuesday 26th January 2016 12:41 GMT Anonymous Coward
Very arbitrary definition of "secure" headers
Ok so I looked at a site that got an "F" - www.haaretz.com
They list this as the reasons:
Strict-Transport-Security - This is one of the only ones I agree with, but people forget, not all browsers respect it... IE up until 10 didn't even acknowledge this, neither does maxthon, so for sites that have many users and don't want to kill of a huge proportion of their users, it shouldn't be obligatory. Considering it's a news site, I don't see why they would...
Content-Security-Policy - A good anti-XSS measure if you configure it correctly - there are many bypasses available if you allow inline javascript - but again, this doesn't ensure security.
Public-Key-Pins - This is so rare to see, but good luck getting your site to run on mobile apps... and updating them when you change your certificate!
X-Frame-Options - whoopy - no one can frame your site and use it as phish-bait... there are more efficient ways to get around this.
X-XSS-Protection - means absolutely nothing. XSS protection filters can be bypassed so easily. I've seen <img/src=x onerror=alert(1)> bypass a filter because the inline javascript was reflecting all the parameters in the URL... if it's a stored XSS, the filter won't even clean it, just like chrome and IE anti-xss filters... they mostly focus on javascript tags in the URL.
X-Content-Type-Options - This is only marginally helpful for preventing XSS, but then again, if you declare content types correctly and have an update to date browser - why not.
What's interesting is that it doesn't even mention caching header safety measures like:
Pragma: no-cache
Cache-Control: no-cache
This would prevent caching of HTTPS content, which can store all sorts of juicy stuff.
An interesting site, but in no measure a gauge of security...
-
Tuesday 26th January 2016 13:41 GMT Rob Moss
Re: Very arbitrary definition of "secure" headers
Not really, AC. Strict-Transport-Security doesn't rely on browser support to be useful. Every website should be served up over HTTPS, and every website should also implement the HSTS header, because for those browsers that support it - and bear in mind MS are working very hard to kill off IE <11 - it means there's never an HTTP request that needs redirecting after the first ever request to the site. There are also preload lists implemented by browsers.
Content-Security-Policy has one very simple setting - upgrade-insecure-requests - which you can set to ensure that none of the resources linked from within your page are ever served over HTTP. I don't understand how anyone could argue against that being a good idea. You can also set all sorts of other restrictions, which are great if implemented properly. At least having the header served up shows that a non-zero amount of thought has gone into external resources.
Public-Key-Pins is something everyone should just do. Serve up two pins - one relates to your private key, and the other relates to a backup private key. If you change your certificate, so what? It's the same private key, and hence the same public key. You serve up the backup pin in case your private key is compromised. It's a commonly held myth that the pin is for the certificate. It isn't. It's a hash on the public key. Not the same thing as a certificate.
Why wouldn't you set X-Frame-Options? What more efficient options are there for stopping your site being framed as phish bait?
Why wouldn't you set X-XSS-Protection? Leaving it unset allows IE to bypass its own filters for backward compatibility purposes. It's madness to suggest this means nothing. For IE, it means everything, and IE remains the number one target, even if it's no longer the most popular browser.
Why wouldn't you set X-Content-Type-Options? Are you suggesting it's OK not to set it if you couldn't be bothered declaring content types correctly? Or if you have someone who might use your site with an older browser? Screw those guys using newer browsers, because there's someone using an older browser which will ignore this header, I'm going to leave an XSS hole open for them.
Your caching safety headers will leak information to disk. They don't cut it. You should have said:
For HTTP 1.1:
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0
For HTTP 1.0:
Pragma: no-cache
Expires: 0
An interesting comment, but in no measure a demonstration of understanding of web application security...
-
Tuesday 26th January 2016 14:02 GMT Anonymous Coward
Re: Very arbitrary definition of "secure" headers
X-Frame-Options is superseded by the frame-ancestors directive of CSP.
X-XSS-Protection is superseded by the reflected-xss directive of CSP.
X-Content-Type-Options isn't relevant to trusted content with valid MIME
Old browser users can pound sand.
-
-
Tuesday 26th January 2016 14:20 GMT ScottHelme
Re: Very arbitrary definition of "secure" headers
Hey, thanks for the comment, I'd thought I'd cover a few points.
HSTS may have poorer support in older browser, yes, but vendors aren't going to roll support for new security features backwards through their older versions. If you want support for the latest security features, you need to keep your browser up to date! ( http://caniuse.com/#search=hsts )
CSP has many more uses than just mitigating XSS, I've covered a few on my blog if you want to have a look at some more. CSP doesn't ensure security, I don't think anything can, but it's a step in the right direction. ( https://scotthelme.co.uk/tag/csp/ )
PKP is very rare yes and this is largely due to it being the most recently standardised of the headers and its higher complexity to implement. I'm not sure how it factors in to mobile apps, which wouldn't look at HTTP response headers, they'd key pin via other means if they did. As for native browsers on mobile platforms, they either support it or not, but in time all of them will I'm sure. Lastly, certificate renewal has no impact on PKP, you're pinning the Public Key (PK-Pin) and not the certificate. I currently issue the PKP header on my own site and automatically renew my certificate with Let's Encrypt ( https://scotthel.me/le ).
XFO is incredibly simple to deploy and widely supported, why would you not if you wanted to prevent framing? (or allow it from specific origins)
XXSSP, so if the filter is bypassed once we should abandon using it. Or perhaps the filters could be improved and continue to offer more robust protection moving forwards? The fact is that it does offer some protection which is always better than no protection, all for the sake of issuing a simple HTTP response header!
XCTO also helps to mitigate drive-by downloads if that poses a risk to your site, but even if it did only offer a marginal improvement against XSS, it's a very easy way to get it.
As for the other headers, there's a lot more coming but I couldn't get everything in to v1. Alongside Pragma and Cache-Control I'm looking at the Cookie header (httpOnly, secure) and the Access-Control-Allow-Origin header too. Any other suggestions for improvement are welcomed, you can leave a comment on my blog or find my email address and get in touch directly if you wish.
Scott.
https://scotthelme.co.uk
-
-
Tuesday 26th January 2016 14:14 GMT Anonymous Coward
A+ Grade for alphastreet.co
Didn't even have to do any additional work. Time for the pub!
Well, maybe not so quick since although it's testing for the Content-Security-Policy header it's not checking that the policy is perfect and I know it's not since it currently allows for in-line scripts (temporary situation).
I'll give securityheaders.io an A for effort but a B for results. It's no good just checking for the presence of the headers if you don't inspect their values.
-
Tuesday 26th January 2016 14:27 GMT Drefsab_UK
I got a nice a+ but Public-Key-Pins is a real sticky issue and I do use it myself I've spent time to research it test it with report only ensure that my keys are and crs's are backed up etc and then alter my ssl generation scripts to use the same private key (using letsencrypt so wasn't using the same key each time before).
So this is all well and good for me. However what about joe public trying to learn the hard way or mr / mrs "knows about computers so you can look after the company website" who is a little over depth.
If they use this tool they could read about that try to implement it do it badly and then boom website is offline and clients cant connect and there's not a lot they can do about it.
Public-Key-Pins is not something you should be messing about with unless you have taken the time to do your research properly. There should be greater warnings as to the risk of poor implementation.
-
-
Tuesday 26th January 2016 16:18 GMT Dick Emery
My bank website sucks?
I just tried it on www.santander.co.uk and it brings up a number of issues.
Missing headers for:
Strict-Transport-Security
Content-Security-Policy
Public-Key-Pins
X-Frame-Options
X-XSS-Protection
X-Content-Type-Options
I'm not sure how that effects my actual login though.
Oh and it's scoring is 'R'? WTF does that mean?
Biting the hand that feeds IT
