Web UI fails CSRF checks on some unsafe methods

[seawolf42]

Checklist

• I have verified that that issue exists against the master branch of Django REST framework.
• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• This is not a usage question. (Those should be directed to the discussion group instead.)
• This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
• I have reduced the issue to the simplest possible case.
• I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

1. Install Django and Django REST Framework as per the instructions in the quickstart
2. Set CSRF_USE_SESSIONS = True in settings
3. Navigate to /users/ and create a new user using "Post"
4. Click "Put" to update the user

Expected behavior

The PUT request is accepted

Actual behavior

Django returns a 403 and indicates a CSRF failure

Additional Information

When using session-based CSRF, no cookie is sent to the browser. For any unsafe method except POST, the CSRF token is not in the form, and even if it is included Django ignores it if the method is not POST (see CsrfViewMiddleware.process_view()).

[superandrew]

I was going to post this issue but found it before posting. Weirdly I found nothing on the web about this, so maybe it is a recent introduction. What I wanted to add is that by putting charles in the middle, it seems that the cookie is properly set and passed into the request.

However I can confirm that I can GET or POST but not PUT, PATCH (wasn't able to try DELETE).

This fails only on the DRF web ui (REST call are fine), and most importantly only on PRODUCTION. I have set up a standard cookiecutter-django on heroku and this is failing only there while locally I had no problem (and test passed).

[Edit] as correctly pointed out by @seawolf42 the problem is that the csrfmiddlewaretoken is not passed in the form in the PUT/PATCH requests, see screenshots

[seawolf42]

Is it possible that it was passing locally because a valid cookie is still in your browser state from prior to enabling USE_SESSION_CSRF? I am seeing all methods to work locally without the cookie but have not had a chance to try it in production yet.

…

On Oct 23, 2018, at 04:19, Andrea Maschio ***@***.***> wrote: I was going to post this issue but found it before posting. Weirdly I found nothing on the web about this, so maybe it is a recent introduction. What I wanted to add is that by putting charles in the middle, it seems that the cookie is properly set and passed into the request. However I can confirm that I can GET or POST but not PUT, PATCH (wasn't able to try DELETE). This fails only on the DRF web ui (REST call are fine), and most importantly only on PRODUCTION. I have set up a standard cookiecutter-django on heroku and this is failing only there while locally I had no problem (and test passed). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[superandrew]

I think it's more likely that in the local.py settings regarding CSRF token aren't enforced. By the way the cookie is always there but as you pointed out the csrf token is missing from the form, in production at least.

Locally I have this set as cookie:
Cookie: csrftoken=Bnp7xEMM8btF9IbTa0jNeVIlgytlFtgQ5GHDEkSFTdzk42i5r65DoZH30dQN3fdp; sessionid=dz10yimc47guyuzrogn1quinkm8m26u2; djdt=hide; _ga=GA1.2.[...]

@seawolf42 I don't understand if your pull request is on release 3.9 or if it has been merged. Is it?

[seawolf42]

@superandrew my PR is most likely going to appear in 3.9.1 or 3.10, according to what I've heard from the team.

[carltongibson]

Yep, this will be 3.9.1 (if there is such a release) or 3.10 (if not).