Someone told me that showing your IP address in a URL (like
http://192.0.2.34/default.html) is easier to hack. Is that true? I could trace any domain name and get its IP number as well.
Easier to hack? No. Easier to DoS? Potentially. Using an IP address instead of a host name with a DNS entry means you're giving up a layer of routing flexibility that can be very beneficial.
For example, if malware targets your IP address in a DoS attack, if you're using a domain name, you switch the IP address of the site and in the DNS record, and the attack is over without your users knowing the difference. If your users are making requests directly to your IP, however, that isn't an option. You're tied to that IP unless you want to inconvenience (and possibly lose) your users along the way.
Typically if your site is accessible as
http://18.104.22.168/ that would imply that it is not enforcing any limitations on the
Host: header. That would mean that you could access it not just through IP address, but any hostname that happened to resolve to that address - including a domain an attacker registered and pointed at it.
This opens up DNS rebinding attacks, where an attacker circumvents Same-Origin-Policy by switching the IP address of a hostname between their own server and yours, and cookie attacks where they point
attacker.com to your service and then
sub.attacker.com to their own, allowing the cookie to be read from the subdomain.
Quite how much of a risk those are depends on the design and purpose of your application. It's most likely to be exploitable on non-public applications, where you have implicit authorisation based on private IP address range or SSO (Windows auth et al); in that case an application might produce sensitive data without user interaction, and that data could become visible to such an attacker.
Without knowing that, the safest route is to put limitations on what the
Host: header can contain for HTTP requests. That usually means setting up host-based virtual servers and allowing only known-good hostnames to hit your web apps, in which case attacker hostnames and direct-to-IP-address access alike would hit an error page.
But you could certainly come up with a custom check that permitted only an IP address and not any other hostname, if you really wanted - so no, it's not the IP address that's a problem in itself.
And/or just use HTTPS, which offers more watertight assurance that you're hitting the right server.
Contrary to the other answers, I consider that using ip-addresses instead of hostnames is bad practice for a number of reasons. Most notably:
It is considerable harder for average users to verify that they are talking with the correct service and not with a phishing site: They have to remember a large number instead of a name.
Using ip-adresses implies that you cannot use https with a valid certificate.
IP-addresses may be reassigned for a number of reasons, and not all of them are under your control. Thus someone else may get your current ip-address.
A common way to handle huge amounts of traffic (e. g. a DDoS attack) is to point the dns entry to a huge distributed caching network. By using an ip-address you are ruling out this effective and relatively inexpensive option.
Using the IP address instead of the domain is not a security bad practice, as an attacker could get it trivially.
A simple terminal command like
nslookup can check for any IP address resolved by the given domain. Furthermore, if the domain is connected to a single IP address,
ping does the job just as well.
Giving your [web site's] address one way or the other doesn't make it any more "hackable" then it already might be.
It can't be a security concern because everyone can find out the domain IP address.
for example check this out: ip-lookup
Along with the good reasons that bobince mentioned, there is also that you cannot create a properly trusted SSL/TLS certificate for a site that doesn't use a DNS domain name. Thus making all browsers trying to connect to your HTTPS:// version of your IP addressed site complain that they cannot trust it.