IETF Logo Mail Archive

[apps-discuss] URI parsing tests: userinfo handling

Julian Reschke <julian.reschke@gmx.de> Fri, 02 January 2015 10:01 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC6B1A0338 for <apps-discuss@ietfa.amsl.com>; Fri, 2 Jan 2015 02:01:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 0veZU4-nAspI for <apps-discuss@ietfa.amsl.com>; Fri, 2 Jan 2015 02:01:40 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC041A0270 for <apps-discuss@ietf.org>; Fri, 2 Jan 2015 02:01:39 -0800 (PST)
Received: from [192.168.2.121] ([93.217.73.238]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LxPAo-1XmgE71GRu-016tAV; Fri, 02 Jan 2015 11:01:29 +0100
Message-ID: <54A66C73.7000508@gmx.de>
Date: Fri, 02 Jan 2015 11:01:23 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>, Graham Klyne <gk@ninebynine.org>
References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <EAACE200D9B0224D94BF52CF2DD166A425A68A90@ex10mb6.qut.edu.au> <CACweHNBEYRFAuw9-vfeyd_wf703cvM3ykZoRMqAokRFYG_O7hQ@mail.gmail.com> <DM2PR0201MB09602B351692D424A49C6B0DC3650@DM2PR0201MB0960.namprd02.prod.outlook.com> <CACweHNBN_Bv=jeXQ_VwXi2HzHKNEwZJ1NiF-BJJo_9-mhO60gQ@mail.gmail.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net>
In-Reply-To: <54A59B26.5000408@intertwingly.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:HG43U0sCyA9qovv39o5sQmWtQAqx/Tr0+ivG5ZqyA4XEnUgcfPB 00yjWfwhVXKP9H7XF38FdMgRnbz5CHgb86RO2z09j6lo37nij5gXhXzLMOKWjB5S6+dPuh3 DkanjdtKrpx9hcscqWoaqAn4giuuem6Ar4PxvQRZKgYknLNUT5rDkyoAjSDM50zEm23/6pJ 9ezQcK8IalpFMpe8YoNDw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Dk0eoKimWtYaYGBjUkp2s-8QotE
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] URI parsing tests: userinfo handling
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jan 2015 10:01:42 -0000

On 2015-01-01 20:08, Sam Ruby wrote:
 > ...
 > I have evidence that RFC 3986 doesn't match a variety of user agent
> behavior.  Agents that aren't limited to browsers, but also to libraries
> that are used by what you would consider "middleware".
>
> Here is a filtered list of test results that only considers RFC 3986
> valid URI references as inputs:
>
> https://url.spec.whatwg.org/interop/test-results/?filter=valid
> ...


So I'm now looking at the first valid entry with UA differences:

<https://url.spec.whatwg.org/interop/test-results/19b44e58a2?filter=valid>

which tests:

   http://user:pass@foo:21/bar;par?b#c

This one is valid per the RFC 3986 ABNF and it contains a "userinfo" 
component.

RFC 3986:

"...Use of the format "user:password" in the userinfo field is 
deprecated. Applications should not render as clear text any data after 
the first colon (":") character found within a userinfo subcomponent 
unless the data after the colon is the empty string (indicating no 
password). Applications may choose to ignore or reject such data when it 
is received as part of a reference and should reject the storage of such 
data in unencrypted form. The passing of authentication information in 
clear text has proven to be a security risk in almost every case where 
it has been used...." -- 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.2.1.p.1>

RFC 7230:

"The URI generic syntax for authority also includes a deprecated 
userinfo subcomponent ([RFC3986], Section 3.2.1) for including user 
authentication information in the URI. Some implementations make use of 
the userinfo component for internal configuration of authentication 
information, such as within command invocation options, configuration 
files, or bookmark lists, even though such usage might expose a user 
identifier or password. A sender MUST NOT generate the userinfo 
subcomponent (and its "@" delimiter) when an "http" URI reference is 
generated within a message as a request target or header field value. 
Before making use of an "http" URI reference received from an untrusted 
source, a recipient SHOULD parse for userinfo and treat its presence as 
an error; it is likely being used to obscure the authority for the sake 
of phishing attacks." -- 
<http://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.2.7.1.p.8>

Looking at the test results suggests that

a) only the Python implementation is really broken (it probably follows 
RFC 2396 which treated params as a separate component; Firefox had a 
similar problem until a few years ago; but that was fixed by me)

b) IE gets away with treating the presence of userinfo as an error; it 
probably would be a good idea if other UAs followed that example.

Best regards, Julian

v2.23.0 | Report a Bug | By Email