RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 7230, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", June 2014

Note: This RFC has been obsoleted by RFC 9110, RFC 9112

Note: This RFC has been updated by RFC 8615

Source of RFC: httpbis (wit)

Errata ID: 5964
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Rick van Rein
Date Reported: 2020-01-23
Held for Document Update by: Barry Leiba
Date Held: 2020-02-05

Section 2.7.1 says:

   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.

It should say:

   The URI generic syntax for authority also includes a
   userinfo subcomponent in which the format "user:password" is deprecated
   ([RFC3986], Section 3.2.1).  The user is permitted, but the password
   is not.  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 a colon in a userinfo subcomponent when an
   "http" URI reference is generated within a message as a request
   target or header field value, but it may prefix a user and an "@" delimiter
   before the host name in an "http" URI.  Before making use of an "http" URI
   reference received from an untrusted source, a recipient SHOULD parse
   for userinfo and treat the presence of a colon in it as an error.

Notes:

RFC3986 does not forbid or even discourage the "user" in the userinfo subcomponent. It only says

Use of the format "user:password" in the userinfo field is
deprecated.

and continues to describe ":password" handling.

Obscuring the authority for the purposes of phishing is not mitigated by parsing the userinfo; subdomains in DNS offer similar notational flexibility. Parsing does help against misleading password popups.

The user is part of the authority section of the URI and its purpose is to zoom in on a scope for authoritative resource addressing. This syntax has in the past been (ab)used for Basic/Digest authentication details, which only works if visitor and visited resource happen to be the same user; it is this (ab)use that is now deprecated.

===========================
Verifier notes:
This is not really an erratum, as the document says exactly what it was intended to say when it was written. That said, the issue does need to be discussed as the document is updated, and an update is planned... so I'm marking it "Held for Document Update", rather than "Rejected".

Report New Errata



Advanced Search