Re: [quicwg/base-drafts] Request forgery attacks (#3995)

MikkelFJ <notifications@github.com> Wed, 12 August 2020 07:46 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44583A1111 for <quic-issues@ietfa.amsl.com>; Wed, 12 Aug 2020 00:46:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Level:
X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6zwS8ciCbmh for <quic-issues@ietfa.amsl.com>; Wed, 12 Aug 2020 00:46:23 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6539C3A1115 for <quic-issues@ietf.org>; Wed, 12 Aug 2020 00:46:23 -0700 (PDT)
Received: from github-lowworker-5825cd4.ac4-iad.github.net (github-lowworker-5825cd4.ac4-iad.github.net [10.52.22.68]) by smtp.github.com (Postfix) with ESMTP id 997C7E05AC for <quic-issues@ietf.org>; Wed, 12 Aug 2020 00:46:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1597218382; bh=roIi5Je3khO7OlbDLpBBOFWBwkqzEK+P22L4lb2v3B8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LnUPk0EPUum1j7NevMm8yGx9nT3Bds7vb5NesBPUiqsdrdLcr54CEIeSw6ssVj1aF UQOZyqND+Rq38Ivjx5t0ZLc3d83E/z7Phm5arnirzmJC0AtKBbrnX9V2INUtm2/Wo7 TMKlHGTq8sKE5SpLdFP4In+OhOBgCCFh2pIOZr0A=
Date: Wed, 12 Aug 2020 00:46:22 -0700
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZ5Z4X2Z46MJ6OUKMV5H57U5EVBNHHCQYGADU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3995/672700043@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3995@github.com>
References: <quicwg/base-drafts/issues/3995@github.com>
Subject: Re: [quicwg/base-drafts] Request forgery attacks (#3995)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f339e4e89e57_17e816f83262fd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/1JnBvEzAz1CnPi-ATCgqASzMH0Q>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2020 07:46:25 -0000

Interesting.

In the issue you mention loopback but then goes on to use a local router address.
I was thinking loopback was on the clients machine.

It is often the case that documentation servers run on localhost to display content, and some applications may be written to either directly use a browser interface, or indirectly via electron to a local host.

These types of applications are generally not hardened and therefore comparatively easy to exploit. In the worst case, such application insists on running on port 80 or some other privileged port thereby having elevated permissions.

But, how does this new attack differ from a HTTP redirect from a random web server, where part of the url is designed til trigger a vulnerability?

I can see some level of same domain protection for HTTPS, but as far as I am aware, such protections to not apply to redirects.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3995#issuecomment-672700043