Cannot apply secure flags on icingaweb2-tzo cookie

mrgohin commented 4 years ago

Describe the bug

This is not really a bug report.

I configured a few http cookie flags which shall improve security of mine reverse proxy.

In the first place everything seem to be fine but the particular cookie "icingaweb2-tzo" won't take action of those settings. So my question is when will this cookie be applied?

To Reproduce

Provide a link to a live example, or an unambiguous set of steps to reproduce this issue. Include configuration, logs, etc. to reproduce, if relevant.

Setup a reverse proxy (i.e. HA Proxy)
Configure Set-Cookie with Path:/; HttpOnly; Secure; SameSite=Lax
Open up Icinga Web 2
Verify cookie settings

Expected behavior

A clear and concise description of what you expected to happen. grafik

Screenshots

If applicable, add screenshots to help explain your problem.

grafik

Your Environment

Include as many relevant details about the environment you experienced the problem in

Icinga Web 2 version and modules (System - About): 2.8.1
Web browser used: Firefox Browser 81.0.1
Icinga 2 version used (icinga2 --version): r2.12.0-1
PHP version used (php --version): 7.3.19-1~deb10u1
Server operating system and version: Debian 10.6

Additional context

Add any other context about the problem here.

lippserd commented 4 years ago

Hi @m4k5ym,

Thanks for the report. This cookie is written via JS. If you're familiar with JS, you can fix that in public/js/icinga/timezone.js and create a PR.

Best regards, Eric

mrgohin commented 4 years ago

Hi Eric,

thanks for your quick and informative response. I will have a look into it and try to provide a reasonable fix / pr for it.

See ya

lippserd commented 4 years ago

Cool stuff. If you have any questions, don't hesitate to ask. I think it makes sense to check for https in location.protocol and then set the secure flag accordingly.

mrgohin commented 4 years ago

At the moment I'd like to focus on a framework wide implementation which is configured "once for all".

Whenever a new cookie will occur it should use the framework given settings to secure it properly.

nilmerg commented 4 years ago

Hi,

what exactly do you mean with a framework wide implementation? We don't have that much cookies (and no plans to introduce more) that this would be worthwhile in my opinion. The timezone cookie only does not obey the server's cookie configuration because it's managed by Javascript. So making the Javascript use the server's cookie configuration sounds like overkill to me, if it's only about the secure flag, which (as Eric suggested) can easily be derived from the URL.

If that is what you had in mind? If instead you want to provide a utility in Javascript to create a cookie, which then is used by timezone.js, I could be up for it.

mrgohin commented 4 years ago

Hi,

That may be correct that the framework itself won't have that much. However since it is a framework other users might come to the idea to use cookies for their modules. So I'd like to be able to obtain those policy from the framework itself to be sure that my module is conform with the framework given policy. I don't think that would be overkill to tell javascript "yo check that configuration file for your cookie settings".

I just don't like it if software is ignoring my given security policy.

nilmerg commented 4 years ago

I just don't like it if software is ignoring my given security policy.

Who doesn't? :laughing:

Though, I'd like to avoid having configuration for our JS at all cost. None of our JS currently requires configuration in any way and I want to keep it that way. Also, configuration might suit your case, but by not requiring to configure this, other not-so-aware users will also profit if it is safe out of the box.

So my alternative would be defining proper defaults or deriving the required facts from other sources:

HttpOnly: Can't be set by JS anyway if JS is it which creates the cookie in the first place
Secure: Could be derived from document.location. It doesn't make sense setting this if it's not a https connection and doesn't hurt if it is
SameSite: Defaults to lax. Though, this is the default anyway in recent browser versions if MDN is to be believed

So applying the flags ;secure;samesite=lax to the timezone cookie should solve your needs. Yes, the cookie is then still not httponly, though changing this would not only require reading configuration, but an entire refactor of how Icinga Web 2 detects the user's timezone. And in all seriousness, I don't think this is anyone's time worth, as it's only a timezone cookie. Not a cookie with any important information.

And regarding your concern that third party code may still not create cookies safely: This only applies to third party Javascript as by creating cookies with PHP the cookie configuration is already respected. But really, I can assure you that there are very few modules out there which make heavy use of Javascript, let alone of cookies created by Javascript. So I'd only adjust timezone.js as described above and be done with it.

If you really want a way for your module to create a cookie in Javascript that already uses these defaults, I'd suggest a new method createCookie(...) in utils.js which then is also used by timezone.js.

Do you agree?

Icinga / icingaweb2