I am building a Django application where people can register for events. Everyone can register, there's no user account or login, i.e. no authentication. Verification is done through an an email with a link that has to be clicked in order to activate the registration.
I'm unsure whether I need to enable CSRF-protection for these forms. It boils down to the following question:
Is CSRF-protection necessary for every POST-request (which doesn't leave the domain) or only for POST-requests by logged-in users?
What could be done with a CSRF-attack? I know you can use it to circumvent the same origin policy and post whatever you want in the name of the user, but can you also use it to alter a real post by the user or steal their data? If a malicious site could learn the data the user posted or silently alter their request that would be a reason for me to use it. If it just means that another website can create additional registrations then no, because so can everyone else.
(I know that it doesn't cost much to just use it everywhere and I might in fact do that, but I'm trying to understand the principle better)
Contrary to the other answer, CSRF fundamentally is not about sending cookies. CSRF is about another website being able to have a user visiting it send a request to your application. If there is a session, it needs to be via something like cookies for this to be successful, because cookies for example will be sent automatically. But there are other forms of authentication that will be sent automatically, for example client certificates.
Also if there is no authentication, even easier, requests can be made. And that sounds like a problem in your case too.
What another website can do is if a user visit them, they can have that user perform actions in your application. For example they can have them register for an event, without them even noticing it. Or the malicious website can deregister people from events if that's possible. They can do whatever in the name of the victim user that is possible on your website, without the victim knowing about it, just by having them visiting the malicious website.
So to put it another way, the probelm is not that another website can perform actions in your application - they could do it with CSRF enabled too if there is no authentication. But without CSRF protection, they can have your users perform actions inadvertently in your application, just by having them visit the malicious website.
Only you can tell, whether this is a problem in your case. Without more info, I think you should have CSRF protection enabled.
CSRF attacks rely on the fact that the browser will send the information that you gave it to identify your users (cookies, typically) along with requests to your site, even ones triggered by a third party (like a malicious script).
If you don't have users, and aren't sending any such information to the browser, your application isn't in danger from CSRF.
Related
I'm developing a login page for my Django application and am using Google login for users to gain access. My question is if they sign on successfully, do I need some way to change the state of their sign on for security purposes?
Might be a silly question but I honestly have no idea and want to be sure.
No, not a silly question but a thoughtful one.
Using Google or other OAuth2 providers for your login is Ok, you request a set of scopes and when your user login and accepts to continue, you can make requests within those scopes. The flow is outlined here for Google https://developers.google.com/identity/protocols/OAuth2.
Generally, you won't have far-reaching access to manipulate users' accounts and for some scopes, your app needs to be verified. For web applications, remember your users will see the scopes you are requesting and can always decline. Because of this, it's generally a good pattern to request the scopes when you need them.
If your public application uses scopes that permit access to certain user data, it must complete a verification process. If you see unverified app on the screen when testing your application, you must submit a verification request to remove it. Find out more about unverified apps and get answers to frequently asked questions about app verification in the Help Center.
https://developers.google.com/identity/protocols/googlescopes
That's Google trying to keep users safe.
By the way, users can always revoke the access they have given your app at any time and for any reason.
I’m making a simple Django app that takes data from a user submitted form, creates an image based on the data and displays the image to the user. The problem is that the form needs to be on an existing Wordpress site. The app will only perform this one task, and the image will be discarded, so there will be no user authentication, sessions, or anything like that. Is it safe to use #csrf_exempt to make this work?
Some of the answers to Do CSRF attacks apply to API's? suggest that a csrf token is not necessary if there is no user auth. However, some of the answers also suggest that there should be some other form of authentication in place instead.
And the answer to Django - CSRF verification failed - send data from form on static website to my django app suggests that there is a way to add a csrf token to a third party site, and this would make #csrf_exempt unnecessary.
Which of these approaches is right? If my understanding of csrf is correct it makes sense to me that there is no risk of csrf without user authentication. Such an attack would not be able to achieve anything, since the third party making the attack could not perform any task they can’t perform already?
The importance of csrf protection is emphasised so much in the learning resources, I just want to be really sure I don’t need it before I turn it off!
Thanks for your help!
Your analysis is right.
CSRF protections are necessary because browsers send the target domain's cookies regardless of what domain makes the request. If your server doesn't make use of cookies (for authentication or anything else) then you are not at risk for the kinds of attacks CSRF is designed to prevent.
Some of the answers to Do CSRF attacks apply to API's? suggest that a csrf token is not necessary if there is no user auth. However, some of the answers also suggest that there should be some other form of authentication in place instead.
There are, of course, pros and cons of different forms of authentication (specifically, cookie-and-session-based vs header-and-token-based), but I don't see anyone suggesting that you should use some other form of authentication instead of no authentication at all.
I need to track unregistered users in my Django website. This is for conversion optimization purposes (e.g. registration funnel, etc).
A method I've used so far is using IP address as a proxy for user_id. For various well-known reasons, this has led to fudged/unreliable results.
Can I sufficiently solve my problem via setting a session variable at server-side? An illustrative example would be great.
For example, currently I have a couple of ways in my head. One is doing request.session["temp_id"] = random.randint(1,1000000), and then tracking based on temp_id.
Another is setting a session variable every time an unauthorized user hits my web app's landing page, like so:
if not request.session.exists(request.session.session_key):
request.session.create()
From here on, I'll simply track them via request.session.session_key. Would this be a sound strategy? What major edge-cases (if any) do I need to be aware of?
Cookies are the simplest approach, but take into consideration that some users can have cookies turned off in their browsers.
So for those users you can use javascript local storage to set some data. This information will get deleted once you close the browser, but it's ok for funneling purposes. Still others can have javascript turned off.
Another approach would be to put custom data(key) in every link of the page when generating the template. in other words you would have the session_id stored in html page and send through url parameters at click. Something similar happens with csrf token. Look into that.
I am creating a saas, software as a service site with django.
Due to the project requirements the users are inside schemas/tenants, for that im using the fantastic django-tenant-schemas app, one user can have accounts inside different schemas (they share username and password) ... i want to let the user move throught the different schemas they are in more or less freely ... for that i have created a view where the user can select on what schema he wants to be on.
When i use an application wide cookie session that is when i have the cookie setting as ".domain.ext" (django documentation) that works fine but its NOT the behaviour we really want for our application.
What we really need is to be able to have different versions of the app on different browser tabs.
So we have to set the cookie configuration to "domain.ext", then everything breaks because the original view is on one tenant and the next view (where the just logged user really belongs) is inside other tenant then the old cookie is deleted.
So the question is how can i programmatically set the cookie correctly on the new view so the user that really belongs to that tenat is still authenticated.
Or is there any alternative approach we could use for that? Any examples?
EDIT TO CLARIFY as demanded:
Person A belongs to 2 schemas SH1 and SH2 on both of them he has the same username and password.
On every password change the password hash is replicated on all the schemas they belong to so they dont have to remember specific passwords or usernames.
When the person is logged on SH1 the url will be sh1.domain.com when he is logged on SH2 the url will be sh2.domain.com
So lets say the person is now logged on schema SH1, he decides to switch to schema SH2, to be able to do that i need the user to still been authenticated so that view has to be on the SH1 schema, but then its redirected to the new schema force authenticating the user but since the cookie is set as domain specific (default django behaviour) when the user lands on the next url sh1.domain.com/whatever the previous cookie is deleted and thus he has to log in again to be able to access.
If I'm understanding correctly, you want the ability to have the behavior of a cross-domain cookie, but without actually using a cross-domain cookie.
The immediate answer that comes to mind is "well, use a cross-domain cookie". This is pretty much the vanilla example of a situation where you'd want to use use a cross-domain cookie. Engineering a complex solution so that you can avoid using the simple solution never ends well :-) Unless there's some other constraint in play that you haven't revealed, I'd start by questioning whether you shouldn't just be doing this the easy way.
However, assuming there is a good reason (and, frankly, I'd be interested to know what that is), the problem you're going to face is that browser security is essentially trying to stop you doing exactly what you're proposing. You want to know, from domain SH2, whether something has happened to a cookie set on domain SH1. That's exactly the situation that cookie security policies are designed to prevent.
The only way you're going to be able to work around this is to have a third party that can share knowledge. When user A logs into SH1, you do password authentication as normal - but you also post a flag somewhere that says "User A is now on SH1". When A logs into SH2, you post the corresponding flag. If A goes back to SH1, you check against the central source of truth, discover that they're currently on SH2, and force a login.
You probably could do this by manipulating cookies and session keys, but I suspect an easier way would be to use an Authentication backend. What you'll be writing is an authentication backend that is very similar to Django's own backend - except that it will be making checks of cross-domain login status against the central source of truth.
How you implement that "source of truth" is up to you - an in memory cache, database table, or any other source of data will do. The key idea is that you're not trying to rewrite cookies so that the same cookie works on every site - you're keeping each site's cookies independent, but using Django's authentication infrastructure to keep the cookies synchronised as a user moves between domains.
I have done a few mobile apps using django as my backend, and now I am working on a chrome extension. I want my users to be able to send POST requests up to the server using the app/extension but is there a way to do it without first asking the server for a CSRF token? It just saves the app from making two requests every time we want to submit data. For example, I want to update my profile on my social media app or update a wallet from a chrome extension. It would be nice to open up the profile view input the data and push it to the server. It's less sleek if I have to open the profile, then wait for it to grab a token from the server and then I can submit the data. Is there another way to do this? Or am I stuck making multiple requests every time I want to submit data?
Also, a little clarification, CSRF prevents sites from submitting forms with user's data. But what is to stop me from making a site that uses ajax or something to grab the real site and steal the CSRF token and then paste that into my cross site request form? I feel like there is a loophole here. I know that I am not quite understanding this all the way.
You can, and should, make any API endpoint CSRF exempt.
Django offers the csrf_exempt decorator for exactly this, see https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#django.views.decorators.csrf.csrf_exempt.
Also CSRF is intended to prevent unintended actions being performed via GET request forgeries. It is not intended to make it impossible for an automated system to submit forms, there are captchas for that.
As for what prevents you from using AJAX to grab the whole site and extract the token is something called the Same-Origin Policy. This is implemented by the browser and prevents any AJAX call from returning data when the target of the AJAX call is a different domain without the correct headers set. (I'm not entirely sure what sandboxing is applied to chrome extensions concerning this). As such it will, or at least should, fail to get data via AJAX for normal websites, e.g. a profile page. If you want to interact with third party websites you should look into whether or not they offer an API.