Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fun with IP address parsing

blog.dave.tf

Post reply on HN
Print view View original

91–100 of 150 posts

Re: Fun with IP address parsing

#91

Post by j1elo »

anderskaseorg wrote: post #85
j1elo wrote: post #81

> It does not process Class A/B notation, or hex or octal notation. I got to find that notation useful once , to make a shorter one-liner... without even knowing that there were different classes of IPv4 address, and that I was looking at one of them. It's a tiny function that gives me the IP address of my machine in the LAN, for either Linux and Mac: # Get main local IP address from the default external route (Inter…

Did you really gain anything here, given that the omission of those 12 characters required a 38 character comment to explain what’s going on?

Absolutely no :)

What I wanted to express here (and did badly) is that crossing paths with this arcane Class-A style IP address is something so strange nowadays... in my case in more than 10 years professionally working as a developer, I had seen it exactly once and even then, didn't recognize it for what it was.

The code snippet was just an extra curiosity in case anyone found it useful.

Re: Fun with IP address parsing

#92

Post by octoberfranklin »

icedchai wrote: post #87
the_mitsuhiko wrote: post #52

Earlier quoted context omitted.

Since there is no NAT in an IPv6 deployment unsafe services you typically want to prevent access to look like non internal ranges. Whereas in your normal IPv4 deployment you might have your protected service on 192.168.4.111 with IPv6 it will just share the same prefix (potentially) as your host.

NAT was meant to work around IP exhaustion issues, not act as a security layer. By accident, it often happens to provide some additional security. By keep in mind those "internal" IP addresses may be routable in some cases, due to either accidental or deliberate mis-configuration. IPv6, with end-to-end connectivity, is how the Internet is supposed to work. It's how it did work in the early 90's, even with IPv4. If yo…

> IPv6, ..., is how the Internet is supposed to work

No, the way the Internet is supposed to work is that you have one routable address space. If you need to expand it, the previous address space is imported as a subset of the new one.

https://cr.yp.to/djbdns/ipv6mess.html

I will never forgive the IPv6 for not making the 32-bit IPv4 space a subrange of the 128-bit IPv6 space. Years after winning the IPng wars they admitted their mistake and standardized NAT64, but it was too late. NAT64 should have been part of IPv6 from day one, and every IPv6 router acting as a default route gateway should have been mandatorily-required to offer NAT64.

Re: Fun with IP address parsing

#93

Post by namanyayg »

geoffpado wrote: post #46

> This is the same IP address: 3232271615. You get that by interpreting the 4 bytes of the IP address as a big-endian unsigned 32-bit integer, and print that. This leads to a classic parlor trick: if you try to visit http://3232271615 , Chrome will load http://192.168.140.255 . This was the source of one of my favorite “bugs” ever. I was working on multiple mobile apps for a company, and they had a deep link setup th…

Funny bug :) I often prefix integers with a char, e.g. maybe "u12345" here, in places where I'm using integers as id to force a string conversion and avoid any code accidentally doing math on it.

Re: Fun with IP address parsing

#94

Post by octoberfranklin »

chungy wrote: post #19

> I’m on the fence about that last one, the “IPv6 with an embedded dotted decimal” form. My reference parser (Go’s net.ParseIP) understands it, but it’s not really that useful any more in the real world. At the dawn of IPv6, the idea was that you could upgrade an address to IPv6 by prepending a pair of colons, as in ::1.2.3.4, but modern transition mechanisms no longer offer anything as clear-cut as this, so the nota…

> At the dawn of IPv6, the idea was that you could upgrade an address to IPv6 by prepending a pair of colons, as in ::1.2.3.4

No, IPv6 explicitly rejected that idea at first. Most of the other IPng proposals did have a backwards compatibility mechanism like that. I'm still sore that the least backwards-compatible proposal was the one that won.

Later the IPv6 cabal admitted their mistake and published NAT64, but at that point it was too late to make it a mandatory required service offered by any default-route router. So now we have all of this crap about dual-stack hosts instead of simply being able to upgrade to IPv6 and trust that you will not lose any connectivity.

This is basically why, twenty years after it was standardized, IPv6 is still merely the "internet of cellphones" and no closer to replacing IPv4.

As usual, DJB saw all of this decades ahead of time:

https://cr.yp.to/djbdns/ipv6mess.html

Re: Fun with IP address parsing

#95

Post by dave_universetf »

j1elo wrote: post #81

> It does not process Class A/B notation, or hex or octal notation. I got to find that notation useful once , to make a shorter one-liner... without even knowing that there were different classes of IPv4 address, and that I was looking at one of them. It's a tiny function that gives me the IP address of my machine in the LAN, for either Linux and Mac: # Get main local IP address from the default external route (Inter…

Oh no, that's another shorthand that's different from all the others. A single number should be interpreted as a big-endian uint32, and so "1" should be "0.0.0.1". However, I can confirm that `ip` interprets it as "1.0.0.0", even though you should have to write "1.0" for that.

Ugh.

Re: Fun with IP address parsing

#96

Post by stevekemp »

arkadiyt wrote: post #17

These different representations also lead to frequent server side request forgery (SSRF) bypasses - someone might be blocking local IPv4 but you can still access their AWS metadata endpoint at ::ffff:169.254.169.254, etc. For anyone using Ruby, I'm the author of a gem [1] that comprehensively protects against SSRF bugs. For anyone using Golang I recommend this [2] blog post. [1]: https://github.com/arkadiyt/ssrf_filt…

For golang I wrote this:

https://github.com/skx/remotehttp

I've found, and reported, a whole bunch of services which take user-supplied URLs and don't filter out access to localhost:8080/server-status, and similar local resources.

A common route to attacking these is to access the AWS metadata URL endpoint. Something at least the Google cloud prevents, by forcing the use of the `Metadata-Flavor: Google` header.

Re: Fun with IP address parsing

#97

Post by geoffpado »

akoncius wrote: post #84
geoffpado wrote: post #46

> This is the same IP address: 3232271615. You get that by interpreting the 4 bytes of the IP address as a big-endian unsigned 32-bit integer, and print that. This leads to a classic parlor trick: if you try to visit http://3232271615 , Chrome will load http://192.168.140.255 . This was the source of one of my favorite “bugs” ever. I was working on multiple mobile apps for a company, and they had a deep link setup th…

I love those kind of stories. it shows on how high-level abstraction we are working on a daily basis when we have no clue what is going on with stuff which we are touching constantly. I bet it was not “I love it” sentiment when you had to debug this kind of issue though, haha :)

Any bug you can learn something from is better than the alternative. :)

Thankfully, I caught this one while building the feature in the first place; I don’t imagine I’d have such fond memories of it if I’d had to recreate it from user reports!

Re: Fun with IP address parsing

#98

Post by slim »

geoffpado wrote: post #46

> This is the same IP address: 3232271615. You get that by interpreting the 4 bytes of the IP address as a big-endian unsigned 32-bit integer, and print that. This leads to a classic parlor trick: if you try to visit http://3232271615 , Chrome will load http://192.168.140.255 . This was the source of one of my favorite “bugs” ever. I was working on multiple mobile apps for a company, and they had a deep link setup th…

maybe it was more appropriate to use a urn instead of a uri. something like urn:namespace:id:scheme:number

https://tools.ietf.org/html/rfc8141

Re: Fun with IP address parsing

#99

Post by bigiain »

lrossi wrote: post #55

Can confirm that visiting http://127.1 on ipad indeed works and redirects to http://127.0.0.1 . This is very surprising and, at least for me, humbling. I think I will quote this article any time I see someone using regex to validate or parse IPs.

... now you've got two^h^h^hthree problems.

Re: Fun with IP address parsing

#100

Post by jweather »

I spent hours debugging an issue that boiled down to an IPV4 parser that treated leading zeroes as octal. Connections to 192.168.123.100 worked as expected. Connections to 192.168.123.034 went to 192.168.123.28. I thought sure it was an issue in my TCP client code, which was handling connections to hundreds of different devices.

Guilty party was Poco::Net library if I recall correctly. I can maybe see this making sense if you provide four octal digits (0377), but not three, and I have a hard time believing anybody has ever used this on purpose.

Post reply on HN