Re: [Technical Errata Reported] RFC9110 (8138)

["Roy T. Fielding" <[e-mail]>]

REJECT

The errata includes the wrong original text, since the comment is suggesting
an additional requirement for text after bullet 5. The actual original text is
already after bullet 5:

A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).
Note: An earlier version of this specification recommended a maximum of five redirections ([RFC2068 <https://www.rfc-editor.org/rfc/rfc9110.html#RFC2068>], Section 10.3 <https://www.rfc-editor.org/rfc/rfc2068#section-10.3>). Content developers need to be aware that some clients might implement such a fixed limitation.

 <https://www.rfc-editor.org/rfc/rfc9110.html#section-15.4.1>
There is no requirement on servers to prevent cyclical redirections because sending
the wrong instruction to a client is self-defeating (and can be configured in any
number of of ways that are outside the scope of this protocol). A client, OTOH,
will stop an infinite cycle simply by counting the requests.

A server that does not validate its own configuration files is not a protocol error.
A client that makes infinite requests is a normal DoS attack.

....Roy

> On Oct 12, 2024, at 7:32 AM, RFC Errata System <[e-mail]> wrote:
> 
> The following errata report has been submitted for RFC9110,
> "HTTP Semantics".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8138
> 
> --------------------------------------
> Type: Technical
> Reported by: Roy Yosef Barkay, Tomer Yair <[e-mail]>
> 
> Section: 15.4
> 
> Original Text
> -------------
>   5.  If the request method has been changed to GET or HEAD, remove
>       content-specific header fields, including (but not limited to)
>       Content-Encoding, Content-Language, Content-Location,
>       Content-Type, Content-Length, Digest, Last-Modified.
> 
> Corrected Text
> --------------
> 6.If a redirect request includes a target uri of 
> redirect link (a recursive redirect request) 
> such as: http://example.com/reditectto=
> ""http://example.com/redirecto="http://bad.examaple.com"" 
> a redirect to http://example.com/redirecto="http://bad.examaple.com" 
> should be made and than to 
> http://bad.examaple.com that way the security 
> messures to redirect to another domain may take place
> 
> Notes
> -----
> currently the rfc doesn't indicate how web server and 
> browsers should handle recursive rerdirect such as 
> http://example.com/reditectto="http://example.com/redirecto="http://bad.examaple.com"" 
> therefore i was able to abuse this behavior to gain 
> cve and exploitation on web server for 2 main resoans 
> 1. redirect allowed only to same domain logic : with regex on 
> the parameter "gooddomain.com/.*" which works as intended for the escape of the domain part in the uri but doesnt handle a case where there is a recursive request which is handled by server side.
> 2. out of domain control which gives the user a choice to know and 
> approve the moving to another domain because the server views the 
> request as to the same domain
> 
> the correct text should come after number 5
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC9110 (draft-ietf-httpbis-semantics-19)
> --------------------------------------
> Title               : HTTP Semantics
> Publication Date    : June 2022
> Author(s)           : R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.
> Category            : INTERNET STANDARD
> Source              : HTTP
> Stream              : IETF
> Verifying Party     : IESG
>