According to the URL syntax there are supposed to be slashes after the colon following the protocol. An email link, e.g.
mailto:bla#shoe.com
, however, does not contain these slashes.
Can these addresses be considered valid URLs ?
The URI standard is STD 66 which currently maps to RFC 3986.
The double slash you know from some URIs (e.g., from HTTP URIs like http://example.com/) precedes the authority component, but this authority component is not required by the generic URI syntax (only scheme and path are).
So, the mailto URI scheme is not using the authority component, and therefore there is no // after the scheme component.
Related
An e-mail address is a valid URI when encoded using the mailto scheme:
mailto:user#example.com
(See RFC 6068)
But how should that be parsed according to RFC 3986, the standard for Uniform Resource Identifier (URI): Generic Syntax?
Is the user name part of the e-mail address (user of mailto:user#example.com) the user name of the user info part?
Is the host-name part of the e-mail address (example.com of mailto:user#example.com) the host part?
Despite an e-mail address containing a user name and a host name, when encoded in a mailto URI, the e-mail address constitutes part of the path of the URI, and the user part and host part are considered empty. This is because the user, password (if it was present) and host would constitute the authority part of the URI, which must be preceded by "//".
That is, if the 'mailto' URI scheme had mandated mailto://user#example.com rather than mailto:user#example.com, the parsing would be as expected. A 'mailto' is thus, rather strangely, a URN.
I recently received an email containing the following chunk (don't click!):
<A HrEf="/#/0X0a290d92b/UALI=28389-UI=176738575-OI=279-ONI=5477-SI=0-CI=0-BI=577-II=27913-IDSP=1-KLEM=11-TIE=A-IDE=276135-MID=572-FID=0-DIOM=0" sTyLe=color:#000;font-size:10px;font-family:arial;>
<span>UNS</span></a>
Here is a link to the raw email: https://gist.github.com/anonymous/16963a230cab0a3a1bcfc81209f297f1
As far as I know, /# is not a valid url. How is my browser able to resolve it to a site?
As it was already mentioned in comments # is allowed in URL paths.
Regarding URL resolving. I guess that attacker uses <base> tag to explicitly set default URL for all relative links in email body and hopes that your browser/email client will resolve it for you.
UPDATE
The original guess might be correct since it is not supported by majority of mail clients
After a bit of investigation I realized that 0x0A290D92B is actually is hex-encoded IPv4 address 162.144.217.43. The only thing which I do not yet understood is how it is supposed to be transformed to http(s)://0x0A290D92B in browser. It seems like the attacker is targeting specific browser/mail client behavior.
It's treating everything before the # as auth information that gets passed to the URL. The "real" url starts after the #, which is the encoded IP address that vsminkov mentioned. So the leading forward slash is discarded.
An easier to read example: http://username:password#example.com/
It's all just layers of obfuscation.
Here's an interesting link that goes over it in more detail:
http://www.pc-help.org/obscure.htm
and here's RFC 2396 describing that part of the URL:
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 may consist of a user name and, optionally, scheme-
specific information about how to gain authorization to access the
server. The parts "#" and ":" may be omitted.
server = [ [ userinfo "#" ] hostport ]
The user information, if present, is followed by a commercial at-sign
"#".
userinfo = *( unreserved | escaped |
";" | ":" | "&" | "=" | "+" | "$" | "," )
Should parameters for POST requests (elements of the resource being created) be allowed to be added to the URL as well as in the body?
For example, let say I have a POST to create a new user at
/user
With the full set of parameters name, email, etc... in the body of the request.
However, I've seen many API's would accept the values in either the body or URL parameters like this:
/user?name=foo&email=foo#bar.com
Is there any reason this second option, allowing the parameters in the URL is bad practice? Does it violate any component of REST?
The intent of a query parameter is to help identify the target resource for a request. The body of a POST should be used to specify instructions to the server.
The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a
resource within the scope of the URI's scheme and naming authority
(if any).
-- RFC 3986 Section 3.4
The hierarchical path component and optional query component serve
as an identifier for a potential target resource within that origin
server's name space.
-- RFC 7230 Section 2.7.1
The Udacity Web Development course, be Steve Huffman (the man behind Reddit), recommends only using POST requests to update server side data. Steve highlights why using GET parameters to do so can be problematic.
Trying to consume the URI cot.ag/o1LnfW from .NET with the HttpWebRequest, I get the 301 Moved response, the response header Location has a (incorrect) value of:
http://www.joycemeyer.org/BroadcastHome.aspx?video=Living_Beyond_Your_Feelings_â_Pt_1&utm_source=Twitter&utm_campaign=EEL&utm_medium=post&utm_term=September29&utm_content=post
From Fiddler, I get the (correct) Location header value:
http://www.joycemeyer.org/BroadcastHome.aspx?video=Living_Beyond_Your_Feelings_–_Pt_1&utm_source=Twitter&utm_campaign=EEL&utm_medium=post&utm_term=September29&utm_content=post
Noted the difference where the – occurs in the Fiddler URL. In the case of Fiddler, the bytes are E2 80 93. In the case of .Net, the bytes are E2 3F 3F. This results in an incorrect header interpretation, with subsequent failure to follow the redirection.
I think this is a .NET framework bug, but I have no idea what the RFCs say it SHOULD sent as. Should I report this as a bug to Microsoft, or is this a failure by bit.ly in serving the headers in the wrong code-page?
RFC 2616 specifies that the Location header should contain a URI as defined by RFC 1630, which requires a URI be 7-bit clean ASCII with any special characters URL encoded.
In other words, the server is delivering the URI incorrectly and should be escaping it.
I've reported this a bug over at bit.ly's support forum. They should be responding with a legal RFC 1630 URI in the ASCII character set (no octets with the high-bit set).
Say you have a mapserver-url like this: http://host/cgi-bin/mapserv?MAP=/path/to/mapfile.map&
Is a WMS specified in this way conform to the OGC WMS-specification? Some say the map-parameter is a vendor-specific parameter, but you also could see it as part of the URL-prefix for this service (ending with ? or & as specified, it's an & in this case). What do you think, is that compatible to the specification or not?
The OGC WMS 1.1.1 (Section 6.2.2)and 1.3.0 (Section 6.3.3) specifications are fairly clear regarding this topic:
An Online Resource URL intended for
HTTP GET requests is in fact only a
URL prefix to which additional
parameters are appended in order to
construct a valid Operation request. A
URL prefix is defined in accordance
with IETF RFC 2396 as a string
including, in order, the scheme
(“http” or “https”), Internet Protocol
hostname or numeric address, optional
port number, path, mandatory question
mark “?”, and optional string
comprising one or more server-specific
parameters ending in an ampersand
“&”.
As long as the online resource URL finishes with an "&", it should adhere to the WMS specification