lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: pauls at utdallas.edu (Schmehl, Paul L) Subject: Apparently the practice was prevalent > -----Original Message----- > From: full-disclosure-admin@...ts.netsys.com > [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of > Shawn K. Hall (RA/Security) > Sent: Monday, February 09, 2004 5:35 PM > To: full-disclosure@...ts.netsys.com > Subject: RE: [Full-Disclosure] Apparently the practice was prevalent > > No, it doesn't. It defines the protocol. It imports necessary > values from other specs and recommendations by reference, > like those you quoted below - which, had you actually read > both RFC's you'd see that authority, as defined in 2396 does > include userinfo. Period. As referenced in 2616 3.2.1, it > imports "authority" as defined in 2396 which includes 'userinfo.' > 2396 also includes this: "Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used." And this: "It is clearly unwise to use a URL that contains a password which is intended to be secret. In particular, the use of a password within the 'userinfo' component of a URL is strongly disrecommended except in those rare cases where the 'password' parameter is intended to be public." Which seems to say that the use of user:password@....domain.com is NOT recommended except in rare cases. > > That's not what I said. I said that it was not definitive, > but abbreviated - having most of it's value by reference. 'An > informed reading' of the RFC's would demonstrate how > misguided you are. > This is what 2616 says about http URLS: "The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs. http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (section 5.1.2). The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2). If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy MUST NOT change the host name." What exactly does "defines the *scheme-specific* syntax and semantics" mean? ISTM it means you are allowed to use http: + // + host + abs_path and/or query. No mention of user:password or "authority" here. And this part of 2396 seems to contradict you specifically: " The URI syntax is dependent upon the scheme. In general, absolute URI are written as follows: <scheme>:<scheme-specific-part> An absolute URI contains the name of the scheme being used (<scheme>) followed by a colon (":") and then a string (the <scheme-specific- part>) whose interpretation depends on the scheme. The URI syntax does not require that the scheme-specific-part have any general structure or set of semantics which is common among all URI. However, a subset of URI do share a common syntax for representing hierarchical relationships within the namespace. This "generic URI" syntax consists of a sequence of four main components: <scheme>://<authority><path>?<query>" I read that as saying the scheme-specific part is authoritative for each scheme and cannot be overridden by the generic syntax specified in 2396. Which means that user:password (<authority>) is disallowed for HTTP because it is not specifically allowed within the scheme-specific definition of HTTP URIs given in 2616. Paul Schmehl (pauls@...allas.edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/
Powered by blists - more mailing lists