Locations https://grafana-openshift-monitoring.apps.test.labs.com Description The secure flag is used to prevent any sensitive cookie values from being sent over an unencrypted channel. When the secure flag is set by the server the browser will not transmit the cookie over HTTP The affected application fails to set this flag on what appears to be a session token. A suitable placed attacker could perform a Man in the Middle attack to downgrade an SSL connection from a client and capture the cookie value when it sent over HTTP even if the backend server rejects the connection the client will still attempt to send it via HTTP. Exploitation The following cookie is set by the Grafana application without the Secure flag set Recommendations The secure flag should be set on all cookies that are used for transmitting sensitive data when accessing content over HTTPS – including session tokens. References https://cwe.mitre.org/data/definitions/614.html
> The following cookie is set by the Grafana application without the Secure flag set What cookie? Can you also provide the haproxy.config (or at least the configuration block for the backend corresponding to the route)? It is possible the router set a cookie for session stickiness, but if it did, the cookie should be marked secure: https://github.com/openshift/router/blob/e7479192fadbc469e6f16ef752c5acfa99519690/images/router/haproxy/conf/haproxy-config.template#L442-L443
The referred cookie is grafana_sess. Regards, Sergio
The cookie in question is set by Grafana, so I am moving this Bugzilla report to the Monitoring component (which I hope includes Grafana). It seems like the problem could be solved by adding "cookie_secure = false" to the base64-encoded grafana.ini here, but I have not tested such a change: https://github.com/openshift/cluster-monitoring-operator/blob/master/assets/grafana/config.yaml
Merged the fix for 3.11 https://github.com/openshift/cluster-monitoring-operator/pull/546 We're continuing with the 4.x releases.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:4050