* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #95 (closed design: fixed)

Opened 7 years ago

Last modified 2 years ago

Handling multiple Content-Length header fields

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: normal Milestone: 14
Component: p1-messaging Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/87k5nu8gbw.fsf@bluewind.rcis.aist.go.jp

Description

Many servers and proxies accept messages containing two Content-Length: headers in different manners: some interpret the first header, and some do the latter. This has caused "request/response smuggling attacks", when any pair of the server, the proxy, and the clients involved are interpreting those differently. The outcome of the attack is severe: it allows cross-site content injection.

Change History

comment:1 Changed 7 years ago by mnot@pobox.com

To fix this, I recommend to add the following note to the specification.

Messages MUST NOT include any hop-to-hop header twice. When the server received such a request, it MUST respond with 400 (Bad Request) and close the connection. When the client received such a response, it MUST discard the response and close the connection. The client MUST NOT accept any responses which follow such an invalid response in a keep-alive connection.

The requirement words may be "SHOULD" and "SHOULD NOT", and the restricted headers can be limited to Connection, Transfer-Encoding, and Content-length.

comment:2 Changed 7 years ago by mnot@pobox.com

  • Milestone set to unassigned

comment:3 Changed 5 years ago by mnot@pobox.com

  • Priority set to normal

sever-side requirement for requests makes sense, but client handling is too specific; should just require that there aren't any more usable responses on the connection, and possibly just limit it to intermediaries, not all clients.

also only applies to Content-Length and Host.

comment:4 Changed 4 years ago by fielding@gbiv.com

From [852]:

Changed message-body ABNF to be *OCTET. Specifying the actual number of octets will have to be done in prose.

Moved mistitled "Message Length" section into the Message Body section, since it only explains how many octets are in the body. Deleted useless "Entity Length" section and transfer-length term.

Addresses #28: Connection closing

Removed redundant mention of terminating by connection close and rewrote explanation so that it doesn't self-contradict.

Addresses #90: Delimiting messages with multipart/byteranges

Removed message-delimiting paragraphs of multipart/byteranges from p1 and p3.

Addresses #95: Handling multiple Content-Length headers

Added requirements for what to do if multiple or invalid Content-Length is received.

Rephrased requirements for Transfer-Encoding to only apply when a transfer-coding is present. Clarify that Transfer-Encoding overrides Content-Length and treat receiving both as an error. Clarify that only the chunked transfer-coding can delimit a message (the original design allowed other self-descriptive encodings, but that was abandoned in 2616).

Addresses #109: Clarify entity / representation / variant terminology

Entity-body terminology changed to payload in order to clarify that it is what gets packaged (as a message-body) into a message, allowing us to (eventually) distinguish between messages containing whole representations and messages containing only partial representations. Reduce use of the same terms for other things (e.g., in explanation of dates).

comment:5 Changed 4 years ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to incorporated
  • Severity set to Active WG Document

I think this is completely incorporated in editor's draft, though resolution may need discussion on list.

comment:6 Changed 4 years ago by julian.reschke@gmx.de

From [859]:

Remove paragraphs in "changes from 2068" about message length handling that do not apply anymore after recent changes; update the remaining to not point to the other parts (see #90)(see #95)(see #109)

comment:7 Changed 4 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 11

comment:8 Changed 4 years ago by julian.reschke@gmx.de

From [1001]:

Note new requirements on handling bogus Content-Length header fields (see #95)

comment:9 Changed 4 years ago by mnot@pobox.com

comment:10 Changed 4 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

Reopening based on discussion with browser vendors.

comment:11 Changed 4 years ago by mnot@pobox.com

comment:12 Changed 4 years ago by julian.reschke@gmx.de

From [1031]:

multiple content-length headers in response -> SHOULD discard (see #95)

comment:13 Changed 4 years ago by julian.reschke@gmx.de

  • Status changed from reopened to closed
  • Resolution set to incorporated

comment:14 Changed 4 years ago by mnot@pobox.com

  • Milestone changed from 11 to 12

comment:15 Changed 4 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

Still being discussed on-list.

comment:16 Changed 4 years ago by mnot@pobox.com

  • Milestone changed from 12 to unassigned

comment:17 Changed 4 years ago by julian.reschke@gmx.de

Status in -12: "SHOULD discard". Open issues: (a) MUST? (b) What about multiple headers that specify the same length?

comment:18 Changed 4 years ago by mnot@pobox.com

Both Chrome and Mozilla seem to have settled on allowing multiple C-Ls if they're dups.

The only SHOULD I see is

If this is a response message received by a user-agent, it SHOULD be treated as an error by discarding the message and closing the connection.

... which I think we're justified in making a MUST. Will take to list.

comment:19 Changed 4 years ago by mnot@pobox.com

  • Owner set to mnot@pobox.com
  • Status changed from reopened to new

comment:20 Changed 4 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 13

Proposal:

  • add text that allows duplicates explicitly, and
  • upgrade the SHOULD to a MUST in this requirement:

If this is a response message received by a user-agent, it SHOULD be treated as an error by discarding the message and closing the connection.

comment:21 Changed 4 years ago by fielding@gbiv.com

From [1156]:

Explicitly require that recipients fix duplicate received Content-Length and correctly combine multiple Transfer-Encoding fields prior to determining the message-body length. Require (MUST instead of SHOULD) user agents to discard messages with framing errors that might indicate response smuggling.

Addresses #95

comment:22 Changed 4 years ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to incorporated

comment:23 Changed 4 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted
  • Milestone changed from 13 to unassigned

Pending discussion on whether it's necessary to require folding of dup C-L's; see

<http://www.w3.org/mid/4D7802C4.6020703@gmx.de>

comment:24 Changed 4 years ago by fielding@gbiv.com

From [1214]:

Adjust handling of duplicate content-length to allow recipient to reject the message. Addresses #95

comment:25 Changed 4 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to incorporated
  • Milestone changed from unassigned to 14

comment:26 Changed 4 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:27 Changed 4 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed

comment:28 Changed 2 years ago by julian.reschke@gmx.de

  • Summary changed from Handling multiple Content-Length headers to Handling multiple Content-Length header fields
Note: See TracTickets for help on using tickets.