5 ms·

How widely used are security-based HTTP response headers?

116 points by bikeshack 11y ago

martinrue 11y ago
For people using Node/Express, Helmet is a useful little library that lets you add these security headers and CSP pretty easily: https://github.com/helmetjs/helmet https://github.com/helmetjs/helmet
- gkop 11y ago
  This is the counterpart for Ruby: https://github.com/twitter/secureheaders https://github.com/twitter/secureheaders
- thephyber 11y ago
  Lusca[1] is the NPM module for use with Express that comes in the KrakenJS middleware (open sourced by PayPal). app.use(lusca.csrf()); app.use(lusca.csp({ /* ... */})); app.use(lusca.xframe('SAMEORIGIN')); app.use(lusca.p3p('ABCDEF')); app.use(lusca.hsts({ maxAge: 31536000 })); app.use(lusca.xssProtection(true)); [1] https://github.com/krakenjs/lusca https://github.com/krakenjs/lusca
nly 11y ago
I've found HPKP and HSTS easy to trivial, but gave up on deploying CSP. It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline.
- JoshTriplett 11y ago
  > It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline. You can still use CSP, and whitelist specific third-party domains. (There's no way to whitelist inline code, though, and if there were it'd be more work than eliminating it and moving it to files.) But the refactoring is well worth doing. By eliminating inline JavaScript and off-domain JavaScript, you eliminate the possibility of script injection. And directly including third-party JavaScript (or CSS, which can include JavaScript) opens you up to various kinds of attacks.
  - jacobparker 11y ago
    > There's no way to whitelist inline code That's not completely true - the nonce attribute (specify a nonce in the CSP header, have nonce=that on every script tag) or by sending the hashes of the inline scripts upfront in the CSP header. It doesn't give you inline code in attributes (e.g. onclick) but it's a big help for migrating.
    - JoshTriplett 11y ago
      Ah. I hadn't found that in Mozilla's CSP documentation. Thanks.
      - Scott_Helme_ 11y ago
        I'm going to be doing some blogs in the coming weeks on how to use hashes and nonces to whitelist inline script. Hopefully, this will make introducing CSP a little easier. I also have some tools in the making that will help in this regard too.
- lol768 11y ago
  You might find the Content-Security-Policy-Report-Only header useful for identifying CSP issues and deploying policies without actually blocking anything.
  - deleted 11y ago
    [deleted]
STRML 11y ago
It's unfortunate that response headers on a secure website need to be bloated so much to receive benefits that should be default on modern sites. I imagine a world where you specifically have to opt-in to unsafe behavior, not the other way around, but of course this would break many existing sites. For those of you looking at this, I've found the X-Frame-Options (to prevent clickjacking via iframe) and Content-Security-Policy (to restrict eval, inline JS, JS and embed sources and more) to be the most useful headers by far. If you can run CSP without 'unsafe-eval' or 'unsafe-inline' and restrict all sources to your local domain, your site's security will be much better for it as an entire range of attacks is eliminated on modern browsers. Of course they are all worth looking at. Scott's header test (https://securityheaders.io https://securityheaders.io) is a great check for your own sites.
- eli 11y ago
  Some day that will probably happen, but of course the issue is that it would break every site that relies on the less secure behavior.
- JoshTriplett 11y ago
  > I've found the X-Frame-Options (to prevent clickjacking via iframe) I wish some way existed to prevent clickjacking (e.g. via invisible iframe) without actually banning frames. There are useful applications for framing another site that can't be achieved by any other means, apart from writing a browser extension. And framing a site without making it invisible seems like unfortunate collateral damage.
  - hannob 11y ago
    Dan Kaminsky is working on something: http://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickjacking/ http://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickja...
- Scott_Helme_ 11y ago
  It's worth pointing out that you can replace the functionality of the X-Frame-Options header with Content-Security-Policy using the frame-ancestors directive if you want to: https://scotthelme.co.uk/csp-cheat-sheet/#frame-ancestors https://scotthelme.co.uk/csp-cheat-sheet/#frame-ancestors A world with opt-in to unsafe behaviour would be great, but a long way off I fear. Thanks for mentioning the header check service!
A010 11y ago
I gone through his previous blog post and found the changing Server: header field. Why have to waste time for rebuilding nginx from source for that? Why not just insert 'server_tokens off' in your nginx.conf?
- nly 11y ago
  Because it doesn't eliminate the Server header, "off" will return "Server: nginx". Just one of several "fuck you" features in nginx.
  - A010 11y ago
    Server: header makes people gone mad?
    - JoshTriplett 11y ago
      It wastes space, and reveals unnecessary information about your server infrastructure.
      - FooBarWidget 11y ago
        As if turning it off helps. Nginx is so popular, attackers would just try Nginx-specific exploits right after trying Apache ones even if they don't know for sure whether you are running Nginx.
  - Scott_Helme_ 11y ago
    Sadly nly is right. The only other option to change this is the ngx_headers_more module, but that still requires a rebuild. I suppose that way you at least get a little more functionality for your troubles.
    - nly 11y ago
      You also need that module to do per URI/path/regex match headers properly, because add_header + location blocks are woefully insufficient thanks to the way they are processed. This is one reason I gave up on CSP under nginx.
jacquesm 11y ago
HN uses x-frame-options:"DENY" to good effect which takes care of a fair number of click-jack tricks, it also uses strict-transport-security. But there is only so much you can do with headers, the real risks are in the documents themselves. How about a <nojs> </nojs> pair in the primary document disabling any kind of javascript execution in the space between the tags. And those tags should only work in the primary document.
- dantillberg 11y ago
  > How about a <nojs> </nojs> pair in the primary document disabling any kind of javascript execution in the space between the tags. But wouldn't folks still be able to inject scripts by just writing `</nojs><script>alert('hi')</script><nojs>`?
- JoshTriplett 11y ago
  CSP does exactly that; you can just ban inline scripts entirely.
dantillberg 11y ago
This post encouraged me to go through my own website and add a moderately strict CSP header, sans 'unsafe-inline' scripts/styles. Thanks!
- Scott_Helme_ 11y ago
  If you like, you could also add reporting to your CSP and get live feedback on it with https://report-uri.io https://report-uri.io It's free to sign up and use.
idlewords 11y ago
CSP breaks bookmarklets in Firefox, which makes it rather user-hostile. This is properly Mozilla's fault, but they've shown no interest in fixing it. https://bugzilla.mozilla.org/show_bug.cgi?id=866522 https://bugzilla.mozilla.org/show_bug.cgi?id=866522
- Scott_Helme_ 11y ago
  Interesting, I don't use Firefox enough to have noticed this. Would it be possible to whitelist this functionality in your CSP in the short term without adversely affecting the strength of your policy?
  - hyperpape 11y ago
    Idlewords runs Pinboard, a bookmarking site, so I'm guessing he's worried about the impact of other people turning on CSP. I don't use Pinboard, but I believe I've encountered the problem using the Instapaper bookmarklet.
jasonlfunk 11y ago
Can you help me understand the graphs? What is being plotted on the X axis?
- cbr 11y ago
  I think popularity, from most to least?
  - Scott_Helme_ 11y ago
    Yes, sorry that wasn't clear. I scanned the sites in groups of 4,000. The x axis is each group in descending order from the top of the Alexa list to the bottom.
greggman 11y ago
I'd really like to know if any of you have used the report feature. It seems like any report you got would show you a bug in your code. What were the bugs? How many reports did you get?
- Scott_Helme_ 11y ago
  To be honest, most of the reports I get for my sites aren't legitimate issues. Malware on the endpoint makes changes to pages (like inserting ads) that generate reports, certain browser features trigger changes that cause reports. There are also browser plugins and addons that make changes which also cause reports to be sent. You can always create a report only CSP which will send reports but not block actions on the page and use my service at https://report-uri.io https://report-uri.io to gather the reports for you to look at them. All free and no risk of breaking anything, if you're interested.

116 points by bikeshack 11y ago

For people using Node/Express, Helmet is a useful little library that lets you add these security headers and CSP pretty easily: https://github.com/helmetjs/helmet https://github.com/helmetjs/helmet

gkop 11y ago
This is the counterpart for Ruby: https://github.com/twitter/secureheaders https://github.com/twitter/secureheaders
thephyber 11y ago
Lusca[1] is the NPM module for use with Express that comes in the KrakenJS middleware (open sourced by PayPal). app.use(lusca.csrf()); app.use(lusca.csp({ /* ... */})); app.use(lusca.xframe('SAMEORIGIN')); app.use(lusca.p3p('ABCDEF')); app.use(lusca.hsts({ maxAge: 31536000 })); app.use(lusca.xssProtection(true)); [1] https://github.com/krakenjs/lusca https://github.com/krakenjs/lusca

nly 11y ago

I've found HPKP and HSTS easy to trivial, but gave up on deploying CSP. It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline.

JoshTriplett 11y ago
> It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline. You can still use CSP, and whitelist specific third-party domains. (There's no way to whitelist inline code, though, and if there were it'd be more work than eliminating it and moving it to files.) But the refactoring is well worth doing. By eliminating inline JavaScript and off-domain JavaScript, you eliminate the possibility of script injection. And directly including third-party JavaScript (or CSS, which can include JavaScript) opens you up to various kinds of attacks.
- jacobparker 11y ago
  > There's no way to whitelist inline code That's not completely true - the nonce attribute (specify a nonce in the CSP header, have nonce=that on every script tag) or by sending the hashes of the inline scripts upfront in the CSP header. It doesn't give you inline code in attributes (e.g. onclick) but it's a big help for migrating.
  - JoshTriplett 11y ago
    Ah. I hadn't found that in Mozilla's CSP documentation. Thanks.
    - Scott_Helme_ 11y ago
      I'm going to be doing some blogs in the coming weeks on how to use hashes and nonces to whitelist inline script. Hopefully, this will make introducing CSP a little easier. I also have some tools in the making that will help in this regard too.
lol768 11y ago
You might find the Content-Security-Policy-Report-Only header useful for identifying CSP issues and deploying policies without actually blocking anything.
- deleted 11y ago
  [deleted]

STRML 11y ago

It's unfortunate that response headers on a secure website need to be bloated so much to receive benefits that should be default on modern sites. I imagine a world where you specifically have to opt-in to unsafe behavior, not the other way around, but of course this would break many existing sites. For those of you looking at this, I've found the X-Frame-Options (to prevent clickjacking via iframe) and Content-Security-Policy (to restrict eval, inline JS, JS and embed sources and more) to be the most useful headers by far. If you can run CSP without 'unsafe-eval' or 'unsafe-inline' and restrict all sources to your local domain, your site's security will be much better for it as an entire range of attacks is eliminated on modern browsers. Of course they are all worth looking at. Scott's header test (https://securityheaders.io https://securityheaders.io) is a great check for your own sites.

eli 11y ago
Some day that will probably happen, but of course the issue is that it would break every site that relies on the less secure behavior.
JoshTriplett 11y ago
> I've found the X-Frame-Options (to prevent clickjacking via iframe) I wish some way existed to prevent clickjacking (e.g. via invisible iframe) without actually banning frames. There are useful applications for framing another site that can't be achieved by any other means, apart from writing a browser extension. And framing a site without making it invisible seems like unfortunate collateral damage.
- hannob 11y ago
  Dan Kaminsky is working on something: http://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickjacking/ http://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickja...
Scott_Helme_ 11y ago
It's worth pointing out that you can replace the functionality of the X-Frame-Options header with Content-Security-Policy using the frame-ancestors directive if you want to: https://scotthelme.co.uk/csp-cheat-sheet/#frame-ancestors https://scotthelme.co.uk/csp-cheat-sheet/#frame-ancestors A world with opt-in to unsafe behaviour would be great, but a long way off I fear. Thanks for mentioning the header check service!

A010 11y ago

I gone through his previous blog post and found the changing Server: header field. Why have to waste time for rebuilding nginx from source for that? Why not just insert 'server_tokens off' in your nginx.conf?

nly 11y ago
Because it doesn't eliminate the Server header, "off" will return "Server: nginx". Just one of several "fuck you" features in nginx.
- A010 11y ago
  Server: header makes people gone mad?
  - JoshTriplett 11y ago
    It wastes space, and reveals unnecessary information about your server infrastructure.
    - FooBarWidget 11y ago
      As if turning it off helps. Nginx is so popular, attackers would just try Nginx-specific exploits right after trying Apache ones even if they don't know for sure whether you are running Nginx.
- Scott_Helme_ 11y ago
  Sadly nly is right. The only other option to change this is the ngx_headers_more module, but that still requires a rebuild. I suppose that way you at least get a little more functionality for your troubles.
  - nly 11y ago
    You also need that module to do per URI/path/regex match headers properly, because add_header + location blocks are woefully insufficient thanks to the way they are processed. This is one reason I gave up on CSP under nginx.

jacquesm 11y ago

HN uses x-frame-options:"DENY" to good effect which takes care of a fair number of click-jack tricks, it also uses strict-transport-security. But there is only so much you can do with headers, the real risks are in the documents themselves. How about a <nojs> </nojs> pair in the primary document disabling any kind of javascript execution in the space between the tags. And those tags should only work in the primary document.

dantillberg 11y ago
> How about a <nojs> </nojs> pair in the primary document disabling any kind of javascript execution in the space between the tags. But wouldn't folks still be able to inject scripts by just writing `</nojs><script>alert('hi')</script><nojs>`?
JoshTriplett 11y ago
CSP does exactly that; you can just ban inline scripts entirely.

dantillberg 11y ago

This post encouraged me to go through my own website and add a moderately strict CSP header, sans 'unsafe-inline' scripts/styles. Thanks!

Scott_Helme_ 11y ago
If you like, you could also add reporting to your CSP and get live feedback on it with https://report-uri.io https://report-uri.io It's free to sign up and use.

idlewords 11y ago

CSP breaks bookmarklets in Firefox, which makes it rather user-hostile. This is properly Mozilla's fault, but they've shown no interest in fixing it. https://bugzilla.mozilla.org/show_bug.cgi?id=866522 https://bugzilla.mozilla.org/show_bug.cgi?id=866522

Scott_Helme_ 11y ago
Interesting, I don't use Firefox enough to have noticed this. Would it be possible to whitelist this functionality in your CSP in the short term without adversely affecting the strength of your policy?
- hyperpape 11y ago
  Idlewords runs Pinboard, a bookmarking site, so I'm guessing he's worried about the impact of other people turning on CSP. I don't use Pinboard, but I believe I've encountered the problem using the Instapaper bookmarklet.

jasonlfunk 11y ago

Can you help me understand the graphs? What is being plotted on the X axis?

cbr 11y ago
I think popularity, from most to least?
- Scott_Helme_ 11y ago
  Yes, sorry that wasn't clear. I scanned the sites in groups of 4,000. The x axis is each group in descending order from the top of the Alexa list to the bottom.

greggman 11y ago

I'd really like to know if any of you have used the report feature. It seems like any report you got would show you a bug in your code. What were the bugs? How many reports did you get?

Scott_Helme_ 11y ago
To be honest, most of the reports I get for my sites aren't legitimate issues. Malware on the endpoint makes changes to pages (like inserting ads) that generate reports, certain browser features trigger changes that cause reports. There are also browser plugins and addons that make changes which also cause reports to be sent. You can always create a report only CSP which will send reports but not block actions on the page and use my service at https://report-uri.io https://report-uri.io to gather the reports for you to look at them. All free and no risk of breaking anything, if you're interested.