My application is running in jboss 7 and the sessions are being maintained by using the jsessionid cookie, which is marked secure and httponly. But even with this, if I am able to get any user's jsessionid cookie value, I will be able to spoof as the user. Is there any way to prevent this?
When you have a session for a user on your server, you need to match a request from a user to its session, it's the goal of the JSESSIONID cookie.
This is why you need to secure it by adding "secure" (this cookie will only be sent over https to prevent network sniffing) and "HttpOnly" (to disable access to this cookie by client javascript code) options.
You can add other mitigation methods by checking change in user's IP address (but will break 3G/WIFI change for legit users), user agent string, ...
But in practice, if you have access to the JSESSIONID cookie you can have access to these data too.
You can take a look at OWASP Session Management Cheat Sheet for more :
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
Related
Currently, we are using a legacy application where the Java HttpServletRequest.GetSession() function to get the session from the Client browser where the session is set from the Browser's parent tab.
Now we need to access the same session information [example, we have Token in the session]
using our new application with decoupled Microservice architecture [ UI-React JS].
Whether we can able to access the session from Front End?
Appreciate your suggestion on this.
Thank you !
The HTTP Session is a temporary store in the backend, where you store something based on previous requests. As soon as you store something there, the backend will return a Set-Cookie header to the browser with a JSESSIONID that the browser stores for the user. For the next calls, the browser will send the same JSESSIONID cookie, and the backend will use it as a key to retrieve the previously saved data for that user's browser.
If you're migrating to a React JS application, I think there's no need to store tokens in the backend, and use cookies with only JSESSIONID in. Instead, the frontend can store all the necessary data client-side.
I think there's multiple options:
Keep it in React state (in the browser's memory)
Keep it in a Cookie that you manage via the frontend
Keep it in the browser's localStorage (less secure, I think)
I have java web application using struts 1.x. Recently my application has gone through penetration testing and our testers found some security holes. Let me explain. In my application i have 2 users called ‘Admin’ and ‘user’. First our PenTester logged to my application as ‘Admin’ and they use ‘Burp tool’ to intercept the request and copy the whole request content into notepad and then forward the request. Now My application log in as ‘Admin’. They use another browser instance to login as “user” and use burp tool to intercept the request. This time they removed the whole request content and copy back the whole request content of ‘Admin’ and then forward the request. Now my application logged in as ‘Admin’ without asking any user id/password? How to restrict this situation? I already stored userid in my session variable after successful login of each user. The moment they intercept the request and copy the ‘admin’ request content, my session variable userid also changed to ‘admin’. How to validate this situation? Your help is really appreciated.
That is not really that much of an issue since the first part "copy the whole request content" is not easily doable if you have a proper HTTPS / SSL connection. That only works if the PC the user is logged in on as an admin is compromised in which case: nothing you can do about it anyway because they can just sniff the keystrokes and get the plain password.
If on the other hand you communicate without the S, namely just HTTP then the solution is: get a certificate and switch to HTTPS.
Apart from that your application can pin a session to an IP which means if the session id / cookie is stolen and someone else uses it you can detect an IP mismatch and ask for credentials again.
To prevent direct replay attacks like copying the request and sending it again you can introduce a hash that incorporates the timestamp or alternative measures, see. How do I prevent replay attacks? . The problem however is that copying the entire request means copying the cookies as well and if the "admin" cookie is copied this measure will not prevent you from "generating" a new hash based on the now admin user.
Apologies if I sound bad.
I have a xyz.war that does some authentication and sets a cookie(with HttpOnly set so I can not expire it via javascript) so that when the user logs-in for the next time the session is maintained. Now, given that I have the access to the Tomcat that is hosting the xyz.war how can I write a Java program that could expire/delete the cookie? I can create a .war of the java project and host it in the same Tomcat and access it from client side via a api.
You would have invalidate the session in xyz application. Removing (thus beeing able to midify) cookie by third parties would be a security hole.
I'm developing an environment with 2 webapps deployed in Tomcat 7. One authenticate users using form, openid, remember me cookie or x509 cert. This one works as expected and use the Remember me cookie to authenticate properly when generated.
The problem resides in the second one (the client):
When the login request comes back to the client from the first one, I don't see any cookie. I'm pretty sure they are in the same domain (localhost) and the cookie path is "/" but the browser (firefox) is not sending the cookie to the client.
If I want to use the generated remember me cookie to authenticate in the client, do I need to include all remember me cookie stuff from Spring's security?
Is the remember me cookie a good approach? Do I need something like siteminder or other better approaches?
Thanks in advance. Answers will be voted
Check the cookie information when it is sent back from the server (use Firebug to monitor the network traffic if you're using Firefox).
Check the domain and path, and also whether the cookie is flagged as secure. If the remember-me cookie is issued over a secure connection it will be marked as secure and the browser won't send it over HTTP.
If this is the case, you have to explicitly override it (though you're better to use HTTPS throughout). There's a use-secure-cookie attribute in the remember-me namespace element which you can set.
I am trying to login and retrieve status information from a HTTPS URL via Java programming. I login through /login.cgi, providing the username and password with a POST request to that script.
The script then verifies the credentials and creates a specific cookie (with session information, user name, etc.) and then immediately calls a Location response header to /home.cgi. Which, I'm guessing, the /home.cgi script verifies the cookie information before continuing to load. Otherwise, it just reverts back to the /login.cgi page.
All of this works fine within a browser because of the way browser's handle cookies/sessions correctly. However, within Java, this is very tricky because I can not get the appropriate cookie to send as a request to subsequent pages. I can not get the correct cookie because I am unable to get the HTTP response back (which holds the correct "Set-cookie" value) in between /login.cgi creating the specific cookie and it calling Location /home.cgi.
Is there something I'm missing or is there a better way that Java can handle cookies similar to a browser? (is there a cookie store, etc?)
Thanks for the help,
Steve
Cookie management is by default not enabled in the java.net HTTP API. If you don't need any specific handling or cross-application cookie persistence (the cookies will be deleted when your application terminates), you can simple enable it with
CookieHandler.setDefault(new CookieManager());
How are you making the HTTP connections and managing cookies?
I would recommend just using commons-httpclient rather than managing this yourself. It will automatically manage cookies for you.