逻辑问题的基本知识总结&越权&支付&验证码&弱口令

最新推荐文章于 2024-07-17 11:29:00 发布

小狗学士

最新推荐文章于 2024-07-17 11:29:00 发布

阅读量984

点赞数 18

分类专栏： web安全文章标签： web安全安全

本文链接：https://blog.csdn.net/c0529/article/details/139414136

版权

web安全专栏收录该内容

33 篇文章 0 订阅

订阅专栏

1.权限问题

1.1越权问题

垂直越权和水平越权，垂直越权的危害要比水平越权更大

1.2访问控制

一般我们遇到了越权问题常常是代码逻辑上的问题，大致有以下三种
- 有验证，但是由于逻辑问题，变成了顺序上问题，先处理这个操作再跳转验证
- 有验证，但是验证凭证脆弱，可以用某些方法绕过（比如jwt验证使用了null加密，或者秘钥简单，容易爆破）
- 没验证，常常出现在某一个文件没有导入验证文件

1.3黑盒白盒测试

黑盒：根据功能来跟踪，或者使用相关工具
白盒：排查文件的导入，文件的逻辑，以及可以使用工具创建高等级用户，普通用户去排查是否有权限上的区别

2.购买与支付

2.1购买与支付常见的流程

找到需要购买的商品和数量->选择商品，确定金额，确定数量->确定订单创建订单->跳转订单页面进行支付->调用三方接口
购买中还容易产生：折扣券的使用，折扣券的领取
我们简单总结一下这个过程中涉及的变量：
商品id，数量，商品金额，订单id，订单的金额，三方接口，折扣券id
这些变量中不少事用户从前端传输的

2.2 针对变量容易产生的问题

商品的金额在前端传输还是后端设定，前端传输很可能让数据在传输到后端时改变
- 商品的数量，没有对于数量的设定后端规则，让用户传输负数，小数点
- 订单id和订单金额不绑定，让用更少的金额支付订单
- 折扣券可以重复的领取和使用，猜解折扣券的id号，使用未领取折扣券
- 三方接口，改变接口的相关设定，后端没有验证端口，导向了攻击者准备好的支付接口

2.3 修复与挖掘

黑盒白盒：主要都依靠功能去观察逻辑
修复:
- 将商品的金额固定在数据库，每次的取用都从后端调用，不要从前端接收
- 商品的数量在后端应该做过滤
- 订单id和订单金额固定在一起
- 折扣券的id使用更加随机和加密的格式，使用后删除
- 三方接口要后端再过滤

3.密码找回，手机登录，验证码

3.1 密码的找回与手机登录的机制

一般密码的找回都需要和手机号码进行验证码，所以这里手机登录我也一起分类了
确定找回账号->输入手机号->输入一层验证码->手机收到验证码->填写验证码->检查验证码是否正确->完成密码重置或者登录成功
在这个过程中容易出现的问题：
- 在前面都通过的情况下在最后重置的时候提交不同的用户数据，重定向用户，完成对于任意用户的密码修改
- 手机收到验证码，但是检查验证码的时候，respond验证码的明文，验证就没用了
- 检查验证码是否成功是在后端进行的，传递到前端是状态码，由前端进行是否跳转下一步，通过修改返回的状态码，我们就可以绕过验证码检测
- 验证码本身简单，没有时间效用，和使用的次数，在一层验证码不影响的情况下，攻击者可以用爆破方式通过检测

3.2 一层验证码

一层验证码常出现以下情况：
- 一个验证可以多次使用，上一个找回可以完成验证码的爆破
- 验证码识别，当验证码形式简单传统，可以用工具识别
- 以上这两个问题都会造成一个情况：接口得到任意调用，也就是无限制的给固定手机号码发送信息，也就是短信轰炸，不法分子收集这种接口可以任意调用的位置，利用网站资源去发送消息

3.3 防护

找回与手机登录：
- 绑定用户权限，防止重定向
- 不显示验证码原文
- 不用前端验证方式
- 采用验证码具有时效性，可以输入的次数
一层验证码：
- 每发送一次消息和表单就更新验证码
- 验证码识别采用更加不容易被识别的，比如steam的，滑动滑块的
- 在调用接口的时候要验证

4.弱口令

使用了一些弱口令去登录服务器，网站，协议等等

4.1 原因

主要有两类：
- 安全意识不足：
- 使用的密码简单，容易被暴力破解
- 多个网站使用的密码固定，或者有某种规律，通过信息收集，社工库等方式猜解
- 初始化：
- 在使用服务器和网站保留了初始化的信息，没有及时修改密码（这个真的是很多人会干的事，大学学校办的网站就有很多人用的是初始化密码）
这些决定了弱口令问题出现在多个方面：网站登录，中间件登录，三方组件登录，各种类型文件加密，各种服务协议