Predictable Cookie Session IDs
Severity: Medium
PCI Status: Fail
Description: The remote web application is using predictable cookie-based session IDs. Ideally, session IDs are randomly generated numbers that cannot be guessed by attackers. If the session ID is predictable, an attacker could hijack an active victim's session, allowing the attacker to interact with the server as though they were the victim. If the session ID is used to track the state of authentication, the session ID of an authenticated user could be guessed, bypassing any need for a username or password.
Remediation: This software needs to be either configured or modified to generate random session IDs.
Apparently, the cookies being generated aren't random enough or something.
How do I fix this?
You should be able to subclass wwSession and override the GenerateSessionId() function with something that satisfies TrustWave.
Carl
When our website is scanned by TrustWave for PCI Compliance, we're having the following reported:
Predictable Cookie Session IDs
Severity: Medium
PCI Status: Fail
Description: The remote web application is using predictable cookie-based session IDs. Ideally, session IDs are randomly generated numbers that cannot be guessed by attackers. If the session ID is predictable, an attacker could hijack an active victim's session, allowing the attacker to interact with the server as though they were the victim. If the session ID is used to track the state of authentication, the session ID of an authenticated user could be guessed, bypassing any need for a username or password.
Remediation: This software needs to be either configured or modified to generate random session IDs.
Apparently, the cookies being generated aren't random enough or something.
How do I fix this?
Allen
Hi Allen,
You should be able to subclass wwSession and override the GenerateSessionId() function with something that satisfies TrustWave.
Carl
When our website is scanned by TrustWave for PCI Compliance, we're having the following reported:
Predictable Cookie Session IDs
Severity: Medium
PCI Status: Fail
Description: The remote web application is using predictable cookie-based session IDs. Ideally, session IDs are randomly generated numbers that cannot be guessed by attackers. If the session ID is predictable, an attacker could hijack an active victim's session, allowing the attacker to interact with the server as though they were the victim. If the session ID is used to track the state of authentication, the session ID of an authenticated user could be guessed, bypassing any need for a username or password.
Remediation: This software needs to be either configured or modified to generate random session IDs.
Apparently, the cookies being generated aren't random enough or something.
How do I fix this?
Just a thought. Using SYS(2015) is useful from a uniqueness standpoint but TrustWave may see it as being predictable. The Session ID is 14 characters long so maybe you could generate a 5 character random string and concatenate substr(sys(2015),2) to the end of it. That should give you uniqueness without looking quite so predictable.
Or I think you could make the SessionID field larger, overriding oSession.CreateTable(), and get more creative while still using sys(2015) for uniqueness, perhaps stuffing portions of sys(2015) into a randomly generated string at specific positions.
Craig Boyd's vfpencryption.fll has a GenerateKey() method that can create a random string of whatever length you need if you don't feel like rolling your own.
Carl
Good idea. What's the best way to generate a truly unique session ID without having to scan the session table every time one is created to ensure it hasn't already been used?
Allen
Hi Allen,
You should be able to subclass wwSession and override the GenerateSessionId() function with something that satisfies TrustWave.
Carl
When our website is scanned by TrustWave for PCI Compliance, we're having the following reported:
Predictable Cookie Session IDs
Severity: Medium
PCI Status: Fail
Description: The remote web application is using predictable cookie-based session IDs. Ideally, session IDs are randomly generated numbers that cannot be guessed by attackers. If the session ID is predictable, an attacker could hijack an active victim's session, allowing the attacker to interact with the server as though they were the victim. If the session ID is used to track the state of authentication, the session ID of an authenticated user could be guessed, bypassing any need for a username or password.
Remediation: This software needs to be either configured or modified to generate random session IDs.
Apparently, the cookies being generated aren't random enough or something.
How do I fix this?
? CreateSessionId()FUNCTION CreateSessionId
LOAPI = CREATEOBJECT("wwAPI")
lcGuid = loApi.CreateGuid()
lcUnique = "_" + TRIM(RIGHT(lcGuid,13),0,"}")
RETURN lcUnique
ENDFUNC
You can still tag on the ProcessId to make it unique per process and you'll need to widen the field to 20 characters maybe.
However there's no guarantee that this ID will be truly unique. Only a full GUID is 100% unique - chunking off small chunks makes it less unique. However, for tempoary state like Session IDs that expire over time this is likely good enough.
+++ Rick ---
Good idea. What's the best way to generate a truly unique session ID without having to scan the session table every time one is created to ensure it hasn't already been used?
Allen
Hi Allen,
You should be able to subclass wwSession and override the GenerateSessionId() function with something that satisfies TrustWave.
Carl
When our website is scanned by TrustWave for PCI Compliance, we're having the following reported:
Predictable Cookie Session IDs
Severity: Medium
PCI Status: Fail
Description: The remote web application is using predictable cookie-based session IDs. Ideally, session IDs are randomly generated numbers that cannot be guessed by attackers. If the session ID is predictable, an attacker could hijack an active victim's session, allowing the attacker to interact with the server as though they were the victim. If the session ID is used to track the state of authentication, the session ID of an authenticated user could be guessed, bypassing any need for a username or password.
Remediation: This software needs to be either configured or modified to generate random session IDs.
Apparently, the cookies being generated aren't random enough or something.
How do I fix this?
In Web Connection 6.0 I'll be switching over to this algorithm:
************************************************************************
* wwSession :: GenerateSessionId
****************************************
*** Function: Generates a new SessionId value
*** Assume:
*** Pass:
*** Return:
************************************************************************
PROTECTED FUNCTION GenerateSessionId
LOCAL loAPI
loApi = CREATEOBJECT("wwAPI")
RETURN TRIM(RIGHT(loApi.CreateGuid(),13),0,"}") +;
PADL(TRANSFORM(_VFP.ThreadID),5,"0")
ENDFUNC
* wwSession :: GenerateSessionId
which uses a partial GUID. The last part of the Guid is the local machine unique bit so as long as you run on a single server this will be guaranteed unique. On another machine chances of conflict are also very slight.
This widens the wwSession table to 20 though and I also switched the field to VarChar() while updating the code.
+++ Rick ---
Hi Allen,
Just a thought. Using SYS(2015) is useful from a uniqueness standpoint but TrustWave may see it as being predictable. The Session ID is 14 characters long so maybe you could generate a 5 character random string and concatenate substr(sys(2015),2) to the end of it. That should give you uniqueness without looking quite so predictable.
Or I think you could make the SessionID field larger, overriding oSession.CreateTable(), and get more creative while still using sys(2015) for uniqueness, perhaps stuffing portions of sys(2015) into a randomly generated string at specific positions.
Craig Boyd's vfpencryption.fll has a GenerateKey() method that can create a random string of whatever length you need if you don't feel like rolling your own.
Carl
Good idea. What's the best way to generate a truly unique session ID without having to scan the session table every time one is created to ensure it hasn't already been used?
Allen
Hi Allen,
You should be able to subclass wwSession and override the GenerateSessionId() function with something that satisfies TrustWave.
Carl
When our website is scanned by TrustWave for PCI Compliance, we're having the following reported:
Predictable Cookie Session IDs
Severity: Medium
PCI Status: Fail
Description: The remote web application is using predictable cookie-based session IDs. Ideally, session IDs are randomly generated numbers that cannot be guessed by attackers. If the session ID is predictable, an attacker could hijack an active victim's session, allowing the attacker to interact with the server as though they were the victim. If the session ID is used to track the state of authentication, the session ID of an authenticated user could be guessed, bypassing any need for a username or password.
Remediation: This software needs to be either configured or modified to generate random session IDs.
Apparently, the cookies being generated aren't random enough or something.
How do I fix this?
The problem is that random strings are generally not 100% unique. The algorithm we use for Session Ids is not 100% unique, but pretty close because we add the thread ID which for a single machine will be unique and SYS(2015) counts up (doesn't repeat until it rolls over).
In Web Connection 6.0 I'll be switching over to this algorithm:
************************************************************************
* wwSession :: GenerateSessionId
****************************************
*** Function: Generates a new SessionId value
*** Assume:
*** Pass:
*** Return:
************************************************************************
PROTECTED FUNCTION GenerateSessionId
LOCAL loAPI
loApi = CREATEOBJECT("wwAPI")
RETURN TRIM(RIGHT(loApi.CreateGuid(),13),0,"}") +;
PADL(TRANSFORM(_VFP.ThreadID),5,"0")
ENDFUNC
* wwSession :: GenerateSessionId
which uses a partial GUID. The last part of the Guid is the local machine unique bit so as long as you run on a single server this will be guaranteed unique. On another machine chances of conflict are also very slight.
This widens the wwSession table to 20 though and I also switched the field to VarChar() while updating the code.
+++ Rick ---
Thanks for the helps, guys!
Use Guid and strip part of it off to match the length you need.
? CreateSessionId()FUNCTION CreateSessionId
LOAPI = CREATEOBJECT("wwAPI")
lcGuid = loApi.CreateGuid()
lcUnique = "_" + TRIM(RIGHT(lcGuid,13),0,"}")
RETURN lcUnique
ENDFUNC
You can still tag on the ProcessId to make it unique per process and you'll need to widen the field to 20 characters maybe.
However there's no guarantee that this ID will be truly unique. Only a full GUID is 100% unique - chunking off small chunks makes it less unique. However, for tempoary state like Session IDs that expire over time this is likely good enough.
+++ Rick ---
Good idea. What's the best way to generate a truly unique session ID without having to scan the session table every time one is created to ensure it hasn't already been used?
Allen
Hi Allen,
You should be able to subclass wwSession and override the GenerateSessionId() function with something that satisfies TrustWave.
Carl
When our website is scanned by TrustWave for PCI Compliance, we're having the following reported:
Predictable Cookie Session IDs
Severity: Medium
PCI Status: Fail
Description: The remote web application is using predictable cookie-based session IDs. Ideally, session IDs are randomly generated numbers that cannot be guessed by attackers. If the session ID is predictable, an attacker could hijack an active victim's session, allowing the attacker to interact with the server as though they were the victim. If the session ID is used to track the state of authentication, the session ID of an authenticated user could be guessed, bypassing any need for a username or password.
Remediation: This software needs to be either configured or modified to generate random session IDs.
Apparently, the cookies being generated aren't random enough or something.
How do I fix this?