mirror of
https://github.com/TheFunny/TelegramTwitterMediaBot.git
synced 2026-09-23 23:32:05 +00:00
The media URLs the bot fetches come from a site's own API response (media URLs, `fallback_url`, thumbnails), `build_client` left reqwest's default redirect policy in place (up to 10 hops, any host), and the downloaded bytes are uploaded to Telegram — so a response pointing at a cloud metadata endpoint would read it back into a chat. `media_request` is now the one choke point both download paths go through: http(s) only, and a host that is no address or name of the host's own network (`blocked_ip` covers loopback, private, link-local, unspecified, broadcast, documentation, multicast, IPv6 unique-local/link-local, IPv4-mapped, plus CGA-NAT and benchmarking ranges; `is_local_name` covers `localhost` and `*.local`). A refusal is `FetchError::Blocked` — permanent, so the send path does not retry a URL that would be refused again (a connection error used to be retryable and burned attempts). The same guard runs on every redirect hop through a custom redirect policy, keeping reqwest's 10-hop cap. Deliberate gap, documented at the function: DNS rebinding (a name the site controls resolving to a private address) needs a `reqwest::dns::Resolve` wrapper, which would also resolve the operator's own proxy host — and `TELOXIDE_PROXY` is routinely a LAN address — so it would take down working deployments to block a much less likely attack. Verified: three offline tests (the address table, the URL table, and a refusal that holds with nothing listening at the metadata endpoint), both mutations confirmed to fail them (guard disabled → the download test fails; link-local dropped from `blocked_ip` → 169.254.169.254 is accepted), and the live `download_media_pixiv_original_with_referer` still fetches from i.pximg.net through the guarded client, so real media downloads are unaffected. `cargo fmt`, `cargo clippy --workspace --all-targets --locked -- -D warnings`, `cargo test --workspace --locked` (198 passed, 15 ignored) clean.