From: Maxime Devos <maximedevos@telenet.be>
To: Vivien Kraus <vivien@planete-kraus.eu>, guile-devel@gnu.org
Subject: Re: [PATCH] Add resolve-relative-reference in (web uri), as in RFC 3986 5.2.
Date: Tue, 10 Oct 2023 23:44:54 +0200 [thread overview]
Message-ID: <98acd379-847c-c3c3-c8ad-02f4e18d1ad0@telenet.be> (raw)
In-Reply-To: <5319ff8510e26e07bcd607be099cd34c8be12e58.camel@planete-kraus.eu>
[-- Attachment #1.1.1: Type: text/plain, Size: 2576 bytes --]
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.
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
next prev parent reply other threads:[~2023-10-10 21:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-25 16:48 [PATCH] Add resolve-relative-reference in (web uri), as in RFC 3986 5.2 Vivien Kraus
2023-09-25 20:46 ` Maxime Devos
2023-09-25 16:48 ` [PATCH v2] " Vivien Kraus
2023-10-02 16:32 ` Vivien Kraus
2023-10-03 18:49 ` Maxime Devos
2023-09-25 16:48 ` [PATCH v3] " Vivien Kraus
2023-10-03 18:56 ` [PATCH v2] " Dale Mellor
2023-10-03 19:04 ` Maxime Devos
2023-10-03 20:03 ` [PATCH] " Vivien Kraus
2023-10-03 22:22 ` Maxime Devos
2023-10-03 22:30 ` Maxime Devos
2023-10-04 5:29 ` Vivien Kraus
2023-10-10 21:44 ` Maxime Devos [this message]
2023-09-25 16:48 ` [PATCH v4] " Vivien Kraus
2023-11-02 20:00 ` Nathan via Developers list for Guile, the GNU extensibility library
2023-11-02 20:48 ` Vivien Kraus
2023-11-03 17:49 ` Nathan via Developers list for Guile, the GNU extensibility library
2023-11-03 18:19 ` Vivien Kraus
2023-11-27 17:10 ` Vivien Kraus
2023-11-27 17:15 ` Vivien Kraus
2023-11-29 1:08 ` Nathan via Developers list for Guile, the GNU extensibility library
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98acd379-847c-c3c3-c8ad-02f4e18d1ad0@telenet.be \
--to=maximedevos@telenet.be \
--cc=guile-devel@gnu.org \
--cc=vivien@planete-kraus.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).