Hacker News Reader

Comment by jetpks | Hacker News Reader

Why are these in the `should fail' section?

    http://www.foo.bar./
    http://10.1.1.1
    http://10.1.1.254
    http://10.1.1.0
    http://10.1.1.255

The top one is just a fully qualified domain name, and the rest could be valid host addresses depending on your subnet size.

View on HN

The first should be allowed, but I can see why the latter are excluded. If the purpose of this validator is to run against user-submitted URLs, then you wouldn't want to allow users to specify ones to which they don't have authority. Imagine that the program takes the user's input, fetches the item, and the stores it somewhere accessible to them. If the program allowed URLs for internal subnets, then a malicious user could attempt to acquire internal assets!

you can point dns at internal hosts too!

Good point, obviously the better way to mitigate is via proper firewalls so that the application servers don't access arbitrary internal hosts.

> http://3628126748

This shouldn't fail. It resolves to an IP owned by The Coca Cola Corp (not an internal IP)

I'm confused by how that works. I've never seen IP addresses expressed in decimal form before (which is what I'm assuming that is).

An IP address is just a number. Here's a great post on it: http://superuser.com/a/486936

It is in octal actually, and it isn't overly portable.

It should also start with a 0 to be "correct". Which in this case "correct" means the libc inet_aton() function will accept it and convert it to an ip address. The octal portion is nonstandard technically for uri's and is more an artifact of the libc the software you're using is sitting on.

That looks like decimal to me. I didn't convert it to test, but I see a couple 8s. :)

Regardless, there are valid dotless decimal, octal, and hex representations for every IP address. Library support is variable.

I'd argue that it should fail, for any hostname/address validation other than an academic exercise.

It's valid, but the only people who ever use dword IP addresses are pentesters and their less scrupulous analogues. I have no issue disapppointing them.

There are valid dotless (and dotted) octal and hex representations too. They should also fail, I think.

It's valid, therefore it should be marked as such by the regex.

Not so. From TFA:

    I also don’t want to allow every possible technically
    valid URL — quite the opposite.

And dword and octal IP URLs are definitely in the realm of technically valid but practically not.

Regarding the IPs, the article's use-case is listed as a 'public URL shortener', and 10.0.0.0/8 is not on the public address range by definition.

Sure, but it seems like you should in those cases just parse the URL and then reject black-listed host names.

Reply on news.ycombinator.com