I am building a server for both mobile and web environments and I want to have session auth alongside with token auth. However, these seem to be at odds with each other.
I have a different view for logins in both schemes.
If I log in as a user inside the browsable API and then send a request for token login for a different user, the server complains that there is no CSRF token. However if I log out, suddenly there's no problem.
I am not sure how severe it will be after frontend is implemented and the logins come from different devices, but so far it doesn't look good.
Any idea how to stop requiring CSRF token if the correct Authorization: Token <token> header is passed? Or different solution to my problem?
Default SessionAuthentication backend from DRF is built in a way that if you provide valid session in request, it will turn on CSRF validation. There are 2 possible solutions for that: either don't use two authentications method together (don't use token when you are sending valid session cookie in request) or prioritize token authentication by putting TokenAuthentication backend above SessionAuthentication in DEFAULT_AUTHENTICATION_CLASSES setting.
Related
I have been searching and reading other questions and blogs, but I didn't find anything concrete about my doubt.
A little of context:
I am developing a SPA which works with a REST API in Django by means of Django Rest Framework (DRF) and the authentication is made it through Bearer token: JWT (package 'Simple JWT'). So, I was reading whether it needs protection against CSRF:
• Do I need CSRF token if I'm using Bearer JWT?
• Should I use CSRF protection on Rest API endpoints?
• The Web API Authentication guide, Bearer tokens
Basically if the browser does not make an automatically authentication (with sessions or some kind of cookie), the odds of a CSRF vulnerability are slim. This approach is achieved with the Bearer Tokens using the JWT inside the 'Authorization' header.
Updated: In this developing stage it is setted Django-CORS, but in production it will be configured a proxy through Nginx. Avoiding CORS attacks.
The problem:
There are some public endpoints, that don't need authentication, so I used this permission in DRF settings
'DEFAULT_PERMISSION_CLASSES': ['rest_framework.permissions.IsAuthenticatedOrReadOnly'],
This way, unauthorized users only can make safe requests -methods: GET, HEAD and OPTIONS-. The users, with a JWT, can perform any kind of request.
Login and register views works through POST requests due to modify the state of the application. The issue is the above permission avoids that the 'anonymous' (to call it in somehow) user from being able to register or login. The question is, how do I protect them?
I have thought in maybe change the permission to these views to 'AllowAny'. But I don't know if this returns the concern about CSRF, because there is no Bearer token here, or perhaps other security vulnerabilities that I can't even imagine.
Another possibility is to only use the CSRF token in these views.
Or is there any better approach to protect these two endpoints?
I hope someone will be able to help me!
You can use CSRF tokens in your login and registration forms, and this will sufficiently protect you from CSRF attacks against these endpoints. You would then have to obviously allow for anonymous access to these endpoints. It's usual that login and registration endpoints are not behind a firewall and are accessible to anonymous users.
I am implementing authentication in Django using SimpleJWT, and have a few questions regarding the same. To give some background I have multiple domains with my backend, some with normal login (username and password), and some with SSO logins.
Question 2:
Suppose, I store the access tokens in local storage and send the access token to all APIs, and I'm also refreshing it before it expires. But what will happen if the user closes the browser, and we are not able to refresh the access token. The access token expires and the user gets logged out. How can we keep the user logged in for a certain amount of time (say 30 days)?
When the Access token expires, you use the Refresh token to obtain a new Access token.
This works because Refresh token has a long life, typically up to 30 days (but can be even longer if you want).
Example:
User closes browser
Comes back 10 days later
User sends a request to the server
Server will return 401 Unauthorized response because Access token has expired
Your app will send a request to obtain a new Access token using the Refresh token
If the Refresh token is valid, server will return a new Access token
If the Refresh token is expired, server will return a 401 response. That means user needs to login again.
Security considerations
Personally, I think JWT for most web apps is not an suitable idea because of conflicting opinions and advice on how to securely store the tokens.
Since a Refresh token is really powerful, it is not advised to store it in the browser. So where do you store it? And that's when this misleading idea of "backendless" web services powered by JWT starts to fall apart.
Paradoxes regarding storing tokens:
Store it in localstorage: Vulnerable to XSS attacks.
This is really serious because the XSS vulnerabilities can also come from third party JS libraries, not just from your own code. Hackers can hijack a third-party library on NPM to inject malicious code and you might be unknowingly using it in your project (it might be a dependency of a dependency of another dependency...).
Store it in httponly cookies: Safe from XSS attacks but requires a first-party backend server (because third-party auth servers can't set cookies for another domain).
If you stop to think about it, you'll notice that this case is exactly similar to the regular session auth where a session token is saved in the cookie. So why not just use session auth instead of this complicated JWT setup?
I'm going to advise you to thoroughly research this and decide whether you really need JWT for your web apps.
JWT auth using cross-origin cookies
Since you mention that your frontend apps connect to an API server in another domain, using JWT seems alright.
If you control the API server, you can setup CORS headers to allow the API server to set cookies on your apps' domains.
Important:
Since this involves Cookies, it is vulnerable to CSRF attacks. But > that is easier to prevent using CSRF tokens.
That means, with every POST request, you'll need to send CSRF token
and the API server must also validate that CSRF token
Here's a diagram I make of the auth flow in that case:
For Question 2, add this code on your settings.py file
SIMPLE_JWT = {
'ACCESS_TOKEN_LIFETIME': timedelta(days=30),
'REFRESH_TOKEN_LIFETIME': timedelta(days=30),
}
I have a React frontend running at frontend.example.com and a Django backend with DRF running at backend.example.com. I am using Django Session Authentication and I want to properly implement CSRF protection.
Taking the React login page frontend.example.com/login as an example. It's the first time for a user to visit the page. There is a form with a user and password and on submit a new POST request is created to the Django backend. To the best of my knowledge, the CSRF token cookie should already be included in this request, right?
How to obtain that CSRF token from the Django backend? I am thinking of doing a GET request to the Django backend on loading the login-page to obtain that CSRF token cookie. Is that the way to do it or is there any other best practice?
Django has a section for AJAX request and how to handle CSRF: AJAX
Using this method you should send the token over and over again for each post request. The other method is using CORS. in this method, you only respond to the domains that you already whitelisted with headers that are whitelisted as well. So, instead of getting and passing CSRF token, you check if the request is coming from the right domain and then you can respond to it. And combining with a token system for user authentication, you should be good.
You can use this package for handling CORS if you use DRF: django-cors-headers
Using rate limiting can also help you avoid spams and robots to do noticeable harm.
I have DRF set with the default settings. My ajax clients works fine with the session authentication. I want another remote server to consume the same API as the javascript clients.
My login code is simple:
class Login(APIView):
def post(self, request, *args, **kwargs):
user = authenticate(username=username, password=password)
if user is None:
return Response(status=status.HTTP_401_UNAUTHORIZED)
login(request, user)
# ...
The issue is when I use a client from another host, like python requests, I get a CSRF error. According to DRF docs, I think I should use a token authentication instead.
Questions:
Why do I need token authentication? The sessionid cookie is already a token, why I can't use it both for ajax clients and software clients? Thus avoid another separate db table for the tokens.
Since I do want to use only session authentication, how to enforce CSRF only for ajax clients?
It's not really compulsory to use Token Authentication, just that Session Authentication is liable to CSRF attacks. You can try to prevent this using CORS mecahnisms and CSRF tokens but it is still not entirely safe.
To be honest, Token Authentication doesn't entirely work well with browsers either as the token can be easily retrieved using the browser's developer tools if you don't use a very complex and sophiscated mechanism for handling it. It's just simpler to use it for third-party apps.
Though CSRF attacks are only applicable to browsers(Ajax clients), you shouldn't try to exlude them because the method of checking if the request is from an ajax client request.is_ajax() depends on whether the client has set the X-Requested-With header. It may be possible for an attacker to remove this header. Again I would advise that you also add CORS verification which is the method used by browsers to safeguard against CSRF attacks in addition to Django's CSRF tokens. This is typically done using Django-cors-headers package
And why token authentication isn't subject to csrf attacks? It does not seem more secure to me than the session. As I see it, both of them use HTTP headers to pass a token (in token authentication is in the Authorization header, and session is a cookie which is also a header)
Tokens are sent using the Authorization header(you could also decide to use a custom header but this is the standard for interoperability) while session auth uses cookies which are automatically sent by the browser and this is why they're susceptible to CSRF attacks. For tokens, the client has to explicitly set the header so it has to know the token, while the attacker will not even have to know what is stored in the cookies as the browser just automatically sends whatever is in its cookie store for that site.
You shouldn't enable CSRF protection for ajax clients only – it doesn't make any sense. How can you differentiate between "ajax" client and "normal" client? If it will be done e.g. by some query param, then an attacker can just use this "normal" link to do bad things.
When you're using token-based authentication, an attacker cannot just use common URL to make your request be authenticated transparently. That's why only session-based authentication requires a valid CSRF token to be included into request.
So for security reasons there are 2 options:
either use session-based authentication, but then you need to send auth cookie and CSRF token with every request;
or use token-based authentication, which is simpler since you only need to provide auth token e.g. as a query param.
Can I use token authentication that gets the token from the standard django_session table? just use that as token?
In theory you can achieve that by writing some custom authentication middleware that will use token from query param and match it with session table, but that's generally bad idea.
First, there's no such a big overhead in using one more table, but without it you're making the system harder to read and maintain.
Second, it will make the system more fragile as well. Since sessions and tokens are 2 completely different entities, they can have e.g. different lifetime. Sessions can be flushed, their TTL can be shorter/longer than token TTL. For example, default django session TTL is 2 weeks. Do you want to complicate remote server logic to get new token every 2 weeks? Or imagine the situation when token is compromised. Do you want to force ajax client to log out as well?
I am using Django + Django REST Framework + Django OAuth Toolkit.
I understand that AJAX calls from a web session require CSRF protection, but it is my understanding that mobile apps don’t as the very thing CSRF check are protecting against can’t happen in a dedicated app. If a person has an OAuth token, they are not using our web app so it seems I don’t need to perform CSRF checks in that case.
Is there any way to disable CSRF checks on REST Framework endpoints when a request includes an OAuth token, and if so is this a safe thing to do? Or should all requests be protected by the CSRF mechanism regardless?
You should probably be using DRF's token authentication with a mobile app. Initially, the user logs in to your backend with a username and password and then the backend issues a token for that instance of the mobile app, which [securely] stores the token locally. With token authentication and the reality of sending your credentials (over SSL/HTTPS) to the server on every request, you obviate the need for a CSRF check and thus no CSRF check is done.