PCI Compliance Session-Fixation
Posted: Tue Jan 26, 2016 5:13 pm
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.
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.