I have an issue on a jhipster:1.10.2 project.
When the client session expired, I have cookie theft attack on refreshing some of my page. I found here the reason. When I refresh my page, the first request refresh the remember-me token, invalidate the old one, and send the result to store in the session. But meantime, another request is gone with the old cookie remember-me token.
How can I solve this issue ?
Thx
Related
I'm working on a SPA where adal-angular lib is used to handle auth on client side. On backend app, passport-azure-ad is used with Bearer Strategy, to issue access token and other stuff(no refresh token though).
When user authenticates, accessToken, together with idToken is saved in localStorage, and with token timeout (which is around 1h).
When token expires, I get error (AADSTS50058) back saying single sign-in failed as it is missing cookie, to confirm identity. I'm not sure who needs to issue this cookie, and why it is not issued.
So I have one choice to manually, after reaching that error, call signIn method, programatically. It works to login, but full page reload happens and user loses work.
So my questions are:
Can this be fixed with missing cookie, who needs to issue the cookie, and will it also do full page reload or not?
If I cannot solve this with missing cookie, is there another way to re-login without doing full page reload?
Thanks.
This error may occur if the third-party cookies have been disabled in your browser.
If you are accessing angular application through Chrome browser on incognito mode. it disables third-party cookies at the home page.
If you are using incognito mode. Re-enable third party cookies in your browser to prevent this error from occurring.
For AADSTS50058 error you need to whitelist the
login.microsoftonline.com endpoint in your browser extension in order
to evade receiving this error again
For using access token, I would suggest to use refresh token, access token has a short life span as it becomes invalid or expires you need to re-login.
So make use of refresh token as it has long life span
However, there are two alternatives,
Set the shorter expiry date 60 minutes to Access Token.
Set the long expiry date 100 days to Refresh Token.
“Access token good for an hour, refresh token good for a year or good-till-revoked” So, you better use both Access Token and Refresh Token to fix this issue
To know more in detail please find these links if they are helpful:
Ref1 , Ref2 , Ref3
I have implemented all of the code to support token rotation/ refresh with one last hitch. How are we supposed to persist the token on the frontend to make authenticated backend calls beyond our login?
My Current workflow goes as follows:
User logs in with email and password and is returned the refresh token and the access token in an HTTP-only secure cookie.
A MongoDB (body) document along with the refresh Token and Access Token in HTTP-only, secure cookies is returned with the response.
Now moving on from here how can we persist using these cookies? Especially since we cannot access these. I am using HTTP-only cookies as that is what is recommended as it is most secure but I am struggling to see how it is possible with only HTTP cookies.
In case anyone stumbles across this. HTTP cookies persist by default. They were not persisting in my case as I had the secure property set to true and I was not over an https connection.
I have read a few articles regarding JWT refresh tokens, and how/why they are used. One thing i have seen mentioned here: https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/#persistance and here: https://dev.to/cotter/localstorage-vs-cookies-all-you-need-to-know-about-storing-jwt-tokens-securely-in-the-front-end-15id
is that using refresh tokens mitigates against CSRF attacks. The first article states:
The refresh token is sent by the auth server to the client as an HttpOnly cookie and is automatically sent by the browser in a /refresh_token API call.
Because client side Javascript can't read or steal an HttpOnly cookie, this is a little better at mitigating XSS than persisting it as a normal cookie or in localstorage.
This approach is also safe from CSRF attacks, because even though a form submit attack can make a /refresh_token API call, the attacker cannot get the new JWT token value that is returned.
The second article says something similar:
Although a form submit to /refresh_token will work and a new access token will be returned, the attacker can't read the response if they're using an HTML form
I am struggling to see how this would prevent CSRF attacks as I am thinking the following:
A request to /refresh token from another domain to the users will return new JWT token to the user. I am going to assume this is stored in a HttpOnly cookie (as is done in the first article)
As CSRF does not involve any injection of javascript and the cookie it httpOnly, the attacker can't read the value of the new JWT token.
However, if the JWT token is stored in a cookie again, surely a CSRF attacker can just send another request using this new cookie, with the new JWT token sinde?
If my understanding is correct, I am struggling to see how CSRF attacks are prevented by using refresh tokens. Can someone please explain exactly why refresh tokens prevent CSRF attacks, and why the CSRF attacker can't just use the new JWT the user would receive for future attacks?
It seems to me that the thing that would actually be preventing a CSRF attack would be the use of a sameSite cookie, or maybe using some sort of anti-forgery token.
The new jwt would not be returned from the identity provider as a cookie. That would not make much sense as the client on a different origin would not be able to read it. Instead, the token is passed in the response body, or even the url (usually not the token in that case, but let's not delve into that).
So the idp has its httpOnly cookie to authenticate the user, issues a new token in some way that is not a cookie, and the client stores the token for the appropriate origin (not the idp) in say localstorage. This way, any call to the resource server is not vulnerable to csrf, because the token needs to be explicitly be added from localstorage. The idp can be called by attacker.com to issue a new token ("csrf"), but attacker.com will not have access to the token due to the same origin policy, so it's not exploitable.
Note that even if the new token is returned as a cookie for the idp and read from there by the client, it's still ok, because the idp will do nothing with that token, and the resource server (~api) will not receive it automatically.
From a custom authenticator; is there a way of telling ember-simple-auth that a user is now invalidated/logged-out?
Some background: I am building an authenticator with token refresh, similar to oauth2-password-grant. While I haven't experimented with the oauth2 authenticator directly, it seems we face the same issue: if the token refresh fails to update, for example due to an expired token, the user remains logged in as far as ember-simple-auth is concerned.
EDIT: (to address comments for further clarification)
Ah, I use JWTs and the server does not maintain sessions; the server has no idea who is logged in nor does it matter. The authentication is done via username/password after which the server issues a JWT token along with a time when it expires. To prolong the expiry time, you may refresh this token (as long as its valid) and get a new token with an updated expiry time. All is well and good except that ember-simple-auth does keep track of whether the user is logged in, as it should. However, if a call to refresh the token fails the user should be considered logged out (the token is invalid/expired and any attempts to make a call to an API that requires authentication will fail).
My question is how do I tell ember-simple-auth that this user has been logged out.
I am trying to implement a user friendly anti CSRF mechanism.
Currently my application program sets a cookie and session variable with the anti-csrf token and sends it to user.
Whenever the user makes an unsafe request(POST,DELETE,PUT) javascript reads the cookie and adds the token to the form which is sent via an ajax request
On server the form value is compared with session contained value.
Problem is my application will be open in multiple tabs and it it highly probable the the token will expire on server.
Is it a good practice to get new csrf tokens from a server file like
get-csrf-token.php
Because anyways the attacker cannot read the response from cross site requests(considering jsonp and cors is disabled)
EDIT:
I plan to keep single CSRF token valid per hour per session and the web applications will re-request new tokens after an hour
Is there anything wrong with this approach?
You only need one CSRF token per user session. As any attacker cannot read the token due to the Same Origin Policy, you do not need to refresh the token until the next session is active. This will mean there will be no problems with your application being open in multiple tabs.
Your approach is an implementation of the Synchronizer Token Pattern CSRF protection mechanism, which is the OWASP recommended approach. As JavaScript is used to add the value to the request, you can't mark your cookie as httpOnly. This would have prevented any XSS vulnerabilities from allowing an attacker to grab your cookie value. However, if you do have any XSS vulnerabilities, these are slightly more serious than CSRF ones and should be addressed immediately anyway as there are other attack vectors once an XSS flaw is found.
See this post for some pros and cons of some CSRF mechanisms: Why is it common to put CSRF prevention tokens in cookies?
In my project, I use cookies for managing authentication of users, and use session for generating the CSRF token.
When generating the form, it should be included in hidden field. For ex:
<form method="post" action="/paymoney">
<input type="hidden" name="csrf" value="csrf value" />
...
</form>
When user makes an request, the server should authenticate the request first (via cookie). After that, the server get the correct user session and verify the CSRF token.
Note that, you should care about the time out of CSRF token. The more expired time of this token, the less efficiency you can get. But if the expired time is too short, it cause a trouble that some ajax call can not work although the authentication of user is still valid.