I need to implement a simple remember me option in a java servlet with cookies, without using any advanced framework.
First, at login, I create the cookie and send it in response to the browser (client). The value to be stored in the cookie is just a simple hash from username + password.
How should I manage the incoming request from the browser, sending the cookie?
My approach is to check between registered users if there is any user that has the hash from username + password equal to the value in the cookie?
Is this approach correct?
Also, I did not understand exactly what is the mechanism of the expiration date. Does the browser delete the cookie when it is expired, it not, how do I check if the cookie is expired?
As long as you're not using HTTPS the method you suggest is highly insecure. I would suggest to generate some sort of session token (e.g. use java.util.UUID.randomUUID()) and set this as cookie and store it somewhere on the server side so you later can identify the user associated with this session id in the cookie.
This gives you the opportunity to reset a certain session cookie if you think there's some fraud happening and there's no direct relation between the user name/password and the cookie id you use. But note: this method is still vulnerable to a man-in-the-middle attack.
Concerning the expiration: yes the cookie becomes invalid and might get deleted by the browser if it is expired. But you can set the cookie to something in the year 3000, so it lives forever.
Related
As we know Rest services are stateless, General strategies to authenticate is using a token based authentication.
In login service it takes credentials which returns a token.
This token might be set in client cookies, and all subsequent requests uses this token to be validated and process new request if token is valid.
Now my question is how one can validate the token ? If someone has stolen the token and tries to access rest services with stolen token by just editing cookies then how can it be identified and restricted ?
We can never know if the token is fetched by valid user and same user is trying to access subsequent request. but what are the possible ways to make it more hard, like to verify if the request has came from same source ?
One general suggestion is to set aging for token/cookies, but it still not helpful till the age of that token/cookies.
Any suggestions would be appreciated.
I don’t believe there are any 100% fool proof methods of preventing access with stolen user tokens. How do you even know that the token is stolen in the first place? But from the top of my head you might want to consider following:
Accessing a REST service with the same token but a different user agent is suspicious. This can be recognized with the value of the User-Agent header. You might want to consider dropping such requests.
What if the IP address changes but the token is still the same? Well, maybe someone is using a load balancer and accesses the network over different IP addresses? Or he accessed a VPN with the same token/cookie as before? If you have no compunction dropping such requests, you might level up the security by checking the source IP address too.
In case of – say – JWT tokens, you will need a bit of infrastructure to handle the blacklisting. Follow this.
My current understand of the "most secure" approach to authorizing requests in the browser is to require validation of an HttpOnly SameSite cookie AND HTTP header (e.g. Authorization or X-CSRF-Token) in combination.
For example, when issuing the JWT to a browser, send the JWT signature in an HttpOnly SameSite cookie, and send the body (without signature) to the client to store in localStorage and submit in the Authorization header. When authorizing a request, combine the two back into the complete JWT and validate it as normal after that.
Alternatively, you can generate two JWTs with a field to distinguish them (e.g. the client one has "browser" in it, the cookie has "cookie") and require that both are valid and both identify the same user. One is sent in the Authorization header and stored in localStorage and the other uses the SameSite HttpOnly cookie.
Another popular approach is to store a CSRF token in a field in the JWT, and put the JWT into a cookie and require the client to send a matching token in a header (e.g. X-CSRF-Token).
All of the solutions effectively prevent XSS and CSRF attacks: XSS cannot retrieve the HttpOnly cookie, and CSRF does not include the HTTP header, so this blocks both attacks.
Note that you probably only want to apply this rule for requests from web browsers. For server-to-server communication, requests are not subject to CSRF and XSS attacks.
After struggling through various approach We found a solution explained below:
We store token (encrypted) in cookies on login request and for each subsequent request this cookie gets validated.
The problem was if someone replace the token in cookie with another valid token, as cookies are maintained by client browser.
Solution :-> Though token values were encrypted, it was representing only one value, So if one replace whole encrypted value with another valid encrypted value it can be hacked.
So to solve this we have added another cookie which was combination of multiple values.
e.g.
Cookie 1 -> encrypted token
Cookie 2 -> An encrypted object containing information like username+ some other user context details+token
So in case of Cookie 1, it was easy to replace with another encrypted value as it was representing only one token though it was encrypted.
But in case of Cookie 2, it was containing object with multiple values, so only token value can not be modified, encrypted and set back in same cookie.
Before authentication We are doing decryption whole cookie 2, fetch token part from it and validate the token part of it against cookie 1.
That has solved our problem !!
Thanks all for your time and guidance.
You can use jwt is an Internet standard for creating JSON-based access tokens that assert some number of claims. For example, a server could generate a token that has the claim "logged in as admin" and provide that to a client. The client could then use that token to prove that it is logged in as admin .
How it's working ?
First it's contain private key generated by developer :
let us have this key :sfcqw#sav%$#fvcxv*s_s515 and this one called private key , and we also have a public key this the public key generated depended on user data and private key and it's impossible to know what is contain if you don't know the private key .
to more explain :
public key :
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.plpJkAcgrgCIsoRyV2kjGsvWF6OsXU1mD785OSWTH4o
we have the above key generated by our private key : sfcqw#sav%$#fvcxv*s_s515
To be more clear going to this website : https://jwt.io/ and try to past the public key without put secrite key like picture and you will understand everything .
To me, there was no way to prevent the access from being stolen JWT token except
setting a short timeout for the token
more secured at the HTTP request level by only allowing specific `User-Agent. See more
more secured at the HTTP request level by customizing the header key for the organization, e.g My-X-Auth = Bearer <token> instead of Authorization= Bearer <token>
more secured at the HTTP request level by restricting trusted urls/domains, e.g X-Content-Security-Policy. See more
Can we put authentication token in session object?
For example:
session.setAttribute("authToken",authTokne);
In my case I have to use authToken in every request call.
In service layer i am using third party services. In each request i need to pass authentication token. Getting authentication token is also a one request. I need to do many request calls step by step. At first request i am getting token and holding it in object level. After some time i need to make another request from different location(another class/object), now token is not available here. For this one more request i need to send for token. So avoiding this every time new call for a token, Can i put this token in servlet session varaible?
In term of security reasons is it good approach?
The all session data is kept on the server, so you can put anything you want there. The browser user is associated to the session via sessionId in a cookie (looked up by container upon request). When a user connects to server, a cookie is dropped on the browser with sessionId. Upon return the browser sends this sessionId back so you can lookup the session (usually a Map) to track data associated with the user and their current session. Session cookies can be set to persist through browser closing or expire when browser closes or after a certain time.
Storing the auth token in session is fine, but you will not be able to find a session based on auth token stored in it if the browser doesn't support or doesn't store cookies. If a user has no cookies (maybe a custom app that calls URLs), you would add an auth-token to the URL so that the user only logs in once per session. In this case you would create a data store which contains session data and associate both sessionId from browser and auth token to the same data. This is how I have done mobile/web/api session data management in the past.
What problem are you trying to solve?
I have a situation where I need to create a cookie when a session is created, and when the session is removed I have to remove the cookie. When a user manually ends a session I can remove the cookie in the doGet method of the logout servlet. But when the session times out I am not able to do that, so I am planning to sue the HttpSessionListener for this, but I have seen some where that we cannot do that. Is there any other way than the one mentioned here.
Really how do want to remove a cookie when you do not access to the user?!?!
The only solution is setting cookie live-time to the exact time your cookie session is(1 hour is default)
For each request you need to set the cookie with the updated time(current_timestamp+'1 hour'), it will tell browser keep the cookie for next 1 hour.
Beside the cookie, you need to check the integrity of the cookie and the session, simply track the cookie integrity with the session(maybe a hash), it helps you when a user tries to fool your server, by providing cookie A from user A by session user B.
When a user has an associated HttpSession object and then want to "log out" of the application you would invalidate that HttpSession which in turn would remove it from the map that the ServletContext keep of all sessions. But this only removes it on the server side, what happens on the client side? Does the user still keep keep the cookie with the session ID which now no longer has a corresponding session object on the server and keeps sending this to the webserver? And what happens when the user wants to login again after logging out?
I imagine the sessionId cookie will still be kept, but since this sessionId will not match any session object in the server's memory, it will be discarded by the server next time user tries to login again. On the server side it will be quite transparent, request.getSession() will return a new session object automatically.
I would like to add to the answer of maksimov.
Although the cookie is still present on the client side, it is possible for the server to delete the cookie also on the client side. Spring Security does that when a user logs out. Here's the code:
Cookie cookie = new Cookie(cookieName, null);
String cookiePath = //cookie's path
cookie.setPath(cookiePath);
cookie.setMaxAge(0);
response.addCookie(cookie);
The important instruction is cookie.setMaxAge(0). Setting the max age to 0 means the cookie has to be deleted. Thus, the server may ask the client to delete the cookie by sending it the same cookie with a max age of 0.
I'm curious how does Remember Me work and how does it work in Spring Security?
I understand that server sends long-lived cookies to the client. And then client sends cookie back and server can recognize the client because there's something like hash-map on the server with relations cookie --> session.
I don't understand how does the server [server-side application] recognize a client by cookie after server [Tomcat] has been restarted.
How and where does Spring Security save cookie-session map before server shutdown? Is it server-specific (i.e. something different is happened in Tomcat, Jetty etc)?
P.S. one more related problem with Spring Security and redeployment: even if I don't tick RememberMe and log in, I'm still recognized after redeployment for about 3 mins. Is it fixable?
The Spring Security docs discuss how this actually works.
This approach uses hashing to achieve a useful remember-me strategy. In essence a cookie is sent to the browser upon successful interactive authentication, with the cookie being composed as follows:
base64(username + ":" + expirationTime + ":" + md5Hex(username + ":" + expirationTime + ":" password + ":" + key))
...
As such the remember-me token is valid only for the period specified, and provided that the username, password and key does not change. Notably, this has a potential security issue in that a captured remember-me token will be usable from any user agent until such time as the token expires. This is the same issue as with digest authentication.
Basically the cookie contains the username, password, expiration time and a key (which you specify), all of which are hashed together. When your browser sends the contents of this cookie to the server, Spring Security:
Retrieves the password from the backend for the given username
Computes the md5Hex() of the username/password/etc from the database and compares it to the value in the cookie
If they match - you are logged in! If not a match, then you've supplied a forged cookie or one of the username/password/key has changed.
The underlying assumption here is that the hash function - the md5Hex() part above - provides a way to easily encode some piece of data in one direction yet is incredibly hard and unpractical to reverse (to recover the password from the md5Hex text).
Dont' confuse session cookies with Remember Me cookies.
Session cookie is sent by the server (e.g. Tomcat) and used to associate incoming request with the session.
Remember Me cookie is sent by Spring Security to authenticate the client in the different sessions (e.g. after expiration of the original session or after the server restart).
To authenticate a user by Remember Me cookie Spring Security provides 2 strategies:
TokenBasedRememberMeServices - used by default, less secure - cookie contains a hash of the password and other data
PersistentTokenBasedRememberMeServices - more secure, requires database access - cookie containt an unique identifier stored in the database