🛡️ Sentinel: [HIGH] Fix SSRF in AddExternalSource

[arumes31]

• 🚨 Severity: HIGH
• 💡 Vulnerability: Server-Side Request Forgery (SSRF) in the AddExternalSource API handler (internal/api/excluded_handlers.go). The handler accepted user-provided URLs without validating if they resolved to internal network addresses before persisting them.
• 🎯 Impact: An attacker could potentially bypass firewall rules and access internal services (e.g., local administrative interfaces, databases, internal APIs) by providing a malicious URL (like http://127.0.0.1/) when creating an external source, which the server would then fetch.
• 🔧 Fix: Added a validation step using security.IsSafeURL() in the AddExternalSource handler to verify that the provided URL is safe and does not resolve to internal IP ranges before allowing the external source to be created.
• ✅ Verification: Added a unit test TestAPIHandler_AddExternalSource in internal/api/excluded_handlers_test.go that explicitly verifies both successful safe URL additions and the rejection of unsafe internal URLs with a 400 Bad Request.

---

PR created automatically by Jules for task 12131855462812607939 started by @arumes31

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0952b05a-6679-45ff-b3f8-f70ed9e9e559

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix-ssrf-external-source-12131855462812607939

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[arumes31]

Superseded by #374 — thank you for surfacing this, the vulnerability is real and the fix has landed there.

Keeping the note here for the record: validating the URL in AddExternalSource is a pre-flight check rather than a defense on its own. ExternalSourceService still fetched with a default http.Client, so two vectors remained open:

• DNS rebinding — a host can resolve to a public address at add-time and an internal one at fetch-time.
• Redirects — a perfectly public URL can 302 inward to, say, 169.254.169.254.

Since refresh runs on a schedule, that fires repeatedly rather than once.

#374 keeps your input-time check as defense in depth and adds the missing layer: dialing through security.SafeSocketControl (the guard the webhook path already used), which re-checks the address actually being dialed on every connection including redirects, plus a redirect cap and re-validation of the stored URL on each refresh. It also closes reserved-range gaps in IsInternalIP itself, notably RFC 6598 shared address space (100.64.0.0/10).

[google-labs-jules]

Superseded by #374 — thank you for surfacing this, the vulnerability is real and the fix has landed there.

Keeping the note here for the record: validating the URL in AddExternalSource is a pre-flight check rather than a defense on its own. ExternalSourceService still fetched with a default http.Client, so two vectors remained open:

• DNS rebinding — a host can resolve to a public address at add-time and an internal one at fetch-time.
• Redirects — a perfectly public URL can 302 inward to, say, 169.254.169.254.

Since refresh runs on a schedule, that fires repeatedly rather than once.

#374 keeps your input-time check as defense in depth and adds the missing layer: dialing through security.SafeSocketControl (the guard the webhook path already used), which re-checks the address actually being dialed on every connection including redirects, plus a redirect cap and re-validation of the stored URL on each refresh. It also closes reserved-range gaps in IsInternalIP itself, notably RFC 6598 shared address space (100.64.0.0/10).

Understood. Acknowledging that this work is superseded by #374 and stopping work on this task. Thank you for the detailed explanation regarding the DNS rebinding and redirect vectors; it's a great learning on defense in depth.