逻辑漏洞

参考：https://www.freebuf.com/vuls/281141.html

身份验证漏洞

暴力破解漏洞

攻击者可以通过该漏洞获取用户名和对应弱口令密码，并进行登录操作。

原理

由于没有设置登录失败次数限制，导致攻击者可以通过口令字典进行特定用户的密码爆破或通过用户名字典进行特定弱口令的用户枚举。

漏洞点

系统登录点

修复

对于固定用户名爆破密码，可以针对用户名进行错误次数计算，高于一定阈值账号锁定一段时间，或者添加验证码。但是不能永久锁定，可能被用来进行账户恶意锁定；

对于固定密码枚举用户名、 需要计算IP对URL的请求情况，若某个IP短时间大量请求登录则应该加入黑名单，对传输数据进行加密有一定的防护效果。

Session固定攻击

会话固定攻击是利用服务器的session不变机制，借他人之手获得认证和授权，然后冒充他人 。

原理

在请求登录过程时候，URL带有一个session，登录成功之后会将登录成功的信息绑定到这个session中，攻击者可以发送带有session的URL给相关工作人员诱导其登录，相当于获取了其身份信息。

漏洞点

在GET方法请求登录时候带有session值。

修复

避免在URL中带入session信息。

另外也要注意POST请求中带有sessionid进行session固定攻击，虽然可利用性比较低，但是建议修复。

cookie欺骗

通过伪造cookie信息能够伪造其他用户进行登录。

原理

开发者为了方便将身份信息/登录信息明文或者只是简单编码、哈希之后存放在cookies中，网站通过获取得到的cookies进行授权或者身份验证。

漏洞点

cookie中有明显或者只是简单编码、哈希的字段时候，比如修改lsLogin值为1可以判定为用户已经登录，修改cookie为asp163=UserName=admin可以获得管理员权限。

修复

Cookie不应该存储可理解的身份信息和登录信息 按照规定，cookie对身份信息和登录信息的存储只能通过存储足够长度的随机字符串进行，避免篡改。

逻辑越权漏洞

参考：

https://blog.csdn.net/huangyongkang666/article/details/123629813

https://www.freebuf.com/articles/web/195837.html

原理

越权访问（Broken Access Control，BAC），指应用在检查授权时存在漏洞，使得攻击者在获得低权限用户账号后，利用一些方式绕过权限检查，访问或者操作其他用户或者更高权限的用户。

成因

开发人员在对数据进行增删查改时，对客户端请求的数据过分相信而遗漏了权限的判定，权限验证不当而导致的越权行为。

通常情况下，一个 Web 程序功能流程是登录 - 提交请求 - 验证权限 - 数据库查询 - 返回结果。如果验证权限不足，便会导致越权。常见的程序都会认为通过登录后即可验证用户的身份，从而不会做下一步验证，最后导致越权。

• 隐藏URL
• 直接对象引用
• 多阶段功能
• 静态文件
• 平台配置错误

分类

水平越权

水平越权是指攻击者尝试访问与他具有相同权限的用户资源。

形成原因：在进行方法调用的时候未验证请求用户和目标信息拥有者是否匹配一致，而是直接用userid/email之类的容易遍历的参数进行数据库查询，导致攻击者利用了其他人的userid。

比如，用户A和用户B属于同一角色，拥有相同的权限等级，他们能获取自己的私有数据（数据A和数据B），但如果系统只验证了能访问数据的角色，而没有对数据做细分或者校验，导致用户A能访问到用户B的数据（数据B），那么用户A访问数据B的行为就叫做水平越权访问。

修复：利用getAttribute(“userid”)获取其userid，而不是直接接收userid参数，避免了userid参数传输。

以下是常出现的水平越权的几种场景：

• 基于用户身份ID

  在使用某个功能时，通过用户提交的身份ID（用户ID、账号、手机号、证件号等用户唯一标识）来访问或操作对应的数据。

• 基于对象ID

  在使用某个功能时，通过用户提交的对象ID（如订单号、记录号）来访问或操作对应的数据。

• 基于文件名

  在使用某个功能时，通过文件名直接访问文件，最常见于用户上传文件的场景。

垂直越权

垂直越权是指低权限用户尝试访问高权限用户的资源。

形成原因：由于后台应用没有做权限控制、角色校验，或仅仅在菜单、按钮上做了权限控制，导致恶意用户只要猜测其他管理页面的URL或者敏感的参数信息，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。

主要有以下两种场景：

未认证账号，访问无需认证就能访问该功能

不具备某个功能权限的账户，认证后能成功访问该功能

未授权访问

游客能够访问普通用户甚至超级管理员才能访问的系统信息或者系统功能，

产生原因：系统设计期间没有进行全局用户身份校验；或者校验存在缺陷。

业务数据篡改

概念：篡改一些参数的数值，达到获利的目的。

若是篡改验证用的判断参数，比如判断用户类型的userType，可能用于实现垂直越权；

若是篡改用户参数，比如手机号、身份证号，可能用于实现水平越权。

漏洞点：抽奖、购买、转账、返现等功能。

修复：

计算传输数据的哈希，并将哈希附加在传输数据中作为校验值，避免被篡改。

设置token。

执行顺序逻辑漏洞

概念：也是篡改参数，但是是通过篡改分步逻辑中的步骤数字，达到绕过支付、校验等效果。

原理：程序逻辑分布进行，但是对步骤、验证信息、支付信息没有做好严格校验，导致修改步骤就直接绕过验证或者支付。

漏洞点：任何分布逻辑且带步骤数字，或者利用JS进行步骤控制的功能中。

修复：

在请求最后一步时候需要带入前面的验证信息，服务端再进行一次校验信息的验证，验证正确方能继续执行数据操作；

也可以通过getAttributr(“userid”)获取userid进行userid和验证结果绑定，最后一步不带入验证信息，但是仍然要获取userid进行校验；

再最后一步通过验证之后或者服务器收到支付信息后再生成相应的数据交给用户。

验证码爆破

概念：抓包后重放，进行参数值遍历。可以用于突破图形验证码的验证，可以实现如登录爆破、个人信息爆破、验证码绕过等攻击。

修复：

• 验证码使用后立即重新生成
• 设置验证码有效期
• 验证码的部分仅使用图片，不使用字符串
• 不进行分布校验，而是连同请求数据一起发送到目标服务器进行校验

找回密码

概念：攻击者通过密码找回逻辑漏洞，可以重置他人账号密码，危害他人账号安全。

通过验证码找回密码的话，可以分为验证码漏洞的一种。

短信轰炸

实现：通过数据包重放实现。

原理：后台未进行相关操作的计数导致数据包重放。

其他逻辑漏洞

条件竞争漏洞

概念：可以通过同时重放大量数据包进行漏洞利用，通常用于突破限量、限额的问题都有奇效。

原理：由于目标函数中，判断与数据修复两个步骤之间，或者两个数据修改步骤之间存在时间差，且函数未进行同步锁定，则可以造成漏洞。

漏洞点：程序中存在限制，可以猜测到后台有判断与修改操作的方法

修复：使用synchronized关键字，可以限制同一时间内访问方法的只有单一线程

并不是每个条件竞争都必须修复。

数据包重放漏洞

概念：通过数据包重放，可以造成短信轰炸、邮件轰炸、重复提交订单等。

原理：后台未进行相关操作的计数导致数据包重放。

漏洞点：短信验证码、邮件校验、提交订单等功能。

修复：（针对短信、邮件）

构造一个Hashmap<String，short>，存放邮箱或电话号码及对应次数，只要某个邮箱或者电话号码次数够了，就不能继续发送了；或者计算两次发送的时间间隔，时间过短就不继续发送了

通用修复方案：

需要建立token机制或验证码机制，一次有效。

参数绑定漏洞

概念：通过添加对象字段相关参数进行数据篡改

原理：对象自动绑定被许多框架支持，它允许将HTTP请求参数自动的绑定到对象，开发者没有对其进行安全校验则容易导致数据篡改。

漏洞点：常见的所有输入的地方都会出现这个漏洞，特别是金融、用户、缓存等。

修复：Spring MVC中可以使用@InitBinder注释，通过WebDataBinder的方法setAllowedFields、setDisallowedFields设置允许或不允许绑定的参数。

举例（出现位置）

逻辑漏洞的问题可以分为前端和后端两个部分，总体思路都是先测试前端再测试后端。

注册处

注册功能可能出现任意用户注册、短信轰炸等问题。

以手机注册为例：

前端参数验证的漏洞

注册时BP抓包，查看每个返回包有没有返回手机验证码或者存在true、false之类的判断语句，尝试将false修改为true，成功注册的话就绕过了前端验证。

拦截返回的响应包：

任意用户添加

在未登录或者低权限的的情况下，利用数据包添加任意用户。

短信轰炸漏洞

尝试重放发送验证码的包，查看手机是否在短时间内收到了多条短信，是的话则存在短信轰炸漏洞，这是因为后端没有对发送手机短信做时间限制。

修改发送包手机号

首先用自己的手机收到正确验证码，在点击注册时拦截包将手机号改为其他手机号，如果成功的话就注册了别人的手机号，这是因为后端仅验证了验证码是否是正确的而没有验证验证码是否与手机匹配。

登陆处

登录处可能出现任意用户登录、验证码可绕过、用户账号可撞库等问题。

以手机验证码登录举例：

前端

对比正确登录和错误登录的包，对比返回包看是否有判断，尝试修改参数绕过前端验证。

修改cookie实现垂直越权

cookie的构造过于简单，可以分析出一部分参数，且通过前端JS文件可以判断出对该参数的校验。

比如发现前端文件内容如下：

1
2
3
4
5

function setCookie() //login_ok.htm use
{
	document.cookie="login=1";
	MM_goToURL('parent', 'home.htm');
}

那么将Cookie中的 login=1 则会以管理员身份跳转 home.html，成功绕过登录。

短信轰炸

与注册处测试步骤一样

验证码爆破

包括图片验证码和手机验证码。

先测试图片验证码，将使用正确验证码登录的包再重放一次，如果回显还是正确登录的话说明并没有对图片验证码进行限制，可以尝试撞库。

至于手机验证码，通常是尝试爆破，如果网站发到手机上的短信没有写什么在xx时间内有效之类的则有可能没有时间限制，将登录包右键发送至Intruder（即测试器模块）设置好爆破位置后在载荷里选择数值后这样填写。

通常范围是填写正确验证码所在的范围，爆破出来后就可以登录用户，对应着任意用户登录漏洞。

修改发送包手机号

修改发送包手机号则和上面注册处修改发送包手机号步骤一样，不同的是上面注册处是为了测试任意用户注册，而这里登录处是为了测试任意用户登录，原理一样目的不同。

修改用户参数

查看正确登录包的返回包是否有用户id之类的参数，尝试修改该参数。（不嫌麻烦的话可以用两个正确登录的返回包对比）

拦截该请求的返回包修改返回包中的用户参数。

密码找回处

密码找回处可能出现任意用户密码找回、验证码可绕过等问题。

以手机验证码找回为例：

前端

同样是修改返回包看是否能跳过验证步骤。

验证码爆破

验证码爆破与上面登录处的验证码爆破操作一致。

修改发送包手机号

与上面注册处的修改发送包手机号操作一致

支付与越权

可以使用两个账号来对比测试，这样可以更快发现可疑参数。

支付接口指的是网站支付一般会有像微信支付、支付宝支付这种，一般网站会在支付的发送包里用某个参数标识。

登录时查看并测试用户信息返回接口指的是，在登录的时候，有的网站有个返回包是一个json数据包，该包内包含了用户敏感信息，此时就可以尝试修改发送包的用户参数，说不定就能获取其他用户的敏感信息。

权限框架缺陷

权限控制框架是实现权限控制功能的基础（例如shiro），如果权限控制框架本身存在缺陷，那么就会导致权限控制功能完全失效。

SRC中逻辑漏洞总结

1. 注册：

   1. 短信轰炸
   2. 验证码安全问题
   3. 密码爆破
   4. 邮箱轰炸

2. 用户任意注册、批量注册

3. 用户名枚举

4. XSS（有框的地方就可以尝试插XSS）

5. 登录：

   1. 短信轰炸、验证码安全问题、密码爆破、邮箱轰炸
   2. SQL注入
   3. 撞库
   4. 抓包把password字段修改为空值发送
   5. 认证凭证替换、比如返回的数据包中包含账号，修改账号就能登录到其他账号
   6. Cookie仿冒
   7. 修改返回包的相关数据，可能会登陆到其他的用户

6. 找回密码：

   1. 短信邮箱轰炸、短信邮箱劫持
   2. 重置任意用户账户密码、验证码手机用户未统一验证
   3. 直接跳过验证步骤

7. 购买支付、充值（要利用抓包去仔细查看每一个可用的参数）

   1. 交易金额、数量修改、更换支付模块（比如更换支付的模块金额）
   2. 交易信息订单编码/导致信息泄露
   3. 整数溢出，int最大值为2147483647，超过最大值
   4. 修改充值账户
   5. 支付绕过

8. 抽奖活动

   1. 刷奖品、积分
   2. 并发

9. 优惠卷、代金卷

   1. 并发逻辑漏洞（burp批量获取优惠券）
   2. 修改优惠券金额、数量

10. 订单信息

    1. 订单信息遍历、泄露
    2. 订单信息泄露导致用户信息泄露
    3. 删出他人订单

11. 会员系统

    1. 修改个人信息上传文件，上传带弹窗的html
    2. 如遇上上传xlsx、docx，可能存在XXE，上传恶意的文档盲测
    3. 图片上传也可能遇到imagereagick命令执行，上传恶意图片
    4. 视频上传如果使用ffmpeg<3.2.4（视频按帧分割成图片），上传恶意avi盲测ssrf
    5. 用户横向越权访问、遍历、导致用户信息泄露
    6. SQL注入、个人简历处存储XSS个人信息注册的名称也可以插入XSS

12. 传输过程

13. 明文传输账户密码

14. 修改信息处无session/token导致csrf

15. POST/COOKIE注入

16. 评论

17. POST注入

18. 存储型XSS

19. 无session/token导致CSRF

20. 验证码问题

    1. 万能验证码
    2. 返回包中存在验证码
    3. 删除验证码或者cookie中的值可以爆破账号密码

21. 短信轰炸

    1. 一直重放
    2. 删除修改cookie，重放数据包
    3. 遍历参数发送数据包
    4. 手机号后面加空格或者前面加其他的比如+86或者逗号分号等，然后重发数据包
    5. 请求参数修改大小写，或者添加请求参数比如&id=1
    6. 一个站的登录处可能做了防护，但是再找回密码处可能没有安全防护，或者在注册流程中没有安全防护，所以说多测试接口
    7. 如果对手机号一天的次数进行了限制，还可以再发一次短信，DO intercept之后修改为成功回显

22. 水平越权

    1. 主要登陆后还是修改参数，主要找到多个接口不断测试
    2. 关注网页源代码，有时候会有表单，但被bidden（隐藏标签）给隐藏起来了，可以修改返回包然后尝试获取数据检测
    3. 多个账号，主要分析请求参数

23. 数据泄露

    在找回密码处，填写数据后抓包查看返回信息，有可能存在敏感数据返回

24. 任意用户密码重置

    1. 目前大部分都是在修改密码处参数修改
    2. 有些是前端验证

支付逻辑漏洞

1. 边界值问题 : 正常的逻辑是用户购买商品，然后价格累加得到一个总价进行扣款。这个时候就会产生逻辑问题：如果说用户购买的商品是负数了，那么计算的总数就是负数。反过来钱给用户
2. 顺序执行缺陷：正常的逻辑是a-b-c-d 循环渐进的进行流程操作。这个时候就会产生逻辑问题：可以直接从中绕过某一个过程进入到下一步操作。如果说有一项是支付的操作，那么也就会产生支付绕过，如果说有一项是验证机制，就会绕过验证直接进入下一步。
3. 金额直接传输导致篡改：直接对下单的金额进行修改值，这里可以使用fd或者burp抓包
4. 确定支付之后还可以加入购物车：把商品放入购物车点击下单支付，会跳转到微信，支付宝等第三方支付平台。这个时候还可以继续在购物车中加入商品，支付结束之后，商家发放的商品是现在的购物车里面的东西。
5. 请求重放：购买成功之后，继续重放请求，可以让购买的商品一直增加。购买成功之后，会有一个银行对商户网站跳转的过程，如果反复进行操作，有几率会导致商品反复购买和增加，但是不需要付更多的钱。
6. 请求参数干扰：金钱做了签名认证之后，修改后不通过，但是在里面仍然会有一个参数对金额产生影响导致问题产生。
7. 订单替换：订单替换发生在支付之后的事件处理，同时向服务器发起二次支付请求一个多一个少，支付金额少的，然后支付之后进行替换，告知服务器订单支付完成，并且过程可以反复的回放。
8. 欺诈:需要两个收款人，一个是正常的商家，一个是伪造的商家
9. 单位替换：产生在paypal类似的国际支付的场景。
10. 用户替换：在支付过程中发生用户替换现象，首先登陆自己的账户，然后取得另外一个人的账户名等有效信息，在业务流程中用对方的用户名替换自己的用户名，用对方的余额购买完成后，再替换自己的账户名，这样就形成别人的钱买自己的东西
11. 强制攻击：强制攻击发生在暴力破解的情况下，如果一个商家运用一个自己的网店，接入第三方支付接口，由于设计上的不当导致商家与第三方支付约定的密钥Key可以单独被MD5加密，导致可以使用MD5碰撞技术对密钥进行破解，攻击者可以设计简单的密钥加密信息使得MD5加密是可以用MD5碰撞技术进行暴力破解。
12. 秘钥泄漏：内置支付功能的app为了设计上的方便有可能会把Md5或者是RSA的私钥泄漏导致攻击者反编译apk之后获取密钥信息使得交易信息可以被篡改。
13. 函数修改：apk反编译之后的函数修改，可能导致商家在最后一步向支付方提交订单时未验证信息的准确性，仍然被篡改。
14. heart bleed：SSL（安全套接层）协议是使用最为普遍网站加密技术，而OpenSSL则是开源的 SSL 套件，为全球成千上万的web服务器所使用。Web服务器正是通过它来将密钥发送给访客然后在双方的连接之间对信息进行加密。URL中使用 https打头的连接都采用了SSL加密技术。在线购物、网银等活动均采用SSL技术来防止窃密及避免中间人攻击。

该漏洞被归为缓冲过度读取。缓冲过度读取错误是软件可以读取比应该被允许还多的数据。漏洞让特定版本的openSSL成为无需钥匙即可开启的“废锁”，入侵者每次可以翻检户主的64K信息，只要有足够的耐心和时间，就可以翻检足够多的数据，拼凑出户主的银行密码、私信等敏感数据。产生原因：数据在传输的两端是不加密的。一些数据如果在传输过程中不加密则会泄露个人数据等信息。

1. 修改返回包的越权

   1. 修改手机号

   一般的逻辑为：认证原手机号-> 填写新手机号-> 提交修改

   如果在下一步操作时，没有校验上一步的认证是否成功时，就会存在逻辑缺陷绕过

   比如在进行第一步认证原手机号时，随意输入验证码，将response包中的相关字段进行修改，比如0改成1，false改成true，即可绕过第一步验证，进入填写新手机号界面，如果第三步提交修改时没有验证第一步的结果，就会造成逻辑漏洞

2. 登录绕过

   部分网站的身份验证放在了前端，因此只需要将response包中的相关字段进行修改，比如0改成1，false改成true，就可以登录任意用户账号

3. 水平越权

   1. 遍历ID

      在一些请求中，GET和POST中有明显的ID数字参数（手机号、员工号、账单号、银行卡号、订单号等等），可以尝试进行遍历，如果程序没有对当前权限进行判断，就会存在水平越权问题

   2. ID替换

      如果程序对用户标识进行了hash或者加密，而无法破解用的什么方式的话，就无法通过遍历ID来获取其它用户的信息了，此时可以尝试注册两个账号，通过替换两个ID加密后的值，判断程序是否对权限进行了验证，如果没有，也会存在越权问题

   3. 垂直越权

      观察cookie中的session字段，可能某些字段或者参数代表身份，尝试修改

防范措施

采用成熟的权限管理框架（如spring security）

验证用户是否具有操作数据的权限

用户进行访问操作的凭证（如用户ID、产品号码、订单流水号等）优先采用在服务端关联session或加密后放在session中的方式获取

应对用户凭证（如用户ID、产品号码、订单流水号等）采用难以猜测的构造方式（如随机数）或采用复杂的加密算法加密后再提交

对管理功能模块进行严格的权限验证