最近我在一个提供一些无意义功能的网站上：
它基本上获取了一个 URL，然后转储了它的内容。它可以是 XML、txt、HTML、任何通过 curl 可到达的路径。
现在我突然想到这应该很危险，对吗？
我手头没有 Linux，也找不到这个网站，但我的 Windows 机器上一个快速被黑的 PHP 页面愉快地使用了这个 URL：
file://D:/something/index.html
并呈现给我。这基本上不会允许攻击者在运行脚本的机器上漫游吗？这个网址会不会
file:///etc/passwd
在Linux上工作？
还有其他一些明显的问题吗？
冒充他人通过 POP3、LDAP、smb 等方案访问其他资源？
在写这篇文章时，我问自己 HTTP[S] 和 FTP 的白名单方案是否可以解决这些问题？
我仍然可以通过此页面在网站上冒充访问者，但除了访问非法内容或可能绕过审查等问题外，我不知道有任何问题。
如果输入没有经过仔细过滤，那么这就是一个称为服务器端请求伪造 (SSRF)的漏洞。
甚至还有一个常见的弱点枚举编号和页面。 https://cwe.mitre.org/data/definitions/918.html
通过向意外的主机或端口提供 URL，攻击者可以使服务器看起来正在发送请求，可能会绕过阻止攻击者直接访问 URL 的防火墙等访问控制。服务器可以用作代理对内部网络中的主机进行端口扫描，使用其他 URL，例如可以访问系统上的文档（使用 file://），或使用其他协议，例如 gopher:// 或 tftp ://，这可以更好地控制请求的内容。
通过利用此漏洞，攻击者可以：
未经过滤的cURL支持甚至比普通的 SSRF 漏洞更糟糕，因为 cURL 支持除 HTTP 和 HTTPS 之外的许多 URL 模式。运行#curl-config --protocols以查看支持的内容。
file://您可以使用URL 方案访问本地文件（curl file:///etc/passwd在 linux 上工作）dict://URL 模式向任何端口上的任何主机发出请求并发送自定义数据。URLdict://host:port/command将导致服务器连接到主机并将字符串发送command到指定的端口。ldap://ftp://scp://smb://telnet://imap://pop3://smtp://rtsp://tftp:// 好吧，这取决于他们如何实现此功能，这确实可能非常危险。除了您提到的风险之外，系统还可能检索到非公共 URL。例如检索http://127.0.0.1将检索 localhost。
这可能是一个风险，因为如今管理面板之类的东西通常通过 HTTP(s) 部署，并且可能可供本地服务器访问，而不是随机的其他 IP。
当然，现在您可能会发现该站点正在正确过滤所有这些攻击，除非您尝试它们，否则这些攻击并不明显（当然，根据您的管辖范围，这在法律上可能是可疑的......）