Op 04-10-2023 om 07:29 schreef Vivien Kraus:
> Le mercredi 04 octobre 2023 à 00:30 +0200, Maxime Devos a écrit :
>>
>>>        The best prevention is not allowing redirects at all or only
>>>        allowing redirections that keep the hostname intact -- while
>>> an
>>>        option for much software, it isn't an option for web
>>> browsers.
>>
>> Partially scratch that -- restricting to ‘keeping hostname intact’ is
>> insufficient, because there could be a DNS record that points
>> 'website
>> via http' to 127.0.0.1, and hence a redirect from https://website -->
>> http://website can change IP addresses from global Internet to local
>> computer.
> 
> But then, it is not a problem with resolve-relative-reference, and not
> even a risk with redirections; if the DNS changes before you query the
> page, then the secret page leaks anyway, no redirection needed. >
> We could add a warning in the "http-request" method documentation,
> like:
> 
> Be warned that if you are hosting a private HTTP(s) server on your
> system, a DNS change for a public target URI to your internal IP
> address, or following a redirection from a public target URI to your
> private server, may lead you to consider the response originating from
> your private server as public.
> 
> Would that be a good summary?

Hum I was thinking from the perspective of the client, whereas this 
considers things form the perspective of the server, but that works too 
I suppose.

However, I am confused by the phrasing of the last sentence

 > [...],  may lead you to consider the response originating from
 > your private server as public.

After reading it again, I think I understand it, but I would instead 
propose:

 > may allow you to accidentally contact your private server as if it 
were public.  Depending on the application, an attacker could exploit this.

because:

   * while the responses can be a problem, another problem is that
     a request is sent in the first place -- as a problematic example,
     the private server could have a buffer overflow somewhere that
     is remotely triggered by the attacker via a redirection to a long
     URL triggering the buffer overflow (with an attacking payload!).

     For another example, consider PUT/POST/DELETE/... instead of GET.

   * to make it clear this is a potential security problem.
     ‘Be warned’ doesn't cut it IMO.

   * another reason I can't word properly, something about the
     'as public'.

Best regards,
Maxime Devos.