24/01/13 12:02:20 (8 years ago)

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.

1 edited


  • draft-ietf-httpbis/latest/p5-range.xml

    r2153 r2157  
     398   A server that supports range requests ought to ignore or reject a
     399   <x:ref>Range</x:ref> header field that consists of more than two
     400   overlapping ranges, or a set of many small ranges that are not listed
     401   in ascending order, since both are indications of either a broken client or
     402   a deliberate denial of service attack (<xref target="overlapping.ranges"/>).
     403   A client &SHOULD-NOT; request multiple ranges that are inherently less
     404   efficient to process and transfer than a single range that encompasses the
     405   same data.
     408   A client that is requesting multiple ranges &SHOULD; list those ranges in
     409   ascending order (the order in which they would typically be received in a
     410   complete representation) unless there is a specific need to request a later
     411   part earlier. For example, a user agent processing a large representation
     412   with an internal catalog of parts might need to request later parts first,
     413   particularly if the representation consists of pages stored in reverse
     414   order and the user agent wishes to transfer one page at a time.
    398417   The Range header field is evaluated after evaluating the preconditions of
    399418   <xref target="Part4"/> and only if the result of their evaluation is
    506525Content-Type: image/gif
    508 ... 26012 bytes of image data ...
     527... 26012 bytes of partial image data ...
    513532   in <xref target="internet.media.type.multipart.byteranges"/>, and send a
    514533   <x:ref>Content-Type</x:ref> header field containing the
    515    "multipart/byteranges" media type and its required boundary parameter.
    516    For example:
    517 </t>
    518 <figure><preamble>
    519 </preamble><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
     534   multipart/byteranges media type and its required boundary parameter.
     535   Within the header area of each body part in the multipart payload, the
     536   server &MUST; generate a <x:ref>Content-Range</x:ref> header field
     537   corresponding to the range being enclosed in that body part.
     538   If the selected representation would have had a <x:ref>Content-Type</x:ref>
     539   header field in a <x:ref>200 (OK)</x:ref> response, the server &SHOULD;
     540   generate that same <x:ref>Content-Type</x:ref> field in the header area of
     541   each body part. For example:
     543<figure><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
    520544HTTP/1.1 206 Partial Content
    521545Date: Wed, 15 Nov 1995 06:25:24 GMT
    539    A server &MAY; combine requested ranges when those ranges are overlapping
    540    (see <xref target="overlapping.ranges"/>).
    541 </t>
    542 <t>
    543    A response to a request for a single range &MUST-NOT; be sent using the
    544    multipart/byteranges media type.  A response to a request for
    545    multiple ranges, whose result is a single range, &MAY; be sent as a
    546    multipart/byteranges media type with one part. A client that cannot
    547    decode a multipart/byteranges message &MUST-NOT; ask for multiple
    548    ranges in a single request.
    549 </t>
    550 <t>
    551    When a client asks for multiple ranges in one request, the
    552    server &SHOULD; send them in the order that they appeared in the
    553    request.
    554 </t>
    555 <t>
    556    When a 206 response is generated, the sender &MUST; generate the following
    557    header fields:
    558   <list style="symbols">
    559     <t>
    560         Either a <x:ref>Content-Range</x:ref> header field
    561         (<xref target="header.content-range"/>) indicating the single range
    562         included with this response, or a multipart/byteranges
    563         <x:ref>Content-Type</x:ref> indicating that multiple ranges are
    564         enclosed as multipart body-parts.
    565     </t>
    566     <t>
    567         <x:ref>Date</x:ref>
    568     </t>
    569     <t>
    570         <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
    571         <x:ref>Expires</x:ref>, <x:ref>Content-Location</x:ref> and/or
    572         <x:ref>Vary</x:ref>, if the header field would have been sent in a
    573         <x:ref>200 (OK)</x:ref> response to the same request
    574     </t>
    575   </list>
     563   When multiple ranges are requested, a server &MAY; coalesce any of the
     564   ranges that overlap or that are separated by a gap that is smaller than the
     565   overhead of sending multiple parts, regardless of the order in which the
     566   corresponding byte-range-spec appeared in the received <x:ref>Range</x:ref>
     567   header field. Since the typical overhead between parts of a
     568   multipart/byteranges payload is around 80 bytes, depending on the selected
     569   representation's media type and the chosen boundary parameter length, it
     570   can be less efficient to transfer many small disjoint parts than it is to
     571   transfer the entire selected representation.
     574   A server &MUST-NOT; generate a multipart response to a request for a single
     575   range, since a client that does not request multiple parts might not
     576   support multipart responses. However, a server &MAY; generate a
     577   multipart/byteranges payload with only a single body part if multiple
     578   ranges were requested and only one range was found to be satisfiable or
     579   only one range remained after coalescing.
     580   A client that cannot process a multipart/byteranges response &MUST-NOT; ask
     581   for multiple ranges in a single request.
     584   When a multipart response payload is generated, the server &SHOULD; send
     585   the parts in the same order that the corresponding byte-range-spec appeared
     586   in the received <x:ref>Range</x:ref> header field, excluding those ranges
     587   that were deemed unsatisfiable or that were coalesced into other ranges.
     588   A client that receives a multipart response &MUST; inspect the
     589   <x:ref>Content-Range</x:ref> header field present in each body part in
     590   order to determine which range is contained in that body part; a client
     591   cannot rely on receiving the same ranges that it requested, nor the same
     592   order that it requested.
     595   When a 206 response is generated, the server &MUST; generate the following
     596   header fields, in addition to those described above, if the field would
     597   have been sent in a <x:ref>200 (OK)</x:ref> response to the same request:
     598   <x:ref>Date</x:ref>, <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
     599   <x:ref>Expires</x:ref>, <x:ref>Content-Location</x:ref>, and
     600   <x:ref>Vary</x:ref>.
    578603   If a 206 is generated in response to a request with an <x:ref>If-Range</x:ref>
    579604   header field, the sender &SHOULD-NOT; generate other representation header
    580    fields beyond those described above.
    581    Otherwise, the sender &MUST; generate all of the same representation header
     605   fields beyond those described above because the client is understood to
     606   already have a prior response containing those header fields.
     607   Otherwise, the sender &MUST; generate all of the representation header
    582608   fields that would have been sent in a <x:ref>200 (OK)</x:ref> response
    583609   to the same request.
    645671   A server generating a <x:ref>206 (Partial Content)</x:ref> response to a
    646    byte range request &MUST; send, in each body-part of a multipart response
     672   byte range request &MUST; send, in each body part of a multipart response
    647673   or in the header block of a single part response, a Content-Range header
    648674   field containing a <x:ref>byte-range-resp</x:ref> value that reflects the
    939 <section title="Overlapping Ranges" anchor="overlapping.ranges">
    940 <t>
    941    Range requests containing overlapping ranges can lead to a situation
    942    where the server is sending far more data than the size of the complete
    943    resource representation.
     965<section title="Denial of Service Attacks using Range" anchor="overlapping.ranges">
     967   Unconstrained multiple range requests are susceptible to denial of service
     968   attacks because the effort required to request many overlapping ranges of
     969   the same data is tiny compared to the time, memory, and bandwidth consumed
     970   by attempting to serve the requested data in many parts.
     971   Servers ought to ignore, coalesce, or reject egregious range requests, such
     972   as requests for more than two overlapping ranges or for many small ranges
     973   in a single set, particularly when the ranges are requested out of order
     974   for no apparent reason. Multipart range requests are not designed to
     975   support random access.
    12051237   When a <x:ref>206 (Partial Content)</x:ref> response message includes the
    1206    content of multiple ranges, they are transmitted as body-parts in a
     1238   content of multiple ranges, they are transmitted as body parts in a
    12071239   multipart message body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>)
    12081240   with the media type of "multipart/byteranges".  The following definition is
    1212    The multipart/byteranges media type includes one or more body-parts, each
     1244   The multipart/byteranges media type includes one or more body parts, each
    12131245   with its own <x:ref>Content-Type</x:ref> and <x:ref>Content-Range</x:ref>
    12141246   fields. The required boundary parameter specifies the boundary string used
    1215    to separate each body-part.
     1247   to separate each body part.
Note: See TracChangeset for help on using the changeset viewer.