Hello，大家好，好久不见。首先还是碎碎念环节，最近我也有在学 web 安全，也有记笔记，只是好多东西记得乱七八糟，懒得总结，就一直没发博客。
很长一段时间我都在自我怀疑，质问自己为啥还没挖到洞，说实话都有点焦虑了，哈哈。后来我意识到我还是积累的太少，投入的太少。于是我给自己设置了一个一千小时挑战，投入一千小时到 bug hunting，只做事，不问结果。现在过去了小六周了，因为是在下班后才能学会，我只学了九十不到一百个小时，投入的还是有点少呀。
这段时间里，我：
- 看了五十篇漏洞报告/writeup；
- 补充了一些基础知识（如 SOP, CSP, HSTS等）；
- 看了下 zseanos 的方法论；
- 看了篇 Cookie 的论文。不过话说回来，都 4202 年了，CSRF 还是真实存在的嘛？
- Hacker101 ctf 也拿到了 26 分，HackerOne 上说拿到 26 分会有 private program 邀请，不过我什么邀请也没收到，裂开；
- 在 BugCrowd 上找了个目标，pinterest（话说有测过这个网站的小伙伴吗），但直到昨天才开始真正 hunting，研究了下修改个人信息模块，报文好多头部看不懂（呜呜）。
另外，我发现现在好多都在用 GraphQL，有人说 GraphQL 是另一个 PHP，遍地黄金，希望能稍稍抓住点机会吧。
其实我每周都会记一下进度，类似下图。如果有小伙伴想追踪我的学习进度或者想要加入这不值一提的小挑战，欢迎评论区留言哦。一个人学挺容易懈怠的。
Hack to learn, hacking for fun!
1 什么是 SSRF
SSRF，服务端请求伪造，英文全称 Server-side Request Forgery，是 web 服务端漏洞的一种，允许攻击者执行未授权的行为或访问内网服务、敏感数据等。某些情况下，SSRF 也可能升级为 RCE（远程代码执行）漏洞。
OWASP wstg5.0 将 SSRF 也归为注入攻击，原因是其跟 XSS、XXE 注入一样隶属输入有效性验证测试模块。我是持不同意见的，要这么说那 80% 的攻击都算注入攻击？但我没有合适的理由，就，fine 啦。
在 2021 版的 OWASP Top 10 中，SSRF 独占一栏，位列第十，而诸如 XSS、SQLi 等典型的注入攻击全部被包含在 “Injection” 条目中。
2 SSRF 原理
SSRF 攻击的核心就一个词：信任关系（trust relationships）。当攻击者使用 URL http://victim.com/admin 直接请求目标服务器的 admin 页面时，由于目标服务器与攻击者之间并不存在信任关系，会提示没有访问权限，访问失败。
倘若借服务器之手发送请求呢？假设该服务器存在 Open Redirect 漏洞或重定向功能，如：http://victim.com/?redirect=http://target.com。通过构造 URL http://victim.com/?redirect=http://localhost/admin，攻击者以 web 服务器的身份请求 http://localhost/admin。由于 victim.com 与 target.com 间存在信任关系，target.com 正确响应，响应报文经 victim.com 返回给攻击者，从而执行未授权访问。在这个例子中，victim.com 与 target.com 是同一个服务器。
3 测试方法
从宏观层面讲，各个漏洞的测试都大差不差，基本都是“三步走”：
- 识别 SSRF 注入点
- 测试该注入点是否可利用？有无 WAF？绕过？
- SSRF 利用：dump 敏感信息或执行其它攻击
3.1 识别注入点
如上所述，SSRF 攻击利用信任关系，借 vulnerable server 之手向其它（内部）服务器发送请求，从而获取敏感信息。所以，识别注入点时可以重点关注该服务器可能与其它服务器 “通信” 的功能模块，如，加载 HTML 页面、重定向等。
So，具体应该怎么做呢？看参数！服务器怎么知道要加载那个页面呢？参数！重定向到哪个 URL 呢？还是参数！下面这个 GET 请求，通过参数 page 将要加载的页面传递给服务器。
1 | GET https://example.com/page?page=about.php |
下面我列了几个可能会导致 SSRF 的参数，你可以添加到你的字典里。
1 | url |
3.2 exploitable？
在找出可能的注入点后，就要判断它是否真的存在漏洞了（废话了属于是）。
How to do? 可以将参数设置成其它 URL，如 https://www.google.com，如果能跳转，也只能说明其可能存在 Open Redirect 漏洞，要判断 SSRF 的话，可以设置成 http://localhost/admin 或其他内部服务器 IP。
1 | GET https://example.com/page?page=http://localhost/admin |
所以为啥不直接测内部 IP？循序渐进啊，循序渐进！要是 https://www.google.com 都给你卡了，也别指望 SSRF 了。再换个角度讲，要是真能找到个 Open Redirect，起码有个保底赏金呀，别到头来白忙活啦，哥们！！！（题外话）
这里可能会涉及到一些 bypass，BUT，SSRF 的 bypass 方式多且杂，有些还有一定难度，我准备后续结合案例慢慢补充。当然，如果你现在就要看，可以先研读下 PayloadAllTheThings。
3.3 exploit！& SSRF 危害
这里把利用和危害一并说了，攻击者的“利用” ≈ 受害人的“危害”。
访问未授权页面
1
2GET https://example.com/page?page=http://localhost/admin
GET https://example.com/page?page=http://127.0.0.1/admin访问本地文件
1
GET https://example.com/page?page=file:///etc/passwd
访问 cloud metadata，如 AWS 敏感数据
1
2
3http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials
http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE NAME]RCE
XSS
and so on …
4 举个栗子
老规矩，用 PortSwigger Web Academy 最简单的 lab 举个例子。
网站业务分析，一个线上商城，商品展示，查看商品详情与库存，且有登录页面，但题目并未提供可用用户。
首先识别可能的注入点，根据题干，将目标锁定在获取库存模块。点击 “Check stock”，并抓包
抓包之后，发现客户端请求报文中包括了一个 API 参数 stockApi ，逻辑可能是后端服务器在收到客户端请求后，不是直接返回结果，而是请求该 API 获取数据并返回。请求链接为： http%3A%2F%2Fstock.weliketoshop.net%3A8080%2Fproduct%2Fstock%2Fcheck%3FproductId%3D2%26storeId%3D1 URL 解码后是 http://stock.weliketoshop.net:8080/product/stock/check?productId=2&storeId=1。
属于服务器与其它后端服务器/ URL 的通信，识别为可疑注入点。
思路：修改 stockApi 让服务端请求其他恶意 url 或未授权给用户的接口，如：http://localhost/admin。修改后可以进入 admin 面板，说明该注入点存在 SSRF 漏洞。
由于 Repeater 渲染后的页面无法进行其他操作，我们再次抓包，改包，并发送。
尝试删除用户 carlos。
报错提示：”Admin interface only available if logged in as an administrator, or if requested from loopback” 该操作要求管理员登录或者请求来自回环地址（127.0.0.1 或 localhost）。
留意一下此时的 url， 也就是说删除用户请求的是这个接口 /admin/delete?username=carlos。我们回到 Repeater 或者再抓一个包，将 stockApi 改为 stockApi=http://localhost/admin/delete?username=carlos，也就是利用 SSRF 执行未授权操作。响应报文也是很配合地重定向到了 /admin 页面，说明删除成功。
5 工具
我基本不咋用工具，但还是放几个给有需要的小伙伴吧。