RFC Errata
RFC 9110, "HTTP Semantics", June 2022
Source of RFC: httpbis (wit)
Errata ID: 8138
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Roy Yosef Barkay, Tomer Yair
Date Reported: 2024-10-12
Rejected by: Francesca Palombini
Date Rejected: 2024-10-29
Section 15.4 says:
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.
It should say:
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
--VERIFIER NOTES--
In rejecting this errata report, I note that the aim of this erratum is not to fix an apparent error, but an addition to the current tex. This sort of text change is not in scope for errata reports, which are meant to collect errors in the documents, things that were actual errors at publication and that would have been fixed at that time had the working group or document authors noticed them -- they were just missed. This is not the case here.
Additionally, cyclical redirections are already addressed for clients, and are not relevant for servers, see: https://mailarchive.ietf.org/arch/msg/httpbisa/o3-eUDiKUiC_nWi-5s1wOOmMesU/ for details.