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

Ticket #311 (closed design: fixed)

Opened 3 years ago

Last modified 18 months ago

Add limitations to Range to reduce its use as a denial-of-service tool

Reported by: fielding@gbiv.com Owned by:
Priority: normal Milestone: 22
Component: p5-range Severity: In WG Last Call
Keywords: Range Cc:
Origin:

Description

Servers that support Range requests as defined by 2616 are vulnerable to denial of service attacks due to the potential presence of many small or overlapping ranges. We can fix this by adding the following requirements:

1) Clients MUST NOT send Range requests containing multiple byterange specifiers that overlap. Servers MAY coalesce such overlapping ranges into a single range, regardless of the order those ranges are specified in the Range header field, or MAY respond with a 416 or 200 status instead.

2) Clients MUST NOT send Range requests containing multiple byterange specifiers that have a gap between ranges of less than 80 bytes, since the transmission overhead of multipart/byteranges parts is generally more than 80 bytes per range and is a far more significant burden on the server than simply transmitting the gap. Servers MAY coalesce multiple ranges with gaps smaller than the size of the corresponding multipart overhead, regardless of the order that those ranges are specified in the Range header field, or MAY respond with a 416 or 200 status instead.

3) Clients that send Range requests containing multiple byterange specifiers MUST list those ranges in ascending order within the Range header field value. Servers MAY reorder multiple ranges if they are not requested in ascending order, or respond with a 416 or 200 status instead.

Change History

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

  • Owner draft-ietf-httpbis-p5-range@tools.ietf.org deleted

comment:2 Changed 3 years ago by ylafon@w3.org

See [1542]

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

From [1543]:

tune changes for [1542] (see #311)

comment:4 Changed 3 years ago by ylafon@w3.org

The changes in [1542] were only editorial:

  • Clarification that server can combine ranges (was only implicit in multipart/byterange text in RFC 2616)
  • Clarification that a server can ignore a Range: header if it detects an DoS attempt (which was already possible before especially as Range is optional)

Those changes mitigate the use of Ranges in DoS attempts while not creating extra requirements or changing conformance of existing implementations.

comment:5 Changed 3 years ago by ylafon@w3.org

  • Status changed from new to closed
  • Resolution set to incorporated
  • Milestone changed from unassigned to 19

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

  • Status changed from closed to reopened
  • Resolution incorporated deleted

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

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

comment:8 Changed 22 months ago by fielding@gbiv.com

  • Status changed from closed to reopened
  • Resolution fixed deleted

It is a security concern that wasn't fixed.

comment:9 Changed 22 months ago by mnot@pobox.com

  • Milestone changed from 19 to unassigned

comment:10 Changed 22 months ago by mnot@pobox.com

  • Severity changed from Active WG Document to In WG Last Call

comment:11 Changed 21 months ago by fielding@gbiv.com

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

From [2157]:

Address range flooding security issue (#175 and #311) by direct requirements and recommendations.

Actually require Content-Range and Content-Type (when appropriate) inside multipart/byteranges body parts instead of assuming that the reader will read between the lines of the MIME registration template.

Simplify description of required headers in 206 responses.

comment:12 Changed 18 months ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:13 Changed 18 months ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.