Re: [Technical Errata Reported] RFC9110 (8138)

> On Oct 13, 2024, at 11:41 AM, ⁨רועי ברקאי⁩ <⁨roybarkayyosef@gmail.com⁩> wrote:
> 
> the rfc does specify as u say a case when you redirect from http://example/redirectto=page1 than to  http://example/redirectto=page2   than 
> to  http://example/redirectto=page3 to limit this so it won't go to infinity on the client side.
> but doesn't specify what to do if you  receive a request like  http://example/redirectto=http://example/redirectto=http://example/redirectto=page3
> 
> should it send the user to 
> http://example/redirectto=page3 or  http://example/redirectto=http://example/redirectto=page3 
> from the above link.
> this misguidance leads to unknown behaviors by server side and client side.
> even giant tech companies get it wrong as there is no guidance for that use case please review this real world sample 
> 
> "https://youtube.com/redirect/description&q=https://www.youtube.com/redirect/?event=video_decription&q=example.com <https://youtube.com/redirect/description&q=https://www.youtube.com/redirect/?event=video_decription&q=facebook.com>"
> 
> when that was the intended behavior "https://www.youtube.com/redirect/?event=video_decription&q=example.com <https://www.youtube.com/redirect/?event=video_decription&q=facebook.com>" 
> the lack of guidance makes vendors and tech companies not protect against this or have a systematic approach.
> Please help me by adding this to the security considerations or the correct way to handle  it in 15.4 . 

This is an application on the server. Its behavior has nothing to do with HTTP.
"/redirect/" could just as easily be the path to some YouTuber named "redirect".
The HTTP interface doesn't know and doesn't care.

If the application running on a server has a security issue, the people who wrote
that application would need to fix it. Not the IETF. Not the httpd server developers.
And certainly not the people who read RFCs.

There is no general definition of resources that accept arbitrary request target
data from an (untrusted) client and automatically rewrite that data into a
redirect to a subset of that arbitrary data. It may be common in practice, but
it has nothing to do with HTTP. That's a security hole in itself.

Hence, the only systematic approach to dealing with such mistakes is to post
a CVE specific to that application which incorrectly writes its own
application-specific redirects.

....Roy