Re: [PATCH] Add resolve-relative-reference in (web uri), as in RFC 3986 5.2.

[Maxime Devos]

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.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature