Security issue: Session Identifier Not updated

1
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 
asked
3 answers
1

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:

 

  1. Open a Mendix app to an anonymous session
  2. Check the session ID cookie - mine was 052f0315-c8c6-4a67-931a-b0632fc8d3f7
  3. Use the Chrome extension EditThisCookie to change the session ID - I changed it to 95eb8c00-d4ce-44b2-b196-10e9da2fcc00
  4. Log in
  5. Check request and response:
  6. The request session ID was: 95eb8c00-d4ce-44b2-b196-10e9da2fcc00, but the response was a brand new session ID: 052f0315-c8c6-4a67-931a-b0632fc8d3f7
answered
0

@Eric: although I agree with you in the sense that I cannot think of an attack at the moment, the finding from Savan is right in that OWASP recommendations agree with him, see: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Renew_the_Session_ID_After_Any_Privilege_Level_Change

answered
0

Thanks Eric and Nikel, I have a further confirmation with support team that they will fix it in future releases of v7 or on a v6 patch release. 

answered