search

elkarte / Elkarte

ElkArte Forum. A free, open source, modern discussion forum / BB
https://elkarte.github.io/Elkarte/
BSD 3-Clause "New" or "Revised" License
175 stars 61 forks source link

Support for current HTTP security features #2614

Closed tomreyn closed 8 years ago

tomreyn commented 8 years ago

ElkArte 1.1.0 Beta1 does not currently support some of the (more or less) newer HTTP/S security features, which can easily prevent many types of common web application attacks. Most of which will not impact the user experience.

Specifically, the following techniques are not currently being used, or disabled by default:

The only header which will, if enabled, definitely need to be modified by the forum admin here is `Content-Security-Policy. The above can be a useful default (but the application would have to replace FORUMHOSTNAME and FORUMDOMAINNAME by the respective values, as determined during installation and written to its configuration file), but must be modifiable. Also, (only) this configuration should be disabled by default since it does require the forum admin to understand its implications. Ideally, the developers should improve the application so it no longer depends on 'unsafe-inline' and 'unsafe-eval' values.

All of the modifications discussed above could also be made on the web server (or intermediary servers which can modify HTTP headers), but most likely the average user will not do so. As such, it would be nice to have the application (optionally?) set these headers and, where needed, make them available from the admin interface or configuration file. Also, specifically for X-Frame-Options and Content-Security-Policy, the application will have a much better understanding than the other intermediaries (including the web server) of what should be configured, so there it makes sense to have the application have a say on how these should be set.

In case the developers feel uncomfortable with setting HTTP headers, an alternative approach would be to just add a 'calculator' / wizard type section to the admin interface which would suggest how these headers could or should be set based on the environment known to the application at runtime.

Vekseid commented 8 years ago

CSP is not appropriate with the current state of Elkarte, any SMF derivative, or most forum software period. Once we finally manage to purge the system of inline javascript and css, then we could talk. Implementing it as-is is just security theater.

X-Content-Type-Options - only useful for SMF's broken attachment system. Most people should be setting this at the webserver.

Frame Options has been obsoleted by CSP, above. Most people should be setting this at the webserver.

X-XSS-Protection - no. This header exists only so that you can turn it off. Nothing that understands it defaults to unblock.

Cookie flags are valid, however.

emanuele45 commented 8 years ago

Related discussion #1288

emanuele45 commented 8 years ago

If I read it right, it seems the frame-ancestors directive is basically the equivalent of the X-Frame-Options we already support?

tomreyn commented 8 years ago

It is actually more than this, but you are also right. However, to date, CSP level 2 directive frame-ancestors is not supported in anything but Chrome / Chromium, Firefox and Opera (and their derivatives). X-Frame-Options, however, is also interpreted by Internet Exploiter (and I would guess by Edge, too), so it does have its specific use case.

Vekseid commented 8 years ago

I would be fine with an option to have frame-options set, but since I do this at the webserver level it tends to feel a bit redundant.

tomreyn commented 8 years ago

It would be redundant in your case, but I would assume you can be too proficient to make a good example of what the average user setting up a forum will do. However, adding a wizard / online / offline documentation which will help you set (some of) those headers up can be a nice improvement, too (IMO).

emanuele45 commented 8 years ago

What's left if the CSP and the option to specify websites in X-Frame-Options (that could later be inherited by CSP).

Unless I missed something.

emanuele45 commented 8 years ago

https://github.com/emanuele45/Dialogo/commit/f5e15207eb355fccbe6d9fe62222368c73933342 <= cookies on

emanuele45 commented 8 years ago

Just for cross-reference: @tomreyn XFO is supported by IE/FF, but only partially by chrome and derivatives (i.e. allowed-from is not supported at all). So, in any case we cannot cover all the spectrum of browsers without implementing both. Since this is basically the only one left here, I would close this issue and continue on #1288 originally opened exactly to track XFO and CSP.

tomreyn commented 8 years ago

I'm not sure I understand when exactly the 'secure' cookie flag will be set (and when it won't), and whether this translates to the behaviour site admins / users will expect. I am happy to wait and see how it will work in the next release, though.

Also, I had commented on the eventuality of not catching secure sessions at https://github.com/emanuele45/Dialogo/commit/bf3894feb2ba43560a6692e99bf0e88ecd98b048

Finally, you need to also take into account situations where HTTPS is spoken but it cannot be determined by the application since SSL is terminated on a load balancer or reverse proxy (server side). I.e. site admins should be able to choose freely whether or not to enable the 'secure' flag. My current understanding is that this choice is not implemented, yet.

emanuele45 commented 8 years ago

I'm not sure I understand when exactly the 'secure' cookie flag will be set

As you asked, it is set on by default, except when is disabled for non-HTTPS connections (or at least for things that look like non-HTTPS connections). If that's what you mean.

Finally, you need to also take into account situations where HTTPS is spoken but it cannot be determined by the application since SSL is terminated on a load balancer or reverse proxy (server side). I.e. site admins should be able to choose freely whether or not to enable the 'secure' flag. My current understanding is that this choice is not implemented, yet.

Well, admin are already able to enable or not secure cookies. It's been like that since... the SMF times.

To be completely honest, I'm not really expert on the matter (and it's fairly evident from both my comments and my commits), I based most of my actions on your explanations, likely misinterpreting few things. If the use-case are so complex, I'm temped to consider to revert the "on-by-default" and let the admin decide what to do based on his knowledge, because apparently there are way too many edge cases that may result in a non-working system... :confused:

tomreyn commented 8 years ago

Well it's not that complex really. There are three scenarios:

  1. Website is available via HTTP only, In this case, enabling the secure cookie flag would be bad, since this would break the site entirely.
  2. Website is available via HTTPS only (possibly with a HTTP -> HTTPS redirect). In this case, enabling the secure cookie flag is a really good idea.
  3. Website is available via both HTTP and HTTPS (same content, no redirections). In this case, admins may want cookies (and thus login sessions) to work on both HTTP and HTTPS connections. If so, the secure cookie flag would break the HTTP variant.

As previously pointed out, you might also have a mixture of these scenarios with a server-side TLS terminating proxy (load balancer, firewall, reverse proxy cache, ...). This situation cannot be reliably detected by the application, which is why in all of the above three scenarios, the admin still needs to be able to override, separately for HTTP and HTTPS connections to the application, whether or not the secure cookie flag is to be set.

And since this bears the potential for locking the admin (and anyone) out, this needs to be configurable by editing a configuration file (possibly in addition to a web based configuration).