I noticed at authentication of several JAVA web applications, the Session ID attached at the url like this http://mywebsite.com/function?value=blah&jsessionid=fgd457dfsd7sde4g4df…
When first authenticated, the website reveals in the URL a sensitive information “the session ID”. This is a security risk according to OWASP reference.
Indeed if an attacker get the session ID it can lead to the vulnerability of session fixation.
Scanner like Acunetix will detect is as a security risk too:
Why the session id is passed to the URL ?
According to this post, it is by design of JavaEE:
This isn’t a bug, it’s by design. When a new session is created, the server isn’t sure if the client supports cookies or not, and so it generates a cookie as well as the jsessionid on the URL. When the client comes back the second time, and presents the cookie, the server knows the jsessionid isn’t necessary, and drops it for the rest of the session. If the client comes back with no cookie, then the server needs to continue to use jsessionid rewriting.
What is a Session Fixation ?
Session Fixation is an attack that permits an attacker to hijack a valid user session.
This vulnerability is part of Top 10 2013-A2-Broken Authentication and Session Management
How to test for Session Fixation ?
What is a Session ?
HTTP protocol and Web Servers are stateless, what it means is that for web server every request is a new request to process and they can’t identify if it’s coming from client that has been sending request previously.
But sometimes in web applications, we should know who the client is and process the request accordingly. For example, a shopping cart application should know who is sending the request to add an item and in which cart the item has to be added or who is sending checkout request so that it can charge the amount to correct client.
This is a link to Servlet specification to understand better the session scope in Java :
SRV.7.3 Session Scope
HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.
Validate Session Id on server side
For sometimes i thought that cookies or hidden input fields is the solution against the “session ID” in the url. According to the link below it is a limited solution. Even if it is hard to copy paste cookies and hidden fields it is still possible to retrieve the Session ID information with special tools on unencrypted website.
Depending of the website it is possible that the sessionId on the URL is not a security risk. If the web application is well designed and the session ID is validated on server side, this is not a problem :
The best practice , in all case is to validate on the server side.
Other solutions are possible : https://en.wikipedia.org/wiki/Session_fixation
Use Filter to get rid of Session ID in URL
Here is an example of using a Filter to get rid of session Id in the URL :
I believe this solution is not necessary if good validation of session ID is done on the server Side.
Spring Security Framework
Probably the best solution for JavaEE is to use well tested framework like spring security framework. It is also a default security against other common vulnerabilities.
The authentication form using spring security provide high security against common vulnerabilities :
The SecurityConfig will:
Require authentication to every URL in your application
Generate a login form for you
Allow the user with the Username user and the Password password to authenticate with form based authentication
Allow the user to logout
CSRF attack prevention
Session Fixation protection
Security Header integration
HTTP Strict Transport Security for secure requests
Cache Control (can be overridden later by your application to allow caching of your static resources)
X-Frame-Options integration to help prevent Clickjacking
Integrate with the following Servlet API methods