CSRFMiddleware should strip POST dat instead of showing the user an error message if a forgery is detected

[Zain Memon]

If a page receives a POST that doesn't contain the 'csrfmiddlwaretoken' variable, it shows the following message: "Cross Site Request Forgery detected. Request aborted."

Instead of showing the user this message, I propose just stripping out the POST data. That could help improve user experience in the case of when a site outside your control is redirecting to you.

For example; if a user is paying you via Paypal web payments, they get redirected back to your website at the end. During this step, Paypal POSTs some (non-critical) information. At this point, the CSRF middleware shows the user an error. As a result, it is impossible to use the CSRF Middleware on a website that accepts paypal web payments.

The patch I have attached merely sets request.POST = [] instead of giving the user an HttpResponseForbidden message.

[Daniel Pope <dan@…>]

Assigning an empty list to request.POST breaks API compatibility. You should assign an empty django.http.QueryDict. If the view is to be executed anyway it also might be useful to move the real POST data to request.UNTRUSTED_POST so that it would be possible to process PayPal data.

However, I think the error message would more useful to users than silently suppressing POST data. A minor refactoring of CsrfMiddleware would let users easily subclass it to provide whatever behaviour they prefer when the POST data doesn't validate.

[Glenn Maynard]

If you're expecting an external website to POST data at a specific page on yours, shouldn't you @csrf_view_exempt the view it's returning to?

I guess it would help for contrib.csrf to expose a way to check a request manually, so you can @csrf_view_exempt a view and then handle a failed CSRF check some other way. This would make it easy to implement things like @csrf_view_clear_post, too.

[Luke Plant]

This suggestion has problems. It is perfectly possible for a view to respond to an empty POST request with some action - if the URL and session data have all the necessary information needed, for example, or if all other data retrieved from POST is optional, or could be valid if empty (so that view code does things like request.POST.get('somefield', '') and proceeds without requiring the data to be non-empty).

With either of the proposed change (empty list or empty QueryDict), the request would make it through, which is a vulnerability. In other words, the suggestion assumes that empty POST requests are not dangerous, when that is not necessarily the case.

In addition, the correct way to handle the scenario given has been described above (use csrf_exempt), and fuller examples are now in the docs.

Therefore closing INVALID.