Bug 8229 - No handling for Transfer-Encoding in POST requests
Summary: No handling for Transfer-Encoding in POST requests
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Administration (show other bugs)
Target Milestone: MediumPrio
Assignee: Bugzilla mail exporter
Depends on:
Blocks: 6003
  Show dependency treegraph
Reported: 2023-09-14 13:22 CEST by Alexander Zeijlon
Modified: 2023-09-19 13:16 CEST (History)
0 users

See Also:
Acceptance Criteria:


Description Alexander Zeijlon cendio 2023-09-14 13:22:51 CEST
In bug 8161 we replaced the deprecated Lib/cgi.py with our own function for parsing POST requests, called parse_post_request.

The parse_post_request function assumes the following:
1. The size of the request body is communicated in the Content-Length header.
2. The request body can be read as one contiguous chunk.
3. If the Content-Length header is missing, the body can be read until the socket returns no more data.

This means that we do not handle cases where the Transfer-Encoding header is present. In which case, there could be situations where the request body should not be read as one single chunk.

We should therefore add the ability to handle POST requests using the Transfer-Encoding header to make our POST request handling more robust.
Comment 1 Alexander Zeijlon cendio 2023-09-14 13:35:24 CEST
Transfer-Encoding and Content-Length should never be present in the same request, and to be able to safely make the third assumption in comment 0, we need to be sure that the request is, in fact, not using Transfer-Encoding.

The parse_post_request function will therefore disallow transfer encoded requests entirely, in place of a real implementation.
Comment 2 Alexander Zeijlon cendio 2023-09-14 13:51:05 CEST
Since having both Transfer-Encoding and Content-Length headers present can have security implications [1], we decided to treat such requests as "400 Bad Request". This is supported by the clear wording in the specification [2].

Even so, we may want to apply a somewhat relaxed constraint instead of always opting for bad request. The specification suggests that one can take only Transfer-Encoding into account if both headers are present [1], given that the connection is closed directly after handling the request.

[1] https://www.rfc-editor.org/rfc/rfc9112#section-6.1-14
[2] https://www.rfc-editor.org/rfc/rfc9112#section-6.2-2

Note You need to log in before you can comment on or make changes to this bug.