PCI Compliance Session-Fixation

Hi,

I have managed to clear all but one PCI compliance message on my quarterly scan...

Session-Fixation Social Engineered Session Hijacking

Can anyone help, it seems to imply as below, what do I need to do to combat this or is the scanner at fault?

Below is an extract from the scanner report... any help would be greatly appricated?

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, 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.

Further to the above it seems Version 1.5.6.4 is ok but Version 2.1.0.2 fails can anyone shed any light on this?

Thanks in advance.

Were you ever able to get this fixed?

Sorry for resurrecting such an old post, but for some reason this has just been flagged in a PCI scan, but hasn't shown up before.

V2.3.0.2

We have recently changed our hosting package, so could it be something to do with that? It is with the same provider and it was seamless, so I don't think we physically moved servers.

sooty wrote: ↑

Fri Mar 29, 2024 3:47 pm

Sorry for resurrecting such an old post, but for some reason this has just been flagged in a PCI scan, but hasn't shown up before.

V2.3.0.2

We have recently changed our hosting package, so could it be something to do with that? It is with the same provider and it was seamless, so I don't think we physically moved servers.

Does the PCI scan give any more details? Have you set session.use_strict_mode to On? Although you will probably have to fix the broken session handler as well.