Hi,
One of our customers has run a security analysis on their system and has reported that there is a significant vulnerability with regard to our Nettalk WebServer application. The analysis was performed by Barclays Bank for their ongoing PCIDSS Compliance of card payment machines on the LAN. It appears to me in my limited knowledge that the Session ID is what they are highlighting, but beyond that I'm lost.
Does anyone have any suggestions, comments or advice about what we can do about this or what we can reply with? I would be most grateful if anyone has anything to share.
I have pasted part of their email 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,
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.
RESULT:
GET /?SESSIONID=0123456789abcdef0123456789abcdef HTTP/1.0
Host: 77-44-120-131.xdsl.murphx.net
HTTP/1.1 200 OK
Date: Thu, 16 Sep 2021 15:53:57 GMT
Expires: Wed, 16 Sep 2020 15:53:57 GMT
Content-Length: 2577
Content-Type: text/html
Cache-Control: no-store, no-cache, must-revalidate, private,post-check=0, pre-check=0, max-age=0
Pragma: no-cache
Set-Cookie: SESSIONID=0123456789abcdef0123456789abcdef; path=/; secure; HttpOnly; SameSite=Strict
Connection: close
Access-Control-Allow-Origin: *
X-Frame-Options: sameorigin
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
X-Xss-Protection: 1; mode=block
<!DOCTYPE html><html class=" nt-html no-js">
<head>
<title>EDGE Anywhere</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="viewport" content="initial-scale=1">
<link href="/themes/base/theme.css?c=12.17" rel="stylesheet" />
<link href="/redactor/redactor.min.css?c=12.17" rel="stylesheet" />
<script src="/scripts/all.js?c=12.17" type="text/javascript"></script>
<script src="/redactor/redactor.min.js?c=12.17" type="text/javascript"></script>
</head>
<body class=" PageBody">
<div id="body_div" class=" PageBodyDiv">
...... rest of page
"
Topic: Security analysis vulnerability reported (Read 7848 times)