PCI Fail - Session-Fixation Social Engineered Session Hijacking

I had a PCI fail due to 'Session-Fixation Social Engineered Session Hijacking'.

Before I go mucking things up, is there a quick admin setting change or file change to prevent this fail.

Admin session settings:
Cookie Domain: True
Force Cookie Use: False
Check SSL Session ID: False
Check User Agent: False
Check IP Address: False
Prevent Spider Sessions: True
Recreate Session: True
IP to Host Conversion Status: true
Use root path for cookie path: False
Add period prefix to cookie domain: True

Details of the fail are below:
Threat: The scanner found a Web application on the target that uses cookies. The application seems to use cookies (likely, session IDs) in an insecure way. Specifically, the scanner created a web session with the target using a session ID specified by the scanner itself. The target application simply started a new session with this specified session ID. This issue is generally called "session-fixation" and is vulnerable to session-hijacking attacks.
One scenario where this could be used to hijack an unsuspecting user's Web session is as follows. Assuming an online store, https://www.examplestore.com, has this security issue. If an attacker uses social engineering techniques to make a target user click on a link (in an email or on a malicious Web site) like http://www.examplestore.com/?PHPSESSID=12345, where PHPSESSID is the cookie used for identifying the session, the store will start a new session for the unsuspecting user with the session ID 12345. Then, since the attacker knows the session ID already, the attacker can simply hijack the session moments after the user has visited the store.

Impact: By exploiting this vulnerability, an attacker could use the hijacked session for information gathering, invasion of privacy, property theft, or credit-card theft.
For more information about the way session-fixation attacks can be performed and the possible consequences of such attacks, read this paper.

Solution: This is a common issue web-developers come across, and many application-specific solutions exist.
The PHP package itself provides a "php.ini" based global configuration option called "session.use_only_cookies" (introduced in PHP Version 4.3.0). This is disabled by default for backward compatibility. When enabled, this allows PHP session IDs to be set only via HTTP cookies. This makes GET/POST based hijack attacks possible only when there is significant activity by an unsuspecting user.
For more information, read the Sessions and Security description provided on PHP's Web site.
For solutions in other web packages, check the relevant documentation.

To apply the offered solution would be to change the setting for Force Cookie Use from false to true.

This will require a cookie to be present to support maintaining session data and there should no longer be a zenID when initiating a new session with the store. It will however have a negative effect for those that have disabled all cookies instead of say just third party cookies as a privacy setting.

Wait before you do that... What version of Zen Cart & PHP. Most likely this is a false positive and you should have them check it manually. I just manually tested 1.5.6C & PHP 7.3 and the session was not activated much less carried forward.

~Melanie

Further to @Mprough's remarks, I have seen this kind of behavior in PHP 5.6 but never in PHP 7+.

PHP 7.1.33
Zen-Cart 1.5.5f

Might need to upgrade the cart the rest of the way prior to making any changes.

i tend to agree with @mprough. i am not sure who is doing your vulnerability scan; as the info they have provided seems inaccurate and misleading.

from your server info page, what is the value of:

session.use_only_cookies

this should be set to 1 to prevent the kind of hijacking mentioned in the scan. as of php 5.3, the default is 1. see:

https://www.php.net/manual/en/session.configuration.php#ini.session.use-only-cookies

I received the same PCI scan vulnerability for my shop. I have manually confirmed the vulnerability is present.

I have v1.5.7c running on PHP 7.3.20, and I have set "Force Cookie Use" to true but the test still succeeds. Here's how it works:

If I access my shop with the following URL: "https://shop.example.com/?zenid=0123456789abcdef0123456789abcdef" a new session is created using the supplied id. (Note that we actually use a custom session name rather than "zenid".) This can be confirmed by checking the session cookie in the developer tools. I have also confirmed the behavior in an older shop that we have running v1.5.0.

I have traced this behavior to line 65 in /init_includes/init_sessions.php "zen_session_id($_GET[zen_session_name()]);". A quick fix would be to disable this line (and the conditional before it) so that session id's are never set from GET but only from POST. What I want to know is what side effects would this have for my shop?

Our PCI scanning provider, Sysnet Global Solutions, considers this a high risk vulnerability. I can't mark it as a false positive since I can reproduce it myself. They say that it is vulnerable to social engineering attacks where the session can be hijacked.

I have traced this behavior to line 65 in /init_includes/init_sessions.php, which is "zen_session_id($_GET[zen_session_name()]);". A quick fix would be to disable this line (and the conditional before it) so that session id's are never set from GET but only from POST. What I want to know is what side effects would this have for my shop?

Hoping that DrByte can confirm whether or not this is a safe work-around. Seems straight-forward enough but a bit afraid to try it without confirmation from DrByte or someone else that has successfully implemented this fix.