fix: add SSRF protection and enable TLS verification in URI source

[Joshua-Medvinsky]

Problem

The URI data source passes user-controlled URLs directly to requests.head() and requests.get() with verify=False, enabling SSRF attacks against internal services and cloud metadata endpoints, as well as MITM attacks on outbound connections.

Fix

1. Add _is_private_url() validation function that blocks URLs pointing to private/internal IP ranges (RFC 1918, loopback, link-local, reserved) and known metadata hostnames.
2. Change verify=False to verify=True in get_url_content_type().
3. Raise ValueError when a private URL is detected.

Test Plan

• Existing test suite passes
• URLs with private IPs (127.0.0.1, 10.x.x.x, 169.254.169.254) are rejected
• Public URLs (https://example.com) still work correctly
• TLS verification is enforced on all outbound requests

Security Note

Severity: High — SSRF allows access to internal services and cloud metadata (AWS/GCP/Azure credentials). Disabled TLS verification enables MITM attacks.

[vercel]

Someone is attempting to deploy a commit to the LLMStack Team on Vercel.

A member of the Team first needs to authorize it.

[failsafesecurity]

Hi! Friendly follow-up on this security fix. Happy to adjust the approach if you have concerns about backwards compatibility, tests, or scope. If you'd prefer a different disclosure channel such as private vulnerability reporting or a security contact, I can resubmit there.

[failsafesecurity]

Hi - friendly follow-up on this security fix PR. Happy to rebase, split the change, or adjust the approach if there are compatibility or scope concerns. If you prefer a private channel for security reports, I can also resubmit via PVRA/security@.

[failsafesecurity]

Hi! Friendly follow-up on this security fix. Happy to adjust the approach if you have concerns about backwards compatibility, tests, or scope. If you'd prefer a different disclosure channel such as private vulnerability reporting or a security contact, I can resubmit there.