Since access token is vulnerable to XSS
and Cookies are vulnerable to CSRF.
is it possible to have a solution of both (Access token and session cookie).
My point is, to generate a random string called X, and store it in access token and session cookie, so when a request to a resource is done, the server side will make sure that the string in cookie and token is the same.
in this case we are eliminating the individual XSS and CSRF attacks.
does this solution more secure than token-based and cookie-based authentication?
and is there any critical vulnerabilities in it?
if there would be any enhancements, please suggest.
A similar technique called CSRF token already exists, I would look into that
What is a CSRF token ? What is its importance and how does it work?
Also, the best you can do to protect against XSS is to add good XSS protection and the best thing you can do to protect against CSRF is to put good cookie policies in place.
Related
I'm implementing security for my React SPA using Spring Security on the backend. After a lot of reading, I opted for the following approach :
HTTPS everywhere
POST /login takes credentials returns JWT_TOKEN & XSRF_TOKEN in cookie form. I build the JWT_TOKEN myself whereas Spring Security handles the XSRF_TOKEN. Both cookies are Secured and SameSite=Strict. The JWT token is HttpOnly.
Subsequent API calls require the X-XSRF-TOKEN header. This is read from the aforementionned cookie. Both are sent and Spring Security compares them. JWT is automatically sent and checked in a Filter.
Every time a XSRF token is used, Spring Security generates a new one to prevent session-fixation attacks
XSS protections are applied by Spring Security
So now I'm wondering about refresh tokens. I'm reading a lot of contradictory info out there. Do I need them with this setup? If so how best to handle this ?
Many Thanks
In general, as its name says, the refresh token changes from one token to another. Typically they are used in OAuth protocol-based authentication. They are useful when an access token has expired, but the user's session is still valid.
First, JWTs are a great choice for access tokens. They have claims that match the access tokens requirements, such as: exp, iat, jti, sub, etc. But, when using a cookie-based authentication there is no need for access tokens and possibly no need for JWT.
As you said, your JWT_TOKEN is being set as an HttpOnly cookie, which means that only the server has access to it. JWT is useful for sharing the initial state between the client and server, and vice-versa. If your server is just taking it to look up the database, you don't need a JWT, you are just using a session concept, and keeping session data on a JWT may not be a good practice.
Second, if your authenticated cookie data will live at /login and die at /logout, there is no need for refresh tokens. Refresh tokens are an exchange key for short-life access tokens. Instead, your cookies keep the session live and don't need to be exchanged by something else.
For example, if the user uses the /login route to exchange your username and password for one short life access_token. He may need the refresh_token to get a new access_token without needing to send his username and password again.
If you are using the OAuth protocol or similar, refresh tokens are essential to provide a more seamless experience for your users and avoid the inconvenience of repeatedly having to re-enter their credentials. But even on OAuth, they are not mandatory.
I am new to web security and implementation of same using spring-security. One important concept is prevention from CSRF using CSRF token. Spring security has provided two ways to manage CSRF token
CookieCsrfTokenRepository
HttpSessionCsrfTokenRepository
However I am not able to understand which one should be used as I can see cons in both the approach.
CookieCsrfTokenRepository is asking to set HTTP only property to false in cookie so that javascript can read it and add the same to in further request. However as per my understanding, setting http only as false is not recommended as malicious script can also read the cookie and share the same token in the forged request.
HttpSessionCsrfTokenRepository is storing the csrf token in session. In this case, we need to introduce session stickiness or session replication in case of distributed environment however recommendation is to go for stateless application.
So please some let me know if my above understanding is correct or not. If correct, which option do we need to select for csrf token implementation.
However as per my understanding, setting http only as false is not recommended as malicious script can also read the cookie and share the same token in the forged request.
I believe this would be true if a) you have an XSS vulnerability on your site or b) you did not set the Domain of the cookie. The rest of your question seems opinion-based to me.
however recommendation is to go for stateless application.
Note: The following is simply my opinion on the matter, as it's difficult to argue for/against statelessness in general.
This is an example where security requires state, so to protect the csrf token and avoid your concern with cookies, you need state on the server and should choose session.
I am using codeigniter 3.1.9.
I have enabled my CSRF protection with csrg_regenerate set to true. It works fine, the token regenerates every time on Post request, validation works as well. On top of that, I have also set my cookie to same-site strict connection only.
I then submitted for penetration test assessment to the security team, they rejected my work because of csrf attacks vulnerability.
The argument was, they changed the cookie token and post params, then perform the attacks.
Here is the proof:
Their response : CSRF token is not securely implemented. An attacker can still perform a CSRF attack using any value to the csrf_cookie_name Cookie and csrf_test_name parameter.
How can I solve this ?
Thanks
Its the first time to see a security token stored in cookies on the client side that's why of course your system is vulnerable.
You must store the token in your session that makes them impossible to retrieve.
The way to implement it:
Create a hidden input in your form with the csrf token and on form submit compare it with your token that is stored in the session.
OWASP's Encrypted Token Pattern is a CSRF protection solution, where the token value is a function of time. Would this mean that Encrypted Token Pattern has a built in BREACH attack protection?
Generally no, because in most implementations the token is only generated once per authentication (i.e. when somebody logs in). It is still generally recommended to only generate the CSRF token once per session.
Once the CSRF token has been retrieved by a BREACH attack, then it could be used on subsequent requests in the session. It doesn't matter if the value is encrypted as it is only the ciphertext itself that is required.
However, as a mitigation for BREACH, you could regenerate the token on every request.
There are some other mitigations here. The one I like best is disabling HTTP compression when the referer header does not match your domain, or is blank because this will not break any functionality of the system. For high security systems, it might be better to disable HTTP compression altogether for HTTPS requests, because in theory it is possible for any part for a repeatable response to be determined.
We're currently developing an entirely AJAX based app that will interact with the server via a RESTful API. I've considered potential schemes to protect against XSRF attacks against the API.
User authenticates and receives a
session cookie, which is also
double-submitted with each request.
We implement an OAuth consumer in
Javascript, retrieve a token when
the user logs in, and sign all
requests with that token.
I'm leaning toward the OAuth approach, mainly because I'd like to provide 3rd party access to our API and I'd rather not have to implement two authentication schemes.
Is there any reason why an OAuth consumer would not work in this situation?
Most AJAX libraries will set an additional header "X-Requested-With: XMLHttpRequest", which is difficult to fake in a basic XSRF attack (though possible if combined with XSS). Verifying that this header exists is a good defense-in-depth strategy if you expect all your requests to be AJAX.
Use a two-step request, the first asking for the server an unpredictible token, the second asking for the real action with the token.
As the attacker can't predict the token, and can't read it (same origin policy) he can't give a valid token in the second query.
But be careful to not leak tokens (learn about capturing json using when they affect value to a global variable and so on) and read :
http://www.google.com/search?q=xsrf+defence
The easiest way to prevent XSRF it to check the referer of every RESTful request to make sure the request is coming from the same domain. The session cookie is important for keeping state, but it will not defend against XSRF becuase it will also be sent with a forged request. Its common to see referer based XSRF protection system on embedded network hardware with limited memory requirements, Motorola uses this method on most of their hardware. This isn't the most secure XSRF protection, token based protection is better but both systems can still be bypassed with XSS. The biggest problem with token based XSRF protection is that it takes alot of time to go back and fix every request and you will probably miss a few requests.
Make sure to read up on the same origin policy and to scan your site for xss. You should also read the OWASP Top 10 for 2010 A3-Broken Authentication and Session Management.