I looked at the GitHub OAuth API and saw that one requirement to send to the endpoint is state.
Sending it is trivial - but how do you validate that the state you sent is the same one you’re receiving?
I thought of using browser caching but it seems like it’s for views of Django and improving performance.
I thought of sending a CSRF token as the state but it seems it’s meant for forms you generate.
In short, how do you validate state in Django? Is there a Pythonic way in Django to do so?
The user's session is the best place to store variables that are session related, which is the case here.
So generate your state and store it into the user's session:
request.session['github_state'] = state
return render(<template with github link>, context={'state': state})
Then when you receive the user's authorised GET request:
if request.session.get('github_state') and not request.GET.get('state') == request.session['github_state']:
# abort here
else:
code = request.GET.get('code')
# POST request with code to GitHub to fetch the access token
I'm checking that the session variable isn't empty/None, otherwise both might be empty and the check would pass.
Related
I'm building a Django where the admin will create a user and then one mail will be sent to the user. In the mail, I'm also sending one token with the URL on clicking which the user will get verified by checking the correctness of the token.
But the problem is I'm storing the token in Django session and when I open the link on the same browser it works but on a different machine user is not getting verified as session data becomes unavailable.
Someone suggest me the best way to store the token.
I didn't want to use the database as it doesn't make sense.
Hey guys I am confused and was thinking about this problem for sometime now, I am storing the current user's username in the session storage, and I have another page in which I use the stored username for an api call, it can be any requests.
Eg. a post can be deleted by its author only, suppose, the url is api/<slug>/delete and in the frontend I have enabled the delete button only for the corresponding user, what if he edits the front end page and changes it to his username or what if I use the stored username to check that condition?
And if he sends a delete request successfully from the frontend, does the django server able to determine that the user in the current session is not the real owner and has tweaked it in the frontend?
Ps. This might be a foolish question, but I am a beginner and quite confused.
Thanks.
Naturally, we would need some code to answer your question.
Will the following delete some other user's data?
A user passes a username from the client to the server
SomeModel.objects.filter(username=username).delete()
Will the above delete the user data whose username is what has been passed from the client? Yes.
You need to always verify and validate data and permissions on the server, and also you should consider using CRUD operations on the current authenticated user (since you are working with sessions), so you don't have to send the current user' username from client, if they are logged in, that can be validated with their session.
I'd advise you to read a little more on Authentication, sessions, ect. authentication in Django
Also, I see you are using A RESTful API, so I would strongly recommend using DRF
I am trying to enforce CSRF for a Django Rest API which is open to anonymous users.
For that matter, I've tried two different approaches:
Extending the selected API views from one CSRFAPIView base view, which has an #ensure_csrf_cookie annotation on the dispatch method.
Using a custom Authentication class based on SessionAuthentication, which applies enforce_csrf() regardless of whether the user is logged in or not.
In both approaches the CSRF check seems to work superficially. In case the CSRF token is missing from the cookie or in case the length of the token is incorrect, the endpoint returns a 403 - Forbidden.
However, if I edit the value of the CSRF token in the cookie, the request is accepted without issue. So I can use a random value for CSRF, as long as it's the correct length.
This behaviour seems to deviate from the regular Django login view, in which the contents of the CSRF do matter. I am testing in local setup with debug/test_environment flags on.
What could be the reason my custom CSRF checks in DRF are not validated in-depth?
Code fragment of the custom Authentication:
class RestCsrfAuthentication(SessionAuthentication):
def authenticate(self, request):
self.enforce_csrf(request)
rotate_token(request)
return None
And in settings:
REST_FRAMEWORK = {
'DEFAULT_AUTHENTICATION_CLASSES': [
'csrfexample.authentication.RestCsrfAuthentication',
]
}
The specific contents of CSRF tokens in Django never matter, actually.
This reply by a Django security team member to a question similar to yours says this:
The way our CSRF tokens work is pretty simple. Each form contains a CSRF token, which matches the CSRF cookie. Before we process the protected form, we make sure that the submitted token matches the cookie. This is a server-side check, but it's not validating against a stored server-side value. Since a remote attacker should not be able to read or set arbitrary cookies on your domain, this protects you.
Since we're just matching the cookie with the posted token, the data is not sensitive (in fact it's completely arbitrary - a cookie of "zzzz" works just fine), and so the rotation/expiration recommendations don't make any difference. If an attacker can read or set arbitrary cookies on your domain, all forms of cookie-based CSRF protection are broken, full stop.
(Actually "zzzz" won't work because of length requirements, but more on that later.) I recommend reading the entire mailing list message for a fuller understanding. There are explanations there about how Django is peculiar among frameworks because CSRF protections are independent of sessions.
I found that mailing list message via this FAQ item on the Django docs:
Is posting an arbitrary CSRF token pair (cookie and POST data) a vulnerability?
No, this is by design. Without a man-in-the-middle attack, there is no way for an attacker to send a CSRF token cookie to a victim’s browser, so a successful attack would need to obtain the victim’s browser’s cookie via XSS or similar, in which case an attacker usually doesn’t need CSRF attacks.
Some security audit tools flag this as a problem but as mentioned before, an attacker cannot steal a user’s browser’s CSRF cookie. “Stealing” or modifying your own token using Firebug, Chrome dev tools, etc. isn’t a vulnerability.
(Emphasis mine.)
The message is from 2011, but it's still valid, and to prove it let's look at the code. Both Django REST Framework's SessionAuthentication and the ensure_csrf_cookie decorator use core Django's CsrfViewMiddleware (source). In that middleware class's process_view() method, you'll see that it fetches the CSRF cookie (a cookie named csrftoken by default), and then the posted CSRF token (part of the POSTed data, with a fallback to reading the X-CSRFToken header). After that, it runs _sanitize_token() on the POSTed/X-CSRFToken value. This sanitization step is where the check for the correct token length happens; this is why you're getting 403s as expected when you provide shorter or longer tokens.
After that, the method proceeds to compare the two values using the function _compare_salted_tokens(). If you read that function, and all the further calls that it makes, you'll see that it boils down to checking if the two strings match, basically without regard to the values of the strings.
This behaviour seems to deviate from the regular Django login view, in which the contents of the CSRF do matter.
No, it doesn't matter even in the built-in login views. I ran this curl command (Windows cmd format) against a mostly default Django project:
curl -v
-H "Cookie: csrftoken=abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl"
-H "X-CSRFToken: abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl"
-F "username=admin" -F "password=1234" http://localhost:8000/admin/login/
and Django returned a session cookie (plus a CSRF cookie, of course).
Just a note on the way you're overriding SessionAuthentication.authenticate(): you probably already know this, but according to the DRF docs that method should return a (User, auth) tuple instead of None if the request has session data, i.e. if the request is from a logged-in user. Also, I think rotate_token() is unnecessary, because this code only checks for authentication status, and is not concerned with actually authenticating users. (The Django source says rotate_token() “should be done on login”.)
I understand that Flask JWT gives us the /auth endpoint. Once a user successfully logs in, an access token is assigned and the logged in user can be stored in Flask JWT's current_identity. What I'm wondering is can I also return the User Json back to my client in the same /auth endpoint? Or does it have to be a separate request?
This is for a mobile rest-api, using Flask-Restful. Right now, I have a user log in. The login route (/auth) returns the access token to the client, and then I use the token to get the User Json in a separate request, but I feel like I should be able to condense this into the same request.
Any tips are appreciated :)
IDEA:
Can I create an auth resource via flask-restful and specify exactly what I want it to return? (the token for the server and the user json to the client?)
Flask-JWT has been abandoned for quiet a while now. I would suggest checking out Flask-JWT-Extended instead as an alternative that is still actively maintained (full disclosure, I'm the author of that extension).
In Flask-JWT-Extended you create your own endpoint instead of having the extension create one for you, so you can return whatever data you want there. Here is an example of this in action: http://flask-jwt-extended.readthedocs.io/en/latest/basic_usage.html
I have a django web app with a RESTful API written using TastyPie. I want to allow my mobile app access to the API that uses username and api_keys, but have struggled to know what the best way to get the api_key back to the mobile client.
I am following the resource code provided here:
How can I login to django using tastypie
My question is if this is a secure method of passing a username and password as data parameters in a POST request. Should I be okay?
Here is an example of the post request:
POST to http://myapp.com/api/user/login with data { 'username' : 'me',
'password' : 'l33t' }.
While data sent over a POST request can be sniffed, that doesn't necessarily mean that you shouldn't be using it to submit user credentials to your RESTful API. So, to answer your question directly:
POSTing a username and password for authentication is not secure. It can be sniffed.
That being said, submitting user credentials in this fashion is something that in my experience is done quite often. A good practice is returning a remember token (or in your case API key) to the user once they have been authenticated. Aside from persisting sessions, the advantage is that if some malicious user gets hold of an API key, it can be reset easily without needing to reset the user's username/password (although it might be a good idea to do so anyway). Of course the downside is that remember tokens/API keys are generally stored in unsafe places like browser cookies/mistakenly in the source of some github repo.
So, is POSTing authentication credentials sniff-proof, no. Can you do it/is it done, yes.
Of course, you can see if HTTPS is an appropriate solution for you in this context if you require more security.
No, sending cleartext credentials is never secure. Anyone sniffing the traffic (including sniffing the traffic and dumping it all into a big logfile) will have the credentials.