fix(security): resolve profile update validation bypass and SSRF

[prince-shakyaa]

fix(security): resolve profile update validation bypass and SSRF via insecure avatar URLs

Description

Fixes #506
This Pull Request resolves a high-severity security vulnerability in the user profile and sharing module.

The Problem

Previously, the ProfileUpdateRequest allowed updating fields optionally. The route only validated that the avatar_url started with https:// if avatar_type was explicitly set to "url" in the current request payload:

if request.avatar_type == "url" and request.avatar_url:
    ...

If a user's profile already had avatar_type = "url" in the database, they could bypass this security check by sending a PUT request containing only avatar_url (omitting avatar_type entirely). The backend successfully saved the insecure URL (e.g. http://127.0.0.1:8500/ or http://169.254.169.254/).

When generating the profile sharing card (/share/profile/{username}/card.png), the backend issued an asynchronous httpx.get request directly to this user-supplied insecure URL to fetch and base64-encode the image. This resulted in a Server-Side Request Forgery (SSRF) vulnerability, enabling attackers to scan local ports, query intranet systems, or access cloud metadata services.

Furthermore, even if https:// was enforced, an attacker could use https://127.0.0.1 or set up a public server that redirects (302 Found) back to a local IP address.

The Fix

This PR introduces a robust defense-in-depth mitigation:

1. Validation Bypass Fix: The update_profile route validation now computes the effective_avatar_type and effective_avatar_url (taking the incoming request's type, or falling back to the existing profile's saved type in the database if omitted).
2. DNS/IP Blocklisting (Layer 1): Instead of just enforcing https://, the effective URL is passed to is_ssrf_safe. This resolves the hostname and blocks any IP in local, link-local, or private RFC-1918 subnets.
3. Disable Redirects (Layer 2): To prevent redirect-based SSRF, the httpx.AsyncClient that fetches the avatar in share.py is now configured with follow_redirects=False.

---

Key Changes

• Modified: finbot/apps/ctf/routes/profile.py
  • Computed effective avatar fields to fix the validation bypass.
  • Implemented is_ssrf_safe using socket and ipaddress to strictly block private subnets.
• Modified: finbot/apps/ctf/routes/share.py
  • Set follow_redirects=False to neutralize redirect-based SSRF.

---

Verification & Testing

Manual Verification

1. Created a user profile and set the avatar type to url.
2. Attempted to bypass validation by omitting avatar_type while setting avatar_url to http://127.0.0.1. Blocked (400 Bad Request).
3. Attempted to supply a "secure" local URL like https://127.0.0.1 or https://169.254.169.254. Blocked (400 Bad Request).
4. Attempted to use a public URL that redirects to a local port. Card generation fails safely as httpx refuses to follow the redirect.

[prince-shakyaa]

Hi @saikishu @e2hln ,
Fixed a validation bypass in profile.py where omitting avatar_type in a profile update request skipped the HTTPS check on avatar_url, allowing insecure HTTP URLs to be saved and triggering blind SSRF via the profile share card endpoint. The fix resolves this by checking the effective avatar type from both the request and the existing database profile before validating the URL. Added 4 unit tests covering the bypass and edge cases.
Thank You.