Hacker News Reader

Comment by chunk_waffle | Hacker News Reader

For a server sending webhooks to endpoints entered in by users, take care that:

a: The FQDN does not resolve to an RFC1918 address (You don't want to be POSTing payloads to endpoints within your internal network.)

b: If you respond to redirect responses (easier to just not do so for other reasons as well) also make sure those don't resolve to internal addresses too!

View on HN

The attacker-controlled DNS record pointing to an internal private address or an explicit redirect is a classic, especially if they can control the event template being used and the service relies entirely on edge filtering... Too much template control is a risk.

I mean, there's a lot of things you should do when dealing with this that most people don't pay attention to:

https://datatracker.ietf.org/doc/html/rfc2606 https://datatracker.ietf.org/doc/html/rfc3927 https://datatracker.ietf.org/doc/html/rfc4193 https://datatracker.ietf.org/doc/html/rfc6761

... and so on. At least in Go some of the handy checks are simplified by IP.Is(Private|Loopback|Multicast|InterfaceLocalMulticast()|LinkLocal*etc.)

It's been years since I've looked into this problem but to tackle it properly one shouldn't just resolve the domain and check that the IP is acceptable. The HTTP client library needs to be involved by providing a way to run code just before creating the socket, which very few do.

Oh interesting... would love to hear more about that. I guess what could happen is:

You would:

1. Resolve the FQDN

2. check the IP

3. Make the request

When the request is actually made, the FQDN is resolved again and a different IP is returned?

Reply on news.ycombinator.com