Re: [Technical Errata Reported] RFC9110 (8138)

On 12.10.2024 16:32, RFC Errata System 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
Please reject this erratum.

RFCs are not meant to contain exhaustive descriptions about how to 
protect from potential attacks.

Best regards, Julian

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

Received on Sunday, 13 October 2024 05:08:44 UTC