Messages
Reply
Edit
Delete
Scan fail Issue:
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. This software needs to be either configured or modified to generate random session IDs.
Number of Cookies evaluated: 100
Low rate of change: The cookie was found to have an average rate of change of 2.22 bytes per request
First Cookie Value: 3OR10A3OS06256
2nd Cookie Value: 3OR10A42806256
2nd to last cookie value: 3OR10AS5F06256
Last Cookie Value: 3OR10ASB206256
The expression used to generate WC sessions is:
SUBSTR( SYS(2015),2,9) + PADL(TRANSFORM(_VFP.ThreadID),5,"0")
Since SYS(2015) is based on the system clock the leftmost digits only change over long intervals, and the ThreadID doesn't change between hits, resulting in the "low rate of change". I think their argument about this being a security risk is bogus - an attacker would have to guess the exact millisecond the session started to have a hope of guessing the sessionID, but they are telling the customer she can't accept online payments unless this is "fixed".
I am looking at subclassing wwsession and replacing the above expression with a string based on RAND() output which hopefully will make them happy. Are there any pitfalls I should watch out for if I do this? I'd give uphaving the ThreadID embedded in the SessionID, something I assume could be useful in debugging, but I've never had ocassion to make use of it.
--stein
