The ip 0 is the simplest alias I've found to localhost, and most browsers can open the page http://0/ without problem.
When trying the same on Chrome, it always redirect me to the search page.. like it does not recognize that 0, 0:80, 127.1, o 127.1:80 are valid IPs -- although it ask if you meant 0.0.0.0 or 127.0.0.1
Chrome can, however, open the page http://0.0.0.0 correctly
Every HTTP URL consists of the following, in the given order. Several schemes other than HTTP also share this general format, with some variation.
the scheme name (commonly called protocol, although not every URL scheme is a protocol, e.g. mailto is not a protocol);
a colon, two slashes;
a host, normally given as a domain name but sometimes as a literal IP address;
optionally a colon followed by a port number;
the full path of the resource;
The scheme says how to connect, the host specifies where to connect, and the remainder specifies what to ask for.
For programs such as Common Gateway Interface (CGI) scripts, this is followed by a query string and an optional fragment identifier.
The syntax is:
scheme://domain:port/path?query_string#fragment_id
So basically http is valid scheme, :// are valid colon and two slashes, but 0 is not valid domain name or IP address. However, the http://0.0.0.0 are valid scheme and literal IP address, that's why Google Chrome opens it.
The domain name or literal numeric IP address gives the destination location for the URL. A literal numeric IPv6 address may be given, but must be enclosed in [ ] e.g. [db8:0cec::99:123a]
The fact that other browsers "convert" http://0/ into localhost or 127.x.x.x is just browser implementation, it is not by the standard.
More details:
IETF and IETF
Wikipedia
Related
I have two questions about SMTP RFC:
What value should I pass as the argument for the EHLO command if I don't have my own domain name?
The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
I don't really undesrstand Section 4.1.3. Can you give me an example or rephrase it?
Which headers are required to send in the DATA section?
Thanks in advance.
Argument to EHLO in the absence of a domain name
Section 4.1.3 Address Literals of RFC 2821 says:
Sometimes a host is not known to the domain name system and
communication (and, in particular, communication to report and repair
the error) is blocked. To bypass this barrier a special literal form
of the address is allowed as an alternative to a domain name. For
IPv4 addresses, this form uses four small decimal integers separated
by dots and enclosed by brackets such as [123.255.37.2], which
indicates an (IPv4) Internet Address in sequence-of-octets form.
so a simple EHLO [123.255.37.2] suffices (with the actual IP address of your SMTP server of course). Or it could be a properly formatted IPv6 instead.
Required headers
Section 3.6. Field definitions of RFC 2822 says:
The only required header fields are the origination date field and
the originator address field(s). All other header fields are
syntactically optional.
so only From: and Date: are required.
If you don't have a domain name, you should use your IP address:
EHLO [192.168.1.1]
It's kind of a ridiculous requirement in the protocol seeing as how there's no real value in this piece of information. The server shouldn't trust it (obviously) and it is trivial for the server to get the IP address of the connecting client, anyway.
I noticed in webpages such as Google maps there is an # in the URL. What does it do? For example https://www.google.com/maps/place/Vancouver+City+Hall/#49.260404,-123.113799,3a,75y,349.48h,90t/data=!3m4!1e1!3m2!1sUeoHwwwaQPVvyH1amrQAAQ!2e0!4m9!1m6!2m5!1sgoogle+maps+vancouver+city+hall!3m3!1scity+hall!2sVancouver,+BC,+Canada!3s0x548673f143a94fb3:0xbb9196ea9b81f38b!3m1!1s0x548673e7b8d4609d:0x9823432c0c571e10!6m1!1e1
An URL in general is not consistenly consisting of directories followed by a file. Before it eventually beeing a physical directory+path, it's just a string, not more, not less. There is only 1 real special character in URL that is not part of this URI string: # (Hash fragment identifier).
Basically you can map any string after //yourdomain.com/ (and before #) to anything you want.
Therefore, the # character in the URL only has cosmetical/optical/ however you call it meaning.
The ? and & have a special meaning in terms of, the server can use these symbols to identify parameters. But it does not have to do so. It is in fact possible to map an URI like //yourdomain.com/&&& to a complete different resource than //yourdomain.com/&&.
As with any user supplied data, the URLs will need to be escaped and filtered appropriately to avoid all sorts of exploits. I want to be able to
Put user supplied URLs in href attributes. (Bonus points if I don't get screwed if I forget to write the quotes)
...
Forbid malicious URLs such as javascript: stuff or links to evil domain names.
Allow some leeway for the users. I don't want to raise an error just because they forgot to add an http:// or something like that.
Unfortunately, I can't find any "canonical" solution to this sort of problem. The only thing I could find as inspiration is the encodeURI function from Javascript but that doesn't help with my second point since it just does a simple URL parameter encoding but leaving alone special characters such as : and /.
OWASP provides a list of regular expressions for validating user input, one of which is used for validating URLs. This is as close as you're going to get to a language-neutral, canonical solution.
More likely you'll rely on the URL parsing library of the programming language in use. Or, use a URL parsing regex.
The workflow would be something like:
Verify the supplied string is a well-formed URL.
Provide a default protocol such as http: when no protocol is specified.
Maintain a whitelist of acceptable protocols (http:, https:, ftp:, mailto:, etc.)
The whitelist will be application-specific. For an address-book app the mailto: protocol would be indispensable. It's hard to imagine a use case for the javascript: and data: protocols.
Enforce a maximum URL length - ensures cross-browser URLs and prevents attackers from polluting the page with megabyte-length strings. With any luck your URL-parsing library will do this for you.
Encode a URL string for the usage context. (Escaped for HTML output, escaped for use in an SQL query, etc.).
Forbid malicious URLs such as javascript: stuff or links or evil domain names.
You can utilize the Google Safe Browsing API to check a domain for spyware, spam or other "evilness".
For the first point, regular attribute encoding works just fine. (escape characters into HTML entities. escaping quotes, the ampersand and brackets is OK if attributes are guaranteed to be quotes. Escaping other alphanumeric characters will make the attribute safe if its accidentally unquoted.
The second point is vague and depends on what you want to do. Just remember to use a whitelist approach instead of a blacklist one its possible to use html entity encoding and other tricks to get around most simple blacklists.
Scenario is this:
Parent.com can have a 'html only' file
and it has iframe with Iframe.com (php that i have full \controll ).
Question is this:
How can i check if iframe.com is loaded only by parent and cant be iframed by other domains
EDIT: Some solution suggest checking Referrer but this can be spoofed.
referer is as close as you can get before getting into really complicated territory.
While it can be spoofed, it can only be spoofed by the client. A third party website couldn't make the client spoof it.
That said, referer is optional. Browsers don't have to send it, and they tend not to under quite a lot of circumstances (such as when the referring document was served over HTTPS).
The following might work…
iframe.example.com uses server side code to request a token from framed.example.net, the request includes the ip address of the browser and a password authorising iframe.example.com to frame framed.example.net
framed.example.net generates a token and gives it to iframe.example.com, registering it against the ip address of the browser
iframe.example.com generates a URI with the token in the query string and uses it as the src to the iframe
framed.example.net checks that the token exists and the ip address in the record matches the ip address the request came from (the browser)
This will generate false negatives when the browser doesn't have a consistent ip address (such as when behind a group of proxy servers, which I seem to recall is quite common in cellular broadband), so I wouldn't recommend it.
X509v3 can contain IP address field in subject Alternative Name extension.
As an application verifying the server's identity, how should the IP address field be validated?
If both DNS name and IP address are present? Is there a preference of one over the another?
What is the use of dirName field?
I read RFC 2818 earlier but must have missed this part.
In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.
My answer is based on my experience with TLS/SSL.
It's based upon the implementation of the certificate validation. To enforce IP address match, you have to implement that.
Whatever way you want. You could also check both.
Sorry no idea what this field does.
Have you checked the OpenSSL documentation?