Session Hijacking issue with https connection

Issue

By replacing the sessionId of a logged-in user, the user's session from another browser is replicated.
Steps to reproduce
- Create 2 users like u1, u2
- Assign the role for the u1 as "Power user", u2 as "Portal Content Reviewer"
- Create 2 pages like Page1, Page2
- Click on the permission of the Page1 and enable the view option for the Power-user role and disable the view permission of the guest user role
- Click on the permission of the Page2 and enable the view option for the Portal Content Reviewer role and disable the view permission of the guest user role
  - Observed behavior: User1 can view the home page and Page1. User2 can view the home page and Page2.
- Using the burp suite tool, intercepting the request as below
  - In the Chrome browser:
    - Logged in as u1 user.
    - Switch on the Intercept in the burp suite and refresh the Chrome browser. SessionId of the u1 will be captured in this tool.
  - In another browser like IE or Firefox browser:
    - Switch on the intercept hit the URL without sign in like "https://IP:8443/"
    - Replace the copied session id of the u1 in the request and click on forward.
- Observed behavior: It's logged in using the u1 login details. Page1 is visible now.

The reported scenario demonstrates well that the portal uses a single session id (JSESSIONID) for identifying the user behind the request. Of course, this means that a stolen session id can be used to gain unauthorized access. Whereas there is no exposure issue or security vulnerability here.
In the described case, set up an environment which is basically suitable for debugging https requests. As a result, you see the requests unencrypted and access everything in it, including the JSESSIONID cookie. Without importing BurpSuite's own certificate into the browser and setting it as trusted to identify websites, interception of the https communication is not possible.
The production environments are protected via request interceptions (man-in-the-middle attacks) by using TLS encryption [HTTPS] or more specifically HSTS [HTTP Strict Transport Security], where communicating via HTTP is not possible at all.