5 ms·
This is a good start, but misses two potential problems: - The 172.16.x.x - 172.31.x.x address space, which is another internal-only one. Chances are that you
by Mister_Snuggles 13y ago
This is a good start, but misses two potential problems:
- The 172.16.x.x - 172.31.x.x address space, which is another internal-only one. Chances are that you'll know what your internal addresses look like, but things can change after something is built.
- What about IPv6?
It's really hard to get something right when you only have a blacklist to work with. It's much better to whitelist a few things that are allowed, but then that would limit the utility of Webhooks.
- jkarneges 13y agoOther internal ranges: Agreed. We should probably put a formal list somewhere (maybe on webhooks.org) that all developers can refer to. Of course, there may be times when you do want internal targets to work as well. I want to say the problem should be something that people in charge of operations need to be aware of, and webhook-sending apps need configuration options to specify ranges. Then it's up to the expertise of the operator to make the right decisions. This doesn't feel very satisfactory though. IPv6: Good question. I don't know enough about how it handles address spaces.
- Mister_Snuggles 13y agoFortunately, formally listing all of the internal IP ranges is a solved problem: http://www.ietf.org/rfc/rfc1918.txt http://www.ietf.org/rfc/rfc1918.txt http://www.ietf.org/rfc/rfc4193.txt http://www.ietf.org/rfc/rfc4193.txt I have a feeling that IPv6 is going to be a lot more complex than simply blocking FC00::/7. I seem to recall that one of the benefits of IPv6 was that NAT-ing would be a thing of the past and every system would have a public address.