Hardening: block SSRF to internal ranges on user-configured webhook/notification URLs

Background

WebHookAlertNotifyHandlerImpl.send (hertzbeat-alerter/.../WebHookAlertNotifyHandlerImpl.java:42-72) issues a server-side POST to a user-supplied hookUrl (e.g. via POST /api/notice/receiver/send-test-msg) after only a non-blank check — no scheme or address filtering, and the outbound auth header is caller-controlled. The same pattern applies to other user-configurable webhook base URLs (Ntfy/Gotify).

I reported this privately to the ASF security team. They assessed it as within the documented trusted-user model (a URL configured by a highly-trusted user), so it is not a vulnerability, and suggested filing here as hardening.

Suggested hardening

• Before sending, resolve the host and reject loopback / link-local (169.254.0.0/16, fe80::/10) / RFC-1918 / ULA addresses — check the resolved IP, and re-check on redirects.
• Restrict the scheme to http/https.
• Apply the same guard to the other user-set webhook base URLs.

Happy to send a PR.