full-disclosure - Phishing scam - Obfuscated url help please

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Phishing scam - Obfuscated url help please

Valdis.Kletnieks@...edu responded to my earlier post:

> > as the "@" is (incorrectly) interpreted by many browsers (most in terms 
> > of absolute use) as indicating the username part of the "userinfo" part 
> > of the generic URI scheme.  
> 
> RFC2396 - Uniform Resource Identifiers (URI): Generic Syntax
> 
> 3.2.2. Server-based Naming Authority
> 
>    URL schemes that involve the direct use of an IP-based protocol to a
>    specified server on the Internet use a common syntax for the server
>    component of the URI's scheme-specific data:
> 
>       <userinfo>@<host>:<port>
> 
>    where <userinfo> may consist of a user name and, optionally, scheme-
>    specific information about how to gain authorization to access the
>    server.  The parts "<userinfo>@" and ":<port>" may be omitted.
> 
>       server        = [ [ userinfo "@" ] hostport ]
> 
>    The user information, if present, is followed by a commercial at-sign
>    "@".
> 
>       userinfo      = *( unreserved | escaped |
>                          ";" | ":" | "&" | "=" | "+" | "$" | "," )
> 
>    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.
> 
> Looks like a correct interpretation to me.

It's a correct interpretation of the generic URI syntax, yes.  However, 
what I said was:

   as the "@" is (incorrectly) interpreted by many browsers (most in
   terms of absolute use) as indicating the username part of the
   "userinfo" part of the generic URI scheme.  Although userinfo is
   specifically not part  of the HTTP protocol, it is still commonly
   "understood" by many browsers.

Thus, without egregiously trimming off a part of what I wrote that adds 
significant meaning to the whole message, the fair-minded reader will 
comprehend that the "incorrectly" above meant "incorrect in terms of 
the URI being an HTTP URL".  This is precisely the point Bill Royds 
made in correcting one of my contributions to the "Internet Explorer 
URL parsing vulnerability" thread back in mid-December; a contribution 
that was very similar to Valdis' suggestion here (sorry, URL will 
wrap):

http://lists.netsys.com/pipermail/full-disclosure/2003-
December/014816.html

So, although the generic syntax of URIs allows for the 
"<username>[:<password>]@" form of userinfo, it also allows scheme-
specific syntaxes to the specify which components are valid for that 
scheme.  The HTTP URL syntax does not allow for the  userinfo part; RFC 
2616, "Hypertext Transfer Protocol -- HTTP/1.1":

   3.2.2 http URL

   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.

RFC 2616 defers to RFC 2396 for its definition of "host" above.  As 
that is a component part of the "hostport" referred to in Valdis' 
extract from RFC 2396, it does not include any reference to a 
"userinfo" or similar construct.  Thus, HTTP URLs, _by definition_ do 
not contain the (option of) a user validation component, just as I said 
(though I wrote it quickly and could have more carefully phrased it had 
I had the time...).

Regards,

Nick FitzGerald