Re: [Technical Errata Reported] RFC9110 (8138)

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 <rfc-editor@rfc-editor.org> 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 <roybarkayyosef@gmail.com>
> 
> 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
>