[Technical Errata Reported] RFC9110 (8138)

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

Received on Saturday, 12 October 2024 14:32:46 UTC