PCI scan for cPanel services: Insecure configuration of Cookie attributes
My recent PCI scan started flagging cookies from cPanel services:
Insecure configuration of Cookie attributes
Host xxx.xxx.xxx.xxx
-
Solution
It is important to set Secure and HTTPOnly flags for all the cookies on the application. The Secure flag prevents cookies from being transmitted over clear text. An HTTPOnly flag would limit cookie access in cases of Cross-Site Scripting issues.
Proper Caching headers should be set for responses carrying the cookie.
Cookies set on the client side should also contain Secure and HTTPOnly tags.
Ensure that any web applications running on this host is configured following industry security best practices.
DetectionDetails: Cookie Vulnerabilities Found
session_locale = ar
Path = /
Host = xxx.xxx.xxx.xxx
Cookie does not have an HTTPOnly Attribute
Request: GET https://xxx.xxx.xxx.xxx:2083/?locale=ar HTTP/1.1
When I log in using that URL, my browser's inpsector shows the "cpsession" cookie as having secure and httponly flags set. But if I use the Network tab in the inspector and record the login process, the resulting cpsession cookie response doesn't show those attributes included the response.
There seem to be multiple cookies listed in the inspector when this page is loaded.
How can I change those cPanel cookies to ensure the httponly and secure flags are always being set?
Thanks!
-
Hey there! Can you try the details outlined here to see if that helps with your situation?
0 -
Thanks! I just tried those steps, but modifying the premain include section as directed caused hosted websites to no longer show images (403 errors) on all pages, so I backed it out and the sites went back to normal.
Also, I received errors on the scan report also related to cookies, saying that there is "Insufficient Session Expiration" for the cookies generated for webmail (the "webmailsession") cookie. Is it possible to turn on cookie expiration anywhere for the webmail applications?
0 -
Thanks for that - after re-reading that, that would only apply to Apache and not the direct cPanel services.
In the past we have informed people this is a false positive as those links on port 2083 can only be accessed through a secure https connection:
Could you bring that up with your scanning team and see if that would let this specific item pass?
I am still looking into your other post as well.
0 -
Ok, I understand. I'll try reporting it as a false positive. Generally they want to know why it's a false positive and not a security issue. So I guess the answer is that "those links on port 2083 can only be accessed through a secure https connection"? Does that somehow make the lack of the httponly and secure flags on the cookie not necessary? Sorry, I don't really understand the risk that is caused by those flags missing, so I also don't understand how only accessing those services on secure connections would mitigate it. :)
0 -
The ASV responded to my submission of a false positive with the following question:
"Thank you for providing that information. Can your organization confirm that each of the cookies as cited in the evidence details are not responsible for starting or maintaining an authenticated session?"
I'm not sure I know the best way to answer that. The cookies in question are "whostmgrsession", "webmailsession", and "cpsession". I assume those cookies *are* used for maintaining authentication but I really don't know that. Perhaps authentication is managed some other way once successfully logged in?0 -
I spoke with the developers about this and got more details about the cookies situation.
Both the cPanel and WHM interfaces will pass non-secure cookies along with secure ones and this can sometimes cause a PCI scan to fail.
This behavior is intentional. When the user logs out we clear *both* the secure and non-secure versions to avoid a redirect loop. cpsrvd, the process that runs the cPanel and WHM services, won't actually set the insecure ones by default on the secure ports you have mentioned.
PCI Audits may be mistaken in identifying these cookies as a security concern. Their purpose is to invalidate the previously used cookies, after a failed authorization attempt. On successful authentication, a secure cookie will be used.
0 -
Thanks! While I don't fully understand how cookies cause redirect loops, I will pass this along to the scanner vendor as a false positive. Hopefully they'll understand the technical explanation better than I do and accept it. :)
0 -
I reported this information as a false positive, and they responded asking the same question (essentially saying they want a yes or no answer regardless of the reason):
"Can your organization confirm that each of the cookies as cited in the evidence details are not responsible for starting or maintaining an authenticated session?"
So is it true to say 'Yes," these cookies are not used for starting or maintaining an authenticated session?0 -
Basically yes - the insecure cookies are only even used if we need to invalidate previously set cookies. Here's a more technical explanation:
Some time ago, it was discovered wherein users whose sessions had been expired by the server were being forced into infinite redirect loops which were only being broken when the browser hit its redirect limit. To address this, if the session is expired on the server, cPanel will send invalid session cookies to the client to force the client to stop trying to use the old session information. Because the user might decide to switch between non-secure and secure webmail sessions (if the system administrator permits non-secure sessions), cPanel will send a version of the invalid session cookie without the secure flag set.
This particular use of non-secure cookies should never return a valid session cookie for a secure webmail session. If a user never logs into webmail via plaintext HTTP, any valid session cookies should be marked with the secure flag. (By default, cPanel will redirect all attempts to access its services over plaintext to an appropriate secure port.)
Because cPanel should only return an invalid non-secure cookie when it is only accessed via HTTPS, and because we recommend and default to not allowing insecure webmail logins, we do not consider the use of a non-secure cookie here to be a security concern.
The cPanel Service (cpsrvd) client won't pass non-secure cookies along with secure ones and this can sometimes cause a PCI scan to fail.
When logging out, we clear both the secure and non-secure versions to avoid a redirect loop that can occur in some instances. cpsrvd won't actually set the insecure ones by default, though, assuming you're always using HTTPS.
0 -
Thanks so much for that detailed explanation. I think I have a better grasp on the subject now. :)
1 -
You're very welcome!
0
Please sign in to leave a comment.
Comments
11 comments