We recently did some penetration testing and got the below medium issue. Could anyone please suggest possible fix for this. they have given a possible solutiont Risk: It may be possible to steal or manipulate customer session and cookies, which might be used to imp ersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transact ions as that user Causes: Insecure web application programming or configuration Fix: Change session identifier values after login Prevent user ability to manipulate session ID. Do not accept session IDs provided by the user's browser at login; always generate a new session to which the user will log in if successfully authenticated. Invalidate any existing session identifiers prior to authorizing a new user session. For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again. Reasoning: The test result seems to indicate a vulnerability because the session identifiers in the Original Request and in the Response are identical. They should have been updated in the response. Many Thanks, Savan
I did a little testing on this. In short, the user cannot manipulate a session ID. The finding is correct in the sense that if you log into an authenticated session from an anonymous session in Mendix, you maintain the same session ID. However, if you manipulate that session ID locally, you lose the original anonymous session ID and get a brand new session ID.
Here's how I tested this:
Open a Mendix app to an anonymous session
Check the session ID cookie - mine was 052f0315-c8c6-4a67-931a-b0632fc8d3f7
Use the Chrome extension EditThisCookie to change the session ID - I changed it to 95eb8c00-d4ce-44b2-b196-10e9da2fcc00
Check request and response:
The request session ID was: 95eb8c00-d4ce-44b2-b196-10e9da2fcc00, but the response was a brand new session ID: 052f0315-c8c6-4a67-931a-b0632fc8d3f7