[Bug] 通过URL发送文件功能缺少SSRF防护，存在内网探测风险

[hiroa-ai]

问题描述

通过 URL 发送文件的功能对传入的地址没有权限限制，存在 SSRF（服务端请求伪造）风险。攻击者可以传入内网 IP（如 192.168.x.x）或本地端口地址，服务端会直接发起请求，被当作跳板进行内网探测，可能泄露内网服务信息或访问本地敏感接口。

如何复现

1. 向该功能传入类似 http://192.168.1.1/admin 或 http://127.0.0.1:port 的地址
2. 服务端会尝试拉取该地址内容，从而探测内网/本地服务

AstrBot 版本

v4.28.1

操作系统

Linux

部署方式

Docker

使用的消息平台适配器

无关（该功能与消息平台适配器无关，为通用功能）

错误日志

无运行时报错，为代码审计发现的安全问题（SSRF）

检查清单

• 我已在 Issue 列表中搜索过相关问题仍无法解决，或该问题从未被报告过。
• 我已尝试过禁用所有插件，排除了可能是因插件导致的问题。
• 我报告的问题与 AstrBot 本体相关，而非在报告某一插件的问题。
• 我已阅读并同意本项目的贡献者行为准则。
• (可选)我愿意提交 PR 以帮助修复该问题。

[kilisamemarisaaa]

I confirmed the report against the current source. The URL path reaches astrbot/core/utils/io.py:113 (download_image_by_url) and constructs an aiohttp.ClientSession before calling session.get(url) or session.post(url, ...); there is no scheme/host/IP-range policy check in this function. The fallback after certificate errors also creates a session with certificate verification disabled, although that is separate from the SSRF boundary.

This is a code-path confirmation only, not an exploit attempt. A fix should validate the resolved destination (including redirects and DNS resolution) at the request boundary, and apply the same policy to both GET and POST. It should also preserve legitimate public HTTPS URLs and avoid relying only on string checks such as blocking 127.0.0.1.