一篇文章学会ssrf

1. 内网资源访问：攻击者可以利用SSRF漏洞发送请求到内部网络中，绕过防火墙，访问并互动与后端系统，包括数据库服务、HTTP服务、版本控制系统等，这可能导致敏感数据的泄露。

2. 远程代码执行：在某些情况下，如果应用程序在处理用户提供的URL时不够严谨，攻击者可能利用SSRF漏洞执行远程代码，这可能导致服务器被完全控制。

3. 服务拒绝（DoS）攻击：攻击者可以利用SSRF向内部系统发送大量请求，导致服务不可用或系统资源耗尽。

4. 扫描内部网络：攻击者可以利用SSRF漏洞探测内网环境，识别网络结构和寻找其他潜在的安全漏洞。

5. 文件读取：如果服务器配置不当，SSRF可能允许攻击者请求本地或远程文件，这可能导致敏感文件内容被读取。

1. 直接把如 www.baidu.com 这种网站输上去看看有没有成功访问

2. 试一试特殊协议，比如 file://、 ftp:// dict://、gopher://

3. 端口扫描，这个没啥说的 遍历就完了，如 http://target.com:22

4. 利用URL解析差异，如

通过添加@符号重定向到其他地址，例如 http://[email protected]

用#来尝试忽略URL的一部分，例如 http://target.com#attacker.com

回环和本地地址 如 使用 http://127.0.0.1、http://localhost 或 http://[::1] 来尝试访问本地服务

绕过技巧

使用短URL或重定向服务来绕过验证。

IP地址八进制、十六进制或混淆形式。

添加无关查询参数或使用URL编码来混淆真正的请求。

防御方法

使用白名单：

仅允许应用程序发起到预先定义的、可信赖的域名或IP地址的请求

对于必须接受用户输入的情况，确保所有的输入都符合白名单中的条目

输入验证：

严格验证用户输入的URL格式，确保只有白名单中的URL能够通过

限制协议：

限制应用程序可用于发起请求的协议类型，通常仅允许http://和https://

先找到这个查看库存的地方看一下它的请求包

好 这就是一个典型到不能再典型的可能存在 SSRF 漏洞的注入点了，正常来说我们可以通过修改参数为 www.baidu.com 之类的方法去测试一下，但是这个靶场是不通公网的，所以这样明显是不会成功的，所以我们就直接拦截后修改成题目要求的 http://localhost/admin 即可

此时我们就可以看到管理员面板了，那我们之间点删除就好了

看起来不太行，提示我们需要登录管理员账号或在回环请求中才能使用管理员界面，那我们就看看它的删除请求是什么样子的

这里我们做一点小小的修改， payload http://localhost/admin/delete?username=carlos 然后我们再回到存在 SSRF 漏洞的位置重新提交

此时我们可以看到，原来的 carlos 已经被删除，只剩下了 wiener 用户，手工下班

1. 鉴权与功能不是一个服务完成的。在实际的生产环境中，为了实现类似 sso （单点登录）这样的功能，其鉴权和功能可能是分布在不同的组件上的，当用户使用功能的时候肯定是需要鉴权的，但是当服务器本身去访问的时候就不一定了，如果程序员没有考虑到这种情况，很可能会出现绕过鉴权的问题，毕竟我访问我自己还需要问问我是不是我？

2. 为了留一个后手用来实现灾难恢复。如果有一天服务崩掉了，恰巧运维把管理员密码给忘了，这种时候总不能什么都做不了吧，那就只能通过免登录的上机恢复了，当然这种情况下默认能进到机房或者能远程服务器的人是可靠的，所以他们就做了这样的一个逻辑处理，但是他们万万没想到还会存在 SSRF 这种东西。

这个靶场和上一个的区别不大，难点主要在怎么发现这个服务器，这个可以利用 burp 的 Intruder 模块，这里提示了相关的网段和开放的端口，可以节省很大的时间，实际中就需要耗费大量的时间在扫描上了，相关配置如下

之后我们就可以直接开扫了

看结果可以知道是 http://192.168.0.137:8080/admin，那后面的步骤就没有什么区别了，修改一下 payload 发送到 repeator 发送即可 payload http://192.168.0.137:8080/admin/delete?username=carlos

无回显 SSRF

1. 使用十进制八进制的表示方法来代替原本的 127.0.0.1，如 2130706433、01770000001和127.1

2. 如果对方的服务器可以通公网的话，你可以注册一个域名然后解析成 127.0.0.1，当然这个需要一些钞能力

3. 如果是关键字检测是的话可以试试大小写绕过或者URL编码绕过

我们直接到注入点看一下是什么情况

可以看到是有安全检测的，我们用上面的绕过方式修改一下 payload 看看 http://localHoSt/aDmIn

可见成功绕过，那后面的也就没什么技术含量了 http://localHoSt/aDmIn/Delete?username=carlos 即可

白名单绕过

1. 使用 @ 在URL 的主机名前嵌入凭据：https://expected-host:fakepassword@evil-host

2. 使用 # 表示URL 片段：https://evil-host#expected-host

3. 如果实现过滤器的代码处理URL编码字符的方式与执行后端HTTP请求的代码不同，可以通过URL编码字符来混淆URL解析代码，也可以尝试对字符进行双重编码；一些服务器递归地对它们接收到的输入进行URL解码，这可能导致进一步的差异从而实现绕过白名单限制

4. 就是可以把上面的一起用出来

首先我们来了解一下如何判断网站是 黑名单策略还是白名单策略，我们先来看一下白名单的情况，原始参数是 stockApi=http%3A%2F%2Fstock.weliketoshop.net%3A8080%2Fproduct%2Fstock%2Fcheck%3FproductId%3D1%26storeId%3D1，我们这里输入 http://127.0.0.1

这里提示 库存检查的主机必须是 stock.weliketoshop.net，当然正常情况下网站不会这么直白的告诉我们，我这里也不会通过这个来分辨防御策略，所以我们继续往下试，因为如果是黑名单的话，它只会禁止一些特征明显的关键字，我们就随便编一个奇奇怪怪的网址就好了，比如 http://aaa.bbb.com

我们发现它的返回还是没有变化，那说明应该是 白名单 的防御策略。

下面我们看看 黑名单是什么样的情况吧，还是先看 http://127.0.0.1

这里提示触发了安全策略，我们还是不管，换成 http://aaa.bbb.com 看看效果

这次就和白名单的返回不一样了，服务器尝试了连接，但是当然是连不到的，所以也就可以断定是黑名单策略了

当然本节讲的是白名单的绕过，我们回到主题上来，前面说到我们可以利用 URL 解析的差异性来绕过 白名单检测，用在这个案例中，我们的思路就是让校验逻辑认为请求的是 stock.weliketoshop.net ，但实际上是另外一个主机，那应该怎么做呢，还记得我们上面的提到的 # 这个符号吧，它是一个片段标识符，它后面的内容不会被用作服务器通信，而是一个单纯的页面锚点，这里我们利用的也就是这个特性，先让我们试试 http://localhost:80#stock.weliketoshop.net

哎？好像不行啊，是它不支持吗，我们改成 @ 符试试 http://localhost:[email protected]

@ 符是可以的，那问题可能是出在 # 上面了，我们对它进行编码试试 http://localhost:80%[email protected](这个试过了也不行，直接上双重编码) http://localhost:80%[email protected]，这里加上 @ 是为了让校验逻辑认为前面的部分是账号密码，但它实际上会被 # 注释掉成为片段的一部分，从而使 @ 失效

可见是可以访问了，那就加上要求的删除用户 http://localhost:80%[email protected]/admin/delete?username=carlo即可

来到原来的地方看看是个什么情况

可以发现这里变成了相对路径，当然我们肯定不能就这么相信它，写进去看看

好吧 看来它没骗我们，现在找到了那个重定向的接口

可以看到这里有个重定向，我们再输进去看看是什么结果（这里主要看的是后台有没有限制重定向的域名）

可以看到，服务器对于这个地址并没有什么疑问，那就好说了，在检查库存的地方让它访问这里，然后就可以在服务端重定向到指定的内网机器，执行我们的payload了 /product/nextProduct?currentProductId=2%26path=http://192.168.0.12:8080/admin/delete?username=carlos(currentProductId 参数没什么用直接删掉，要不然后面的 & 会认为 path 参数和 stockApi 是同一级的参数，而不是 stockApi 中的值；当然也可以对 & 进行URL编码)