红队系列-SRC常用漏洞挖掘技巧_红队、src

·

重放攻击

 重放攻击漏洞  
   
 比如说点赞或者签到地方，服务器是根据ip地址识别当前用户是否已点赞的，  
 在数据包里添加一行X-Forwarded-For来伪造http客户端ip，  
 使用bp抓包后发到intruder里遍历IP，设置payload去攻击，经过多次重放，可导致多次签到。  
   
 防御：  
 1.添加token值  
 2.添加时间戳。
1
2
3
4
5
6
7
8
9

逻辑漏洞

 支付逻辑漏洞  
 服务器端没有对客户端请求数据中的金额、数量等敏感信息作校验，攻击者通过bp抓包修改任意金额购买商品或者给账号充值等。  
   
 防御：  
 1.在请求数据中对涉及金额、数量等敏感信息进行加密，并在服务器端对其进行校验。  
 2.支付交易请求数据中加入token，防止重放攻击。
1
2
3
4
5
6

越权访问

   
 ## 越权漏洞  
 水平越权：  
 修改get或post参数来查看其他人的业务信息  
   
 垂直越权：  
 两个账号，一个普通，一个管理员，  
 抓包修改管理员的参数，权限类型不变，权限ID改变，普通账号获得与管理员相同的权限。
1
2
3
4
5
6
7
8

目录遍历

未授权访问

暴力破解

  验证码脚本  
    
  验证码  
 暴力破解：验证码具有一定的规律性，通过穷举或其它方式猜解出验证码。  
 验证码重复使用：当服务器端接受请求后，没有将上一次保存的session及时清空，将会导致验证码可重复使用。  
   
 验证码绕过：系统没有把验证码和用户放在一个请求里面校验，导致绕过了第一次验证码校验，就可以进行密码爆破。

 生物验证与非对称加密  
   
 登录频繁限制  
   
   
 安全开发 登录  
   
 https://blog.csdn.net/TL_ATC/article/details/113092201  
   
 接口安全设计  
   
 

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

密码找回

  密码找回  
 本地抓取数据包并对其内容加以分析就能获取到其他用户的用户凭证,  
 从而达到重置任意用户密码的目的。  
 找回密码功能模块通常会将用户凭证(通常为验证码或者链接)发送到用户注册时使用的手机号或者邮箱中，  
 只要用户不泄露自己的用户凭证就不会被攻击者利用。  
 但有些信息系统在密码找回功能的设计存在逻辑缺陷，  
 可能会将用于用户自证身份的信息的用户凭证以各种各样的方式返回到客户端。  
   
   
 防御：  
 1.不要将token验证之类的数据直接返回给用户数据包。  
 2.用户身份验证一定要在后端实现。
1
2
3
4
5
6
7
8
9
10
11
12

信息泄露

 logo  
 目录结构  
   
 
1
2
3
4

URL重定向

CRLF

cookie伪造

http://t.zoukankan.com/lovequitepcs-p-12864203.html

通达OA任意用户登录和后台GetShell漏洞

8RCE

1

## RCE远程 代码执行/命令执行
### 过滤掉了cat命令
使用more、less、head、tail、tac、sort、uniq、file -f、vi/vim、nl/od

### 过滤了空格

```
linux过滤空格可以使用${IPS}、${IPS}$
windows下可以使用%20（空格），%09（tab）
```

### 过滤特定字符

```
使用通配符例如fla*.php或者使用base64编码，还可以使用变量拼接，例如，a=fl;b=ag;$a$b。
```
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

rce
找exec、shell_exec、popen、proc_popen、system、eval、assert 这些函数
1
2

7SSRF

   
 SSRF（Server-Side Request Forgery，服务器端请求伪造）漏洞是一种常见的网络安全漏洞，它允许攻击者在受攻击的应用程序上执行未经授权的网络请求。下面是SSRF漏洞的详细介绍以及可能导致的危害：  
   
 1. 漏洞原理：SSRF漏洞通常出现在应用程序中存在用户可控的输入参数，攻击者可以操纵这些参数，使应用程序发起指向内部网络或外部互联网的请求。  
       
 2. 攻击方式：攻击者利用SSRF漏洞可以发起以下类型的攻击：  
       
     - 访问内部资源：攻击者可以通过指定内部IP地址或域名，访问应用程序所在服务器内部的资源，如数据库、管理界面等。  
     - 探测内网服务：通过发送特定请求（如访问本地API、敏感文件等），攻击者可以探测目标网络的拓扑结构和敏感信息。  
     - 攻击其他系统：攻击者可以利用SSRF向外部服务器发送恶意请求，包括针对内网的攻击、远程代码执行、DDoS攻击等。  
 3. 危害与风险：  
       
     - 数据泄露：攻击者可以利用SSRF漏洞访问内部资源并窃取敏感数据，例如数据库中的用户信息、API密钥等。  
     - 内网攻击：通过访问内部服务或发起内网攻击，攻击者可以进一步侵入网络和系统，造成更严重的后果。  
     - 服务器资源滥用：攻击者可以利用SSRF漏洞发送大量外部请求，导致服务器资源过载、服务不可用以及额外的带宽消耗。  
     - 完全控制：如果攻击成功，攻击者可能获得对服务器的完全控制权，并在其上执行任意操作。  
   
 为了防止SSRF漏洞的滥用，开发者应该采取以下安全措施：  
   
 - 验证和过滤用户输入：对于用户可控参数，应该验证和过滤输入，确保只允许有效的URL和受信任的主机地址。  
 - 使用白名单：限制应用程序可以访问的资源和外部服务，仅允许必要的请求。  
 - 内网隔离：将应用程序和内部资源放置在独立的安全网络中，防止直接访问内部系统。  
 - 加强监控和日志记录：及时检测异常请求并记录相关信息，以便追溯和响应安全事件。  
   
 总之，SSRF漏洞可能导致严重的安全威胁，攻击者可以通过它窃取数据、攻击内部网络以及滥用服务器资源。因此，开发者和系统管理员应密切关注并采取措施来防止和及时修复SSRF漏洞。

# SSRF getshell

[https://segmentfault.com/a/1190000021960060](https://segmentfault.com/a/1190000021960060)

[https://xz.aliyun.com/t/9371](https://xz.aliyun.com/t/9371) [https://forum.butian.net/share/1085](https://forum.butian.net/share/1085)

   
 ## SSRF 服务端请求伪造  
 服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。  
   
 对外网、服务器所在内网、本地进行端口扫描，获取一些服务的版本信息；  
 攻击运行在内网或本地的应用程序  
 对内网 WEB 应用进行指纹识别，  
 通过访问默认文件实现(如：readme文件)；  
   
 攻击内外网的 web 应用，主要是使用 GET 参数就可以实现的攻击  
 (如：Struts2，sqli)；  
 下载内网资源(如：利用file协议读取本地文件等)；  
 进行跳板；无视cdn；利用Redis未授权访问，HTTP CRLF注入实现getshell  
   
 ### 防御  
   
 ```cpp  
 1.限制协议：仅允许http和https请求。 不让使用伪协议  
 2.限制IP：避免应用被用来获取内网数据，攻击内网。  
 3.限制端口:限制请求的端口为http常用的端口，比如，80,443,8080,8090。  
 4.过滤返回信息:验证远程服务器对请求的响应是比较简单的方法。  
 5.统一错误信息:免用户可以根据错误信息来判断远端服务器的端口状态。  
 

### 测试过程

 有回显  
 直接通过页面加载出目标资产，  
 可先尝试加载http://www.baidu.com 页面确认有ssrf，如果成功的话，  
 可进一步将百度换成内网IP，通过fuzz扫描内网资产。  
   
 无回显  
   
 1.先配合dnslog平台，测试dnslog平台能否获取到服务器的访问记录，  
 如果没有对应记录，也可能是服务器不出网造成的，  
 利用时可以通过请求响应时间判断内网资产是否存在，  
 然后再利用内网资产漏洞（比如redis以及常见可RCE的web框架）证明漏洞的有效性。  
   
 "... <!ENTITY test SYSTEM "SSRF.xxxx.ceye.io\\aa"> ..."  
   
 "... <!ENTITY test SYSTEM "SSRF.lkun0l.dnslog.cn\\aa"> ..."  
   
 2.使用burp的collaborator来进行尝试  
 3.开启apache服务，  
 在存在ssrf处访问http://10.1.1.200(本机服务地址)，查看服务器日志信息，  
 打开日志确定是否被访问,确定是否存在ssrf漏洞。  
   
 

### 禁用 127.0.0.1 后如何绕过，支持哪些协议

CRLF 是指cr回车、lf换行，

绕过方法可以使用url单、双编码，还可以将/r/n换为ascii

### php常用的伪协议

filter、file、ftp、http、https、php、data、glob、phar、expect。其中expect需要扩展

   
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93

6XXE

## XXE  xml外部实体注入


XXE漏洞发生在应用程序解析XML输入时，没有禁止外部实体的加载，
导致可加载恶意外部文件，
造成文件读取、命令执行、内网端口扫描、攻击内网网站、发起dos攻击等危害。
xxe漏洞触发的点往往是可以上传xml文件的位置，
没有对上传的xml文件进行过滤，导致可上传恶意xml文件。


利用DTD可以进行内部引用、外部引用、引用公告DTD、引用参数DTD
可以造成DDOS攻击、文件读取、命令执行、SQL执行、内外网端口扫描、入侵内网站点；

### 防御

```cpp
1、使用开发语言提供的禁用外部实体的方法。

2、PHP：libxml_disable_entity_loader(true);

3、过滤用户提交的XML数据
4、XML 解析库在调用时严格禁止对外部实体的解析
```



### 关键词：

 

```cpp
<!DOCTYPE和<!ENTITY，或者，SYSTEM和PUBLIC。
```

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

5CSRF

 
## CSRF跨站请求伪造
网站的cookie在浏览器中不会过期，只要不关闭浏览器或者退出登录，而在这个期间，
攻击者发送了构造好的csrf脚本或包含csrf脚本的链接，执行一些用户不想做的功能（比如是添加账号等）。

### 防御

```cpp
1.验证 HTTP Referer 字段
2.在请求地址中添加 token 并验证
3.在 HTTP 头中自定义属性并验证
4.再次输入密码
```
1
2
3
4
5
6
7
8
9
10
11
12
13

【Burp系列】超全CSRF请求伪造漏洞实验总结

https://mp.weixin.qq.com/s/AeM8pm4vEJLD2TTjmRw9aQ

（1）构造CSRF攻击（√）

（2）颠覆应用程序逻辑（√）

（3）绕过SameSite Cookie限制（√）

（4）绕过基于引用的CSRF防御（√）



靶场地址：https://portswigger.net/web-security



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

跨站点请求伪造（CSRF）

1、简述：

跨站点请求伪造（CSRF）是一个Web安全漏洞，
使得攻击者能够诱使用户执行他们不打算执行的操作。

它允许攻击者部分规避同源策略，该策略旨在防止不同的网站相互干扰

1
2
3
4
5

2、影响：

在成功的CSRF攻击中，攻击者会让受害者用户无意中执行某个操作。
如可能是更改帐户上的电子邮件地址、更改密码或进行资金转账。
根据操作的性质，攻击者可能能够完全控制用户帐户。

如果受损用户在应用程序中具有特权角色，则攻击者可能能够完全控制应用程序的所有数据和功能。
1
2
3
4
5

3、原理：

1、CSRF攻击必须具备三个关键条件：

    1、一个操作行动。
应用程序中存在攻击者有理由引发的操作。
这可能是一个特权操作（如修改其他用户的权限），也可能是对用户特定数据的任何操作（如更改用户自己的密码）。

    2、基于Cookie的会话处理。
执行操作涉及发出一个或多个HTTP请求，应用程序仅依赖会话cookie来识别发出请求的用户。
没有其他机制可用于跟踪会话或验证用户请求。

    3、没有不可预测的请求参数。
执行操作的请求不包含任何攻击者无法确定或猜测其值的参数。
例如，当使用户更改其密码时，如果攻击者需要知道现有密码的值，则函数不容易受到攻击。


2、示例

1、某个应用程序包含允许用户更改其帐户上的电子邮件地址的功能。当用户执行此操作时，会发出如下所示的HTTP请求：
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=wiener@normal-user.com

2、这符合CSRF要求的条件：
攻击者会对更改用户帐户上的电子邮件地址的操作感兴趣。
在此操作之后，攻击者通常能够触发密码重置并完全控制用户帐户。
应用程序使用会话cookie来标识发出请求的用户。没有其他令牌或机制来跟踪用户会话。
攻击者可以轻松确定执行操作所需的请求参数值。

3、具备这些条件后，攻击者可以构建包含以下HTML的网页：
<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

4、 如果受影响用户访问攻击者的网页，则会发生以下情况：
攻击者的页面将触发对易受攻击网站的HTTP请求。
如果用户登录到易受攻击的网站，其浏览器将自动在请求中包含其会话Cookie（假设未使用SameSite Cookie）。
易受攻击的网站将以正常方式处理请求，将其视为受害用户发出的请求，并更改其电子邮件地址
虽然CSRF通常是针对基于Cookie的会话处理进行描述的，但它也出现在应用程序自动向请求添加一些用户凭据的其他上下文中，
例如HTTP基本身份验证和基于证书的身份验证




4、构造CSRF攻击
1、手动创建CSRF利用所需的HTML可能很麻烦，特别是在所需请求包含大量参数或请求中存在其他异常的情况下。构建CSRF利用漏洞攻击的最简单方法是使用 CSRF PoC发生器 内置于BP专业版：

    1、在Burp Suite Professional中的任意位置选择您想要测试或利用的请求。
    2、从右键单击上下文菜单中，选择参与度工具/生成CSRF PoC。
    3、Burp Suite将生成一些HTML来触发选定的请求（不包括cookie，它将由受害者的浏览器自动添加）。
    4、可以调整CSRF PoC生成器中的各种选项来微调攻击的各个方面。在一些不寻常的情况下，您可能需要这样做，以处理请求的古怪特性。
    5、将生成的HTML复制到网页中，在已登录到易受攻击网站的浏览器中查看该网页，并测试是否成功发出预期请求以及是否发生所需操作。
示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

4、构造CSRF攻击

实验1：无防御的CSRF漏洞
1

5、利用CSRF

6、针对CSRF的常见防御措施

二、绕过CSRF令牌验证

1、CSRF令牌

2、CSRF令牌的验证取决于请求方法

实验2：令牌验证取决于请求方法的CSRF
1

3、CSRF令牌的验证取决于令牌是否存在

实验3：CSRF，其中令牌验证取决于令牌是否存在

4、CSRF令牌未绑定到用户会话

实验4：令牌未绑定到用户会话的CSRF
1

5、CSRF令牌绑定到非会话Cookie

实验5：令牌绑定到非会话cookie的CSRF
1

6、CSRF令牌只是在Cookie中复制

实验6：标记在Cookie中重复的CSRF
1

三、绕过SameSite Cookie限制

1、简述：

2、SameSite Cookie的上下文中、网站

3、站点和源之间的区别

3、SameSite工作原理

4、使用GET请求绕过SameSite Lax限制

实验7：通过方法覆盖绕过SameSite Lax
1

5、使用现场小工具绕过SameSite限制

实验8：通过客户端重定向绕过SameSite Strict
1

6、通过易受攻击的同级域绕过SameSite限制

实验9：通过兄弟域严格绕过SameSite
1

7、使用新发布的Cookie绕过SameSite Lax限制

 实验10：通过cookie刷新绕过SameSite Lax
1

四、绕过基于引用的CSRF防御

1、简述：

2、引用方的验证取决于是否存在标头

实验11：CSRF，其中Referer验证取决于是否存在标头
1

3、可以绕过引用方的验证

实验12：引用方验证中断的CSRF
1

渗透测试-业务逻辑与非常规漏洞原理与利用 逻辑漏洞专题

 在攻击者没有获取到登录权限或未授权的情况下，或者不需要输入密码，
即可通过直接输入网站控制台主页面地址或者不允许查看的链接便可进行访问，同时进行操作。


一个页面对用户身份的判断基于两种方式：
一种是将身份验证代码写入当前文件；
另一种是写一个身份验证的代码文件，


然后其他页面需要调用时，直接包含进来即可。
当写了身份验证代码，但开发者在开发时忘了将身份验证的代码文件包含进来，就会造成未授权访问，asp/aspx的网站通常会有这样的问题。








未授权漏洞一般分为两种：
1、组件类的
redis未授权、mongodb未授权等
不需要登录即可执行里面的功能，所以存在未授权漏洞。
2、WEB层面的，
CMS未授权文件上传、未授权创建账号等。
因为可以绕过登录限制进行操作，所以存在未授权访问漏洞。


https://blog.csdn.net/weixin_43214644/article/details/124348759

[格格巫 MMQ!!]()

https://blog.csdn.net/weixin_43214644





1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

 认证因子Cookie
由于 HTTP 是无状态的协议，不能保存每一次请求的状态，所以需要给客户端增加 Cookie 来保存客户端的状态。
Cookie，是某些网站为了辨别用户身份，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密）


包含xxx.php
<?php
if(isset($_SESSION[""]))

由用户客户端计算机暂时或永久保存的信息。


浏览器->检查->application->cookie


还有auth，jwt等认证方式。大体方向是一样的，都是为了辨别用户身份（鉴权）。







漏洞挖掘
只需要将数据包中的Cookie等字段值置空或者修改为无用字符，再查看前后的数据包是否相同即可。
一个插件可以帮助快速挖掘此类漏洞。
项目地址：https://github.com/theLSA/burp-unauth-checker


burp 本身抓包模块功能
options->match and Replace

type:Request header
match:Cookie:xxx=.*
Replace:Cookie:xxx=1
regex match


越权访问漏洞

使用用户A的权限去操作用户B的数据，如果能够成功操作，则称之为越权操作。
如果A、B的权限相同，或者说是在同一水平层面的，那么我们称此操作为水平越权。
否则为垂直越权。


漏洞挖掘
越权类漏洞分为两大类
1、未使用cookie鉴权，通过修改userid等字段进行越权。
2、使用cookie鉴权，未检测对应操作是否符合当前权限预期。

一、
HTTP  history

Filter setting
filter by search term
eg:userid	有没有通过userid等参数值进行校验的,通过全局搜索userid、id、countid等字符
通过修改对应id值进行判断。


例如此处获取用户数据功能，如果未检测用户id是否与cookie对应。
那么便可以通过枚举用户id，获取其他用户数据。


获取验证码功能，通过修改user字段值，伪造代替其他用户获取验证码进行越权操作。


二、
第一种、拥有两个账号密码的情况下，使用管理员账号操作，抓取数据包，修改cookie为普通用户的cookie
第二种、只有普通账号的情况下，通过js文件发现接口，通过自主访问接口，fuzz字段值进行越权测试
拥有两个账号密码
1、登录管理员用户，获取以下cookie
PHPSESSID=lm5n7it0hinhbnqa3fp4v263i3
2、登录普通用户，获取以下cookie
PHPSESSID=9sa9vq9ng9n7b9hodjrkel5qg7
使用管理员进行添加用户操作并抓取数据包
将数据包发送到重放模块，替换cookie为普通用户cookie。如果依旧可以正常执行，那么即表示存在越权漏洞。

通过暴力破解获取了一个低权限账号的情况下，
一般会先通过js文件、swagger等获取存在的接口，然后访问接口查看是否能直接获取信息。
【Js里找到 未授权访问的接口】

能够获取信息那么删除认证因子看看是否能够未授权。
直接访问提示错误，并且没有办法fuzz到具体的参数的话，一般就无法利用了。
有些情况下，会提示缺少什么参数，或者什么参数不能为空。这就可以构造出具体的请求包进行测试。


能够进行操作，比如获取某用户信息，修改某用户数据，那么便是存在越权漏洞。
当提示无权限或者其他错误信息，即不存在越权漏洞。



修复
1、检测cookie是否已登录。
2、如果该功能属于管理员才能操作的功能，检测cookie中的用户是否属于管理员组。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94

1.3 密码找回漏洞~1

1、密码重置

一般的密码重置的设计都是分为以下四步的：

1.输入账户名
1

2.验证身份
1

3.重置密码
1

 4.完成   
1

通常漏洞是会存在于2或者3步骤中，下面来看看常见的一些重置密码漏洞的方式。

2、任意使用
3、越权操作

挖掘逻辑漏洞思路
1、各种回显（验证码回显，用户凭证回显，个人信息回显）
2、各种可逆（登陆处存在撞库危害，发现用户凭证可逆）
3、逻辑顺序（）

越权