Hardening HTTP Headers

[franzliedke]

Probably a good idea... here's a nice checklist: https://scotthelme.co.uk/hardening-your-http-response-headers/

[d1a8lo24]

I may be wrong but most of the information concerning http headers on the link your provided is for server administrators to apply on the server side and not really via an application since most of the configurations there have to do with how a server response and replies. Most of the rules and configurations there are using the htaccess file to overwrite standard headers and when it comes to playing with the htaccess file many servers will respond differently or will just give a 500 error for miss configuration.

And not only that but most apply to either virtual servers or dedicated servers where you have more control, when it comes to share hosting that's where problems may happen since some of the configurations may not be available. Some share hosts don't even allow for you to have an htaccess file or a php.ini file, to turn on or off some of the configurations.

The reason for this is because most people don't really know what they are doing so instead of making their site more secure they end up making it less secure or to the point of overloading because of miss configuration

And yes you can have some control of certain headers with PHP but they still rely on the rules of the server so even though you're sending a particular header if the server decides not to send it or to allow to overwrite it then it won't be applied..

I wouldn't put this as a feature or start playing on how an application should send headers since it will become more of a headache because of the many types of servers and configurations there are out there but it should be something people should have as a reference no matter what type of site they are running is always good to know what you can apply for "security" on a server that allows it..

But then again I may be wrong, is not like I read the whole thing but just by browsing I did notice a lot of configurations there I have done on my own server via htaccess, again it was not something that many of my applications required or could be apply through them but because is good standards to follow when you're running a server.

[franzliedke]

I think things like the Frame-Options headers (or Content-Security-Policy, as it's now called if I'm not mistaken) are pretty useful (e.g. for preventing clickjacking attacks). We'll be careful about what we consider. :)

[d1a8lo24]

Yes those are headers that need to be applied via the htaccess file as a user or the server response header configurations file or similar by the server admin or host server admins.
Not via the application because of the limitations of many share hosts which can end up giving errors of miss configuration since many of them may not allow certain settings.

Most content security headers are use for CDNs and calls for REST requests and API requests as far as clickjacking this is not just a concern for Flarum this is for any site out there.

As I said before is should not be a feature but a reference somewhere in the installation guide or best practises.

Looking at other applications out there you can see that none of them will try to do this not because they can't but because not every server out there is capable of applying such settings via the application.

Just look at how many problems many people have because the htaccess file doesn't have the right configuration for re routing URLs for their server configuration.
Not only you have to worry about Nginx, lighttpd etc... and how they are configure with Apache or any other platform but also you have to worry about how much flexibility do they have to configure that server.

To me just be careful trying to play with the htaccess file and headers, the application shouldn't rely too much on this unless really necessary.

But it is nice to have that link as a reference somewhere in the docs is always nice to have a second look at what a user can apply on their server for security.

Here is another great reference for the htaccess file and the many setting you can apply through it.

https://github.com/phanan/htaccess

[askvortsov1]

@franzliedke maybe we can solve this by just adding these into the default skeleton?

[askvortsov1]

On second thought, another idea. Django's middleware processes both requests and responses. I don't know if we want to have our current middleware stack do both (although I'd like that), but there should definitely be a way to apply some form of response processing, including applying relevant security headers.

[tankerkiller125]

Some notes on the linked list:

• HSTS is 100% server admin, we can't force this ourselves because some (rare) people might want HTTP
• CSP could be done on the application, but it's better for the admin to do this because of extensions
• HTTP PKP is outdated and most browsers no longer support it (and it's hard to do correctly)
• X-Frame-Options would be good to do but should have an extender of some sort to add domains to the allowed list
• X-Xss-Protection should 100% be enabled, there is zero good reason not to have this on the application side
• X-Content-Type-Options can/should be done, normally done server side but could also be done application side
• Removing headers nothing we can do about that

So out of all of those I only see 2-3 that we can/should do, the rest should be up to the admin, we could possibly have a link in the docs someplace to consistently updated security header information for various web servers officially listed (Apache, Nginx, Caddy)

[askvortsov1]

Agree as to all of these. I guess the next step would be a Middleware that adds frame options, xss protection, and content type options.

As to CSP, I like it, but it's something that we'd need to support first. I think that should be split into its own issue, with incremental steps taken (both in core and in extensions) to achieve it. Discourse has it on by default, I see no reason why we couldn't do the same.

[tankerkiller125]

@askvortsov1 the best way I can see CSP being done is if we bring in a lib that specializes in building CSP strings, and then allowing extension devs to using an extender or something that uses that lib to add to the default string.

[tankerkiller125]

Some additional stuff for CSP if we did it, there are two CSP string builders that I can find that look decent:

• https://github.com/paragonie/csp-builder
• https://github.com/martijnc/php-csp

A CSP string builder would be required to properly support extensions, further I would love to see proper use of nounce for any inline scripts.

[askvortsov1]

To clarify, for this issue, we don't need CSP (or optimizing for CSP) yet. Although if someone is up for it, I definitely wouldn't complain

[askvortsov1]

Actionable steps:

• X-Frame-Options would be good to do but should have an extender of some sort to add domains to the allowed list
• X-Xss-Protection should 100% be enabled, there is zero good reason not to have this on the application side
• X-Content-Type-Options can/should be done, normally done server side but could also be done application side

but should have an extender of some sort

This should be an array in config.php

CSP should be a separate issue (https://github.com/flarum/core/issues/2702)

[askvortsov1]

We might also want to consider Referrer Policy and Permissions Policy (the latter needs an extender):

https://securityheaders.com/?followRedirects=on&hide=on&q=discuss.flarum.org

[tankerkiller125]

I agree we should also include the referrer policy header and use a config for that.

[tankerkiller125]

After further research it appears that X-Frame-Options doesn't make sense as it's basically deprecated at this point. We could set it to SAMEORIGIN for a simple sane default. But there are no browsers that follow the ALLOW-FROM option.

[askvortsov1]

Lets drop it then, one less thing to configure