免责声明

CSRF(Cross-site request forgery)跨站请求伪造

跨站点请求伪造被称为CSRF，发生在用户访问站点上的页面时，该页面在另一个站点上执行操作。假设用户点击了由恶意攻击者精心构造的恶意链接，该html连接的内容为：<img src =" https://vulnerable-website.com/email/change?email=pwned @ evil-user.net">，用户点击之后，会将易受攻击的网站上的帐户电子邮件更改为”[email protected]“。CSRF之所以起作用是因为发出请求的是受害者而不是站点，因此，被攻击站点看到的只是发出普通请求的普通用户。例如，通过使用密码重置，完全控制了用户的帐户。在极端情况下甚至能获取受害者信用卡的信息。

利用要求：

• 攻击者必须构造恶意链接诱使受害者点击链接

• 服务器存在CSRF漏洞

• 服务器没有二次验证机制

• 用户的身份验证没有过期

• 攻击者要熟悉网站请求

CSRF 发生原因： 服务器对用户的验证不够严格(二次验证)

攻擊者並不能通過CSRF攻擊來直接獲取用戶的帳戶控制權，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶的瀏覽器，讓其以用戶的名義執行操作。

CSRF 能做到的：

• 修改个人信息/帐号密码

• 发送伪造的业务请求

• 关注他人的社交帐号,推送博文

• 在用户非自愿,不知情的情况下提交请求

• 获取信用卡等信息

攻击方法:

如果服务器没有做任何验证,则可以直接构造恶意链接诱使用户点击

如果服务器对Referer进行了验证,则可以考虑

• 修改文件名(如dvwa medium难度)

• 如果站点下存在xss漏洞则可以结合,构造反射型恶意链接,或将恶意js代码存储在数据库中(存储型)

防御方式

1. 重要操作加入验证码

2. Referer 检测

3. Anti CSRF Token
   生成一个Token，放在用户的Session中，或者在浏览器的Cookie中。
   页面表单附带Token参数
   用户提交请求后，服务端验证表单中的Token是否与用户的Token一致
   这个Token的值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。

SSRF 服务端请求伪造攻击

SSRF是Web应用程序中的漏洞，攻击者可以通过该漏洞通过服务器发出进一步的HTTP请求。攻击者可以利用此漏洞与服务器网络上通常受防火墙保护的内部服务进行通信。

在正常情况下，攻击者只能访问网站并看到网站数据。运行网站的服务器被允许与内部的GitLab或Postgres数据库进行通信，但用户可能不允许，因为中间的防火墙只允许访问80端口（HTTP）和443端口（HTTPS）.然而，SSRF将使攻击者有能力通过连接到网站服务器，然后使用该服务器连接到数据库，从而与Postgres建立连接并查看其数据。Postgres会认为网站正在向数据库请求什么，但实际上，这是攻击者利用网站的SSRF漏洞来获取数据。过程通常会是这样的：攻击者在网站上发现一个SSRF漏洞。防火墙允许其对网站的请求。然后，攻击者利用SSRF漏洞，迫使网站服务器从数据库中请求数据，然后将数据返回给攻击者。由于请求来自网络服务器，而不是直接来自攻击者，所以防火墙允许这个请求通过。

• 生成十六进制的IP地址

• 各种绕过姿势

SSRF产生原因:

web服务器过于信任用户输入的URL地址。

payload:

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

http://vulurl/?url=http://127.0.0.1:3306

# 也可以变成这样
http://vulurl/?url=http://localhost:3306

http://:::3306
127.0.0.1 可以变化成
127.127.127.127
127.4.5.6 等等

# 读文件
http://vulurl/?url=file:///etc/passwd

# 也可以用十进制绕过
http://2130706433/ = http://127.0.0.1

# 十六进制也是可以的

http://0x7f000001/ = http://127.0.0.1

防御方式

• 限制协议为HTTP、HTTPS

• 不用限制302重定向

• 设置URL白名单或者限制内网IP

SSRF，XSS，CSRF 三者区别

不同点:

• XSS:利用用户对站点的信任

• CSRF:利用站点对已经验证用户的信任

• SSRF:利用内网服务器对内网边界机器的信任

相同点：

都是过于信任用户的输入，没有严格过滤用户的输入。

SSTI

SSTI服务器模板注入Server Side Template Injection

而服务端模板注入和常见Web注入的成因一样，也是服务端接收了用户的输入，将其作为 Web 应用模板内容的一部分，在进行目标编译渲染的过程中，执行了用户插入的恶意内容，因而可能导致了敏感信息泄露、代码执行、GetShell 等问题。其影响范围主要取决于模版引擎的复杂性。

简单的探测语句

1
2
3

{{2*2}}如果出来的是计算之后的结果，则表明可能存在注入。
personal_greeting=username 如果出来是用户名
{{config}}如果出来的是配置文件，则表明可能存在注入。

漏洞发生原因：
模板渲染的值受到用户控制，并且没有严格过滤用户的输入。

漏洞危害能从XSS甚至到RCE。

SSTI的有效载荷

自动检测工具tplmaptplmap

GET型 tplmap -u <url>/?<vulnparam>
POST型 tplmap -u <url> -d '<vulnparam>'

Payload

1

{{ ''.__class__.__mro__[2].__subclasses__()[40]()("<file>").read()}}

Payload2

1

{{config.__class__.__init__.__globals__['os'].popen("<commond>").read()}}`

业务逻辑漏洞

• 关键操作缺少确认机制

• 自动扫描程序无法发现此类漏洞

越权

分为水平越权，和垂直越权。
越权漏洞形成的原因是后台使用了不合理的权限校验规则导致的。

一般越权漏洞容易出现在权限页面（需要登录的页面）增、删、改、查的的地方，当用户对权限页面内的信息进行这些操作时，后台需要对当前用户的权限进行校验，看其是否具备操作的权限，从而给出响应，而如果校验的规则过于简单则容易出现越权漏洞。

水平越权

A和B属于同等级的用户，只能操作自己的信息。但是如果A能操作B的信息，那就是水平越权。

垂直越权

A的级别比B高，B无权执行A的操作，但是B能够操作A的权限的话，就是垂直越权。

越权漏洞可能发生的地方所有用户信息查询,修改,等页面.

如何挖?

确定业务流程—>寻找流程中可以被操控的环节—>分析可被操控环节中可能产生的逻辑问题—>尝试修改参数触发逻辑问题

修复方式

• 改用session

• 登录时再加验证

• 修改等操作加个判断当前用户是否有权限修改。

交易支付中的逻辑问题

1. 加入购物车时是否可以修改购买数量为负数?

2. 商品价格是否可以修改?

3. 确认购物车信息时是否可以修改商品数量为负数?

4. 是否存在折扣限制突破问题?

5. 是否可以修改商品总金额?

6. 输入物流信息时是否可以控制运费?如果可以,尝试修改为负数.

7. 确认订单后跳转支付接口时是否可以修改支付金额?

8. 可否不支付直接跳转到交易成功环节?

修改密码

首先走一遍正常的密码修改流程,把过程中所有环节的数据包全部保存.
分析流程中哪些步骤使用了哪些身份认证信息,使用了哪些认证方法.
分析哪个步骤是可以跳过,或者可以直接访问某个步骤.
分析每个认证方法是否存在缺陷,可否越权
首先尝试正常密码找回流程,选择不同找回方式,如邮箱,手机,密码提示问题等.
分析各种找回机制所采用的验证手段,如验证码的有效期,有效次数,生成规律,是否与用户信息相关联等.
抓取修改密码步骤的所有数据包,尝试修改关键信息,如用户名,用户ID,邮箱地址,手机号码等。

一次地级市某行业专项攻防演练的案例

2022-09-15

记一次前端安全测试

2022-09-14

记录一次实战，注入+本地JS绕过拿shell

2022-09-13