Earlier quoted context omitted.
So does it intercept all connections on that port (from the client app) and pass them along? Or do I need to reconfigure my client application to talk to localhost:whatever? Your only example is that curl using a hostname, it's not really clear.
You would point the application at the local port. It operates very similarly to SSH port forwarding. No fancy magic to intercept all traffic.
https://github.com/99designs/aws-vault/issues/578 was for an issue with remote servers accessing the localhost ec2 metadata service that aws-vault can run, that worked exactly by using DNS rebinding. It was fixed only months ago, so it seems like this is a developing area and if I were on a red team or pen testing, I would play around with more.
I visualize the "localhost hole" problem of blindly trusting localhost as an air gap in a pipe (like [0]); anybody could come along and either drop poison in the pipe, or redirect the water coming from the top to their own bucket, or both.
I appreciate that Boundary gives completely generic identity-aware-authenticated TCP sockets, but I don't know of a way, today, to make those not accessible to browsers through dns rebinding attacks.
This is probably much much too far in the weeds and this is unlikely to contribute to a major breach (unlike the aws-vault one where of course attackers would try to access the fake metadata service on the default port, because it's high-value and on a well-known port), but I'm interested in the space.
[0] https://news.ycombinator.com/item?id=23265509 [1] https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-...
