Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#19052 closed Bug (invalid)

HTTP POST Dictionary should not be populated unconditionally

Reported by: eric@… Owned by: nobody
Component: HTTP handling Version: 1.4
Severity: Normal Keywords: http, post
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When Django creates an HttpRequest object, it appears to populate the POST property by creating a QueryDict using the contents of the POST entity body unless the Content-Type header begins with "multipart" (in which case it attempts to process a file upload). This behavior produces a garbage POST dictionary if the contents of the entity body are arbitrary binary data. The populating of the POST QueryDict should be skipped unless the Content-Type specifies such processing (such as for URL-encoded form data). It should not perform this processing, for example, if the Content-Type is application/octet-stream.

Change History (3)

comment:1 Changed 2 years ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

It appears to me that request.POST is loaded lazily at the first access.

Could you clarify why you think it's unconditionally loaded at the creation of the HttpRequest?

comment:2 Changed 2 years ago by anonymous

Yes, what I meant to say that although it is lazily loaded, if accessed, it is unconditionally populated with the contents of the entity body. The resulting QueryDict is garbage. An application that attempts to access request.POST (or request.REQUEST) may get erroneous results. The specific case I ran into is that in the application/octet-stream entity body, there were values that could get parsed into name/value pairs in request._post. However, they were never intended as query or form data parameters, yet showed up in the request.POST dictionary. The application attempted to locate a parameter which was NOT specified in the query parameters, but which showed up in request.POST because it was put there upon lazy loading of the post data.

comment:3 Changed 2 years ago by claudep

I think this is a valid concern and a duplicate of #5611. We currently assume that POST content is either multipart or form-urlencoded. We are not prepared to handle a POST request like:

POST /url HTTP/1.1
Host: www.example.com
User-Agent: ...
Content-Type: application/octet-stream
Content-Length: n

Here is binary content
Note: See TracTickets for help on using tickets.
Back to Top