Plesk cookies with "secure" attribute on 8443 port

[YSA]

Hi,

Recently we ran into a problem with PCI compliance scan on our sever with Linux Plesk 12.0.18 installed (CentOS release 6.6 OS).
The problem is that cookie which is sent when you open control panel login page at 8443 port does not have "secure" attribute. According to most recent PCI requirements such behavior is classified as PCI-fail.

From our side we've tried to turn on session.cookie_secure setting in php.ini (the one responsible for Plesk web interface), but looks like it has no impact on control panel behavior (while we see that the option is turned on via phpinfo() ), as cookies seem to be created on application-level.

Below we attach an example of http response headers:

HTTP/1.1 200 OK
Server: sw-cp-server
Date: Wed, 04 Nov 2015 22:21:01 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Expires: Fri, 28 May 1999 00:00:00 GMT
Last-Modified: Wed, 04 Nov 2015 22:21:01 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
P3P: CP="NON COR CURa ADMa OUR NOR UNI COM NAV STA"
X-Plesk: PSA-Key/PLSK032192340005
Set-Cookie: psaContext=dashboard; path=/

We believe that this issue should be addressed to control panel developers, could anyone advice on this?

Thanks.

 

[HostaHost]

Any response from Plesk?!

 

[SibProgrammer]

In general there is no reason to mark cookies that does not contain any sensitive information with "secure" attribute (such as psaContext, locale and etc) because such information is useless for the attacker. And PCI scanners were happy with such behaviour.

According to most recent PCI requirements such behavior is classified as PCI-fail.

Can you provide a link on some authoritative document, that describes these changes?

 

[HostaHost]

In general there is no reason to mark cookies that does not contain any sensitive information with "secure" attribute (such as psaContext, locale and etc) because such information is useless for the attacker. And PCI scanners were happy with such behaviour.


Can you provide a link on some authoritative document, that describes these changes?

Most things that PCI scanners fail you on have no basis in security or logic, they're one step up from script kiddies doing something because a scanning script they found online told them to. Unfortunately, proving to them why they're stupid is not typically easy to do.

I was able to manually dispute the failure by modifying /etc/sw-cp-server/conf.d/plesk.conf to add:

add_header Strict-Transport-Security "max-age=31536000";

Then the lack of 'secure' didn't matter because the browser was being told to only access the site securely.

Plesk can solve this issue in one of three ways to make your users not have to deal with PCI scan failures:

1) Make the above change to add the transport security header
2) Mark the cookie secure when served via https, and NOT when served via http
3) Prevent the nginx on 8443 from answering http requests on that port

Here is McAfee's text on the failure as an example:

VULNERABILITY DETAILS
CVSS Base Score: 6.4 AV:N/AC:L/Au:N/C/I/A:N CVSS
Temporal Score: 5.8 E:F/RL:W/RC:C
Severity: 2
QID: 150122
Category: Web Application
CVE ID: -
Vendor Reference: -
Bugtraq ID: -
Last Update: 10/19/2015
THREAT: The cookie does not contain the "secure" attribute. Based on the latest release of the PCI-DSS, this vulnerability is a PCI Fail. PCI-DSSv3.1 requirement 6.5.10 is focused on secure session management, and refers to session cookies needing to have the "secure" attribute set within the Cardholder Data Environment. Refer to PCI-DSSv3.1 for details.

IMPACT: Cookies with the "secure" attribute are only permitted to be sent via HTTPS. Session cookies sent via HTTP expose an unsuspecting user to sniffing attacks that could lead to user impersonation or compromise of the application account.

 

[AndreyZ]

The PCI DSS v3.1 standard says clearly:
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

6.5.10 Examine software development policies and procedures and interview responsible personnel to verify that broken authentication and session management are addressed via coding techniques that commonly include:
* Flagging session tokens (for example cookies) as “secure”
...

https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-1.pdf

Session Token
In the context of web session management, a session token (also referred to as a “session identifier” or “session ID”), is a unique identifier (such as a “cookie”) used to track a particular session between a web browser and a webserver.

Looks like McAfee (and maybe other scanners) wrongly treats `psaContext` (and maybe other cookies) as session tokens. This is a false positive error.
Plesk session cookies do have `secure` attribute.

Previously PCI scanners were happy with such behaviour, probably because of the following:
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

Note: Requirement 6.5.10 is a best practice until June 30, 2015, after which it becomes a requirement.

HTTP Strict Transport Security (HSTS) addresses threats related to cookies without `secure` attribute (https://tools.ietf.org/html/rfc6797#section-2.3.1.1). So this is a workaround. But do not forget that HSTS does not prevent a browser from using unencrypted HTTP before a first secure HTTPS request. One also need to configure redirect from HTTP to HTTPS (or close HTTP at all).
Anyway, it is good to configure HSTS and the redirect. I hope all this will be automated in Plesk in the future. (You can vote here: https://plesk.uservoice.com/forums/...port-for-http-strickt-transport-security-hsts).

Also note the following HSTS issues:
- Not all clients support HSTS: http://caniuse.com/#feat=stricttransportsecurity.
- HSTS is time limited, so session tokens must expire (on server) before HSTS expires (on client).
- Because HSTS is time limited, it is sensitive to attacks involving shifting the victim's computer time e.g. using false NTP packets: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#cite_note-23
So, it is still better for session cookies to have `secure` attribute.

 

[trialotto]

@Everyone,

First of all, thanks for the (in-depth) discussion, I enjoy this.

@Hostasaurus.Com already stated that

Plesk can solve this issue in one of three ways to make your users not have to deal with PCI scan failures:

1) Make the above change to add the transport security header
2) Mark the cookie secure when served via https, and NOT when served via http
3) Prevent the nginx on 8443 from answering http requests on that port

and the above suggestions underpin the lack of flexibility in configuration of the Nginx server for the Plesk Panel, with some related (alleged) "problems" mentioned on the forum being:

4) redirection of the Plesk Panel URL to some custom domain URL,
5) application of custom SSL certificates to the Plesk Panel,
6) SSL/TLS hardening of Nginx (even though forum users do not often discuss this topic in the light of Plesk Panel itself)

and so on (my apologies, this is not the place to summarize all of the directly or indirecty related issues).

In general, one is able to adjust the unique Nginx webserver that Plesk uses for it´s Panel.

However, there should be a default configuration that is able to tackle most of the mentioned issues, primarily those concerning security, including those mentioned by @Hostasaurus.Com.

Problem 1 can be solved by implementing the solution suggested by @Hostasaurus.Com.

Problems 2, 3 and 4 can be solved, if I am not mistaken, by replacing

error_page 497 https://$hostname:$server_port$request_uri;

by

return 301 https://<domain>:$server_port$request_uri;

in /etc/sw-cp-server/config, with <domain> some configurable domain (and, if not configured, the hostname by default).

Note that a script has to be created, in order to allow the configuration of the domain, i.e. to set the appropriate value.

Note that this method does not require server_name aliases, it is just redirecting automatically: to the custom domain, if an appropriate DNS record exists, otherwise to the hostname.

Problems 5 and 6 can also be solved with a script, allowing for choosing some options that can be automatically rendered in a conf file in the /etc/sw-cp-server/conf.d/ directory.


In essence, for normal domains we have to possibility to custom configure our Nginx settings, but for the Plesk Panel we do not have that option.

The structure is the same, the process is the same, the code is already present (i.e. can be "borrowed" from the code for normal domains) and so on.

In conclusion, it surprises me that this minor patch to Plesk core code has not been applied already, it would be of great value to all Plesk customers.

@SibProgrammer, @AndreyZ (and @Sergey L and @IgorG), is there any chance we can see such a patch in the near future?

Regards.....