网络信息安全笔记—逻辑漏洞_平行权限

逻辑漏洞简介

​逻辑漏洞是指攻击者利用业务/功能上的设计缺陷，获取敏感信息或破坏业务的完整性。一般出现在密码修改，越权访问，密码找回，交易支付金额等功能处。​ 逻辑漏洞的破坏方式并非是向程序添加破坏内容，而是利用逻辑处理不严密或者代码问题或固有不足，操作上并不影响程序的允许，在逻辑上是顺利执行的。​ 这种漏洞一般防护手段或设备无法阻止，因为走的是合法流量也没有防御标准。

逻辑漏洞被称为“不安全的对象引用，和功能级访问控制缺失”。现如今，越权和逻辑漏洞占用比例比较高，包括任意查询用户信息，重置任意用户密码，验证码爆破等。

逻辑漏洞的重要性

​常见的OWASP漏洞，通过漏洞扫描工具，大多支持自动化或者半自动化扫描出来，并且传统的安全设备或者防护措施收效甚微。但逻辑漏洞是和系统自身功能和逻辑有关系的漏洞，每一家的漏洞出现可能存在一定的独特性，很难复制或者通过规则脚本和漏扫工具扫描出来，因此逻辑漏洞大多需要配合代码审计和手段测试才可以发现相关漏洞，也是工具无法代替人工的漏洞。

逻辑漏洞分类

越权访问漏洞

单点登陆

越权访问时web应用程序中一种常见的漏洞，由于其存在范围广，危害大被OWASP列为web应用十大安全隐患之一，该漏洞是指应用在检查授权时存在纰漏，使得攻击者在获得地权限用户账户后，利用一些方式绕过权限检查，访问或者操作其他用户或者更高权限。越权漏洞的成因主要时因为开发人员对数据进行增、删、改、查时对客户端请求的数据过分相信而遗漏了权限的判定，一但验证不充分，就容易出现越权漏洞。

不安全的对象引用指的是平行权限的访问控制缺失，即水平越权：

A,B同为普通用户，他们之间彼此之间的个人资料应该相互保密的，A的资料如果被B用户利用程序访问控制的缺失而已查看，这就是水行权限的关系。

功能级别访问控制缺失指的是垂直权限的访问控制缺失，即垂直越权：

低权限用户访问到了高权限用户，比如普通用户可以执行管理员才可以执行的操作 等于想干嘛干嘛。A是普通用户，B是管理员，B的页面登录访问需要密码和token.A账号能直接输入管理页面URL的方式绕过管理员登录限制查看管理员页面，这个时候A,B就是垂直关系。

越权漏洞产生原因

水平越权和垂直越权的定义不一样，但漏洞的原理都是一样的，都是账户体系上在判断权限时不严格导致存在绕过漏洞，这一类的绕过通常发生在cookie验证不严，简单判断用户提交的参数，归根截底，都是因为这些参数在客户端提交，服务端未严格校验

• 通过隐藏URL
  实现控制访问有些程序的管理员的管理页面只有管理员才显示，普通用户看不到，利用URL实现访问控制，但URL泄露或被恶意攻击者猜到后，这会导致越权攻击
• 直接对象引用
  这种通过修改参数就可以产生水平越权，例如查看用户信息页面URL后加上自己的id便可查看，当修改为他人的id号时会返回他人的信息，便产生了水平越权
• 多阶段功能
  多阶段功能是一个功能有多个阶段的实现，例如：修改密码，可能第一步是验证用户身份信息，号码验证码类的，当验证成功后，跳到第二步，输入新的密码，很多程序会在这一步不在验证用户身份，导致恶意用户抓包直接修改密码
• 静态文件
  很多网站的下载功能，一些被下载的静态文件，例如pdf、word、xls等，可能只有付费用户或者会员才可以下载，但当这些文件的URL地址泄露后，导致任何人可下载，如果知道URL命名规则，则可利用服务器的收费文档进行批量下载。
• 平台配置错误
  一些程序通过控件来限制用户访问，例如后台地址，普通用户不属于管理员组，则不能访问。但当配置平台或配置控件错误时，就会出现越权访问。

越权漏洞修复建议

1.前后端同时对用户输入信息进行校验，双重验证机制
2.执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限
3.特别敏感操作可以让用户再次输入密码或其他的验证信息
4.可以从用户的加密认证cookie中获取当前用户的id防止攻击者对其修改，或在session、cookie中加入不可预测、不可猜解的user信息
5.直接对象引用的加密资源ID，防止攻击者枚举ID敏感数据特殊化处理
6.永远不要相信来自用户的输入，对于可控参数进行严格的检查与过滤

密码改回

即密码修改/重置，顾名思义，就是修改原来的密码

• 途径：
  1.一个网站，一般我们可以登录进入个人中心直接修改密码
  2.当我们忘记密码是还可以使用系统自带的密码找回功能进行密码修改
  • 什么是密码修改/重置漏洞
    密码重置这个功能本身没有问题，但如果对密码重置功能的验证机制不够完善就形成了漏洞
  • 密码修改/重置的成因
    • 基于修改密码的
      如果后台没有对旧密码进行验证，就直接让输入新密码
      1.第一种，如果存在csrf漏洞我们就可以直接修改一波
      2.如果存在越权漏洞就可以直接修改其他人的密码
      3.点击修改后抓包测试，观察数据包有没有验证类似cookie随机数，如果没有的话可以尝试修改用户名，手机号或者uid来尝试重置其他密码
      ​ 如果后台是通过向注册手机或者注册邮箱来重置密码的，关于验证码的漏洞我们都可以尝试，这种方式的前提是你已经通过某种方式进入到了对方的个人中心所以意义不大。
    • 基于找回密码的
      一般情况下当我们点击找回密码的时候都是通过验证手机号或者邮箱，这就又变成了验证码的问题
      • 1.验证码发送后前端返回
      • 2.验证码时效导致验证码爆破
      • 3.验证码有规律可控
      • 4.验证码被放回在返回包中
      • 5.输入验证码后通过修改响应包的状态来重置密码
      • 6.验证码为空（原理就是后台未考虑验证码为空的情况，直接就是如果存在，然后下面仅判断了存在的情况）绕过过或使用万能密码
      • 7.拦截数据包，发送验证码时可以向多个手机号发送验证码，这个时候就可以添加个云短信，直接接受验证码完成修改
• 密码找回
  大纲如下图所示：
  
  密码找回是出现逻辑漏洞问题最多的一个地方，因为它的交互流程最多，目前找回密码的方式一般都是通过验证问题，验证邮箱，验证手机号码，等操作进行找回。
  基本步骤:
  • 先尝试正确的密码找回流程，记录不同找回方式的所有数据包
  • 分析数据包，找到有效数据部分
  • 推测数据构造方法
  • 构造数据包验证猜测
• 简单案例：
  • 1，邮箱验证：
  • 一般是点击邮件中的链接后会转跳到修密码的页面，这就需要分析链接的token构造了，
    可以考虑是时间戳md5、用户名或邮箱和随机字符串md5等，一般是类似如下链接：
    php?u=xiaoming&token=MTIzQHFxLmNvbQ==
    php?id=374&token=2ad64bf14c714dbce88c7993663da7da
    当构造相应链接时就可以重置任意用户的密码
  • 2，手机短信验证：
    短信找回一般就是4位或6位验证码，暴力猜测
  • 3，无需验证，直接修改：
    在修改密码时跳过选择找回方式，直接访问修改密码的页面进行修改
  • 4，本地验证：
    随意输入一个验证码，开Burp抓包，forward，抓返回包，返回包里可能有一个token字段，若token的值为1则跳转到修改密码页面，所以只要修改返回包即可。
  • 5，服务端将验证码返回给浏览器：
    在点击获取验证码时，服务器会将验证码发送给浏览器，抓包即可
  • 6，验证码直接出现在url中：
    当点击获取验证码时发出的请求链接中直接有code,或者直接在源代码里面。
  • 7，密保问题找回：
    回答密保问题，有时一些答案就在html源码里
  • 8，找回逻辑错误：
    若恶意用户A用15123333333找回密码，此时收到验证码但不使用
    此时恶意用户A再用受害者B的手机号找回密码，用户A在B的验证表单填入自己收到的验证码，发送，此时跳转的修改密码页面修改的就是用户B的密码
  • 9，无需旧密码验证：
    修改密码，发现不需要输入原来的旧密码，直接设置新的密码，这个时候就直接存在了csrf漏洞，构造链接，直接就修改了php?token=2&username=test&password=tst
• 输入用户名/邮箱/手机阶段
  交互过程;即输入要重置账户信息点击确定时，大部分应用都用会直接从数据库中读取用户邮箱和手机信息，并且发送验证码，还有部分程序在输入用户名后，会提示使用手机还是邮箱找回密码
  在提交的时候可以直接抓包修改手机或者邮箱参数，这是如果后端没有做验证，原本发送给账户A的验证码就会发送到被我们篡改的手机或者邮箱上，利用接收到的验证码即可重置密码
  • 填写验证码和新密码阶段
    填写验证码和新密码就意味着我们已经拿到了验证码或者重置密码的URL这里存在的问题有
    1.验证凭证较简单，可以暴力破解
    2.验证凭证算法简单，凭证可预测
    3.验证凭证直接保存在源码里
    • 验证凭证较简单，可以暴力破解
      目前大多数手机短信重置密码的验证码比较简单4位或6位数字如果提交验证码的地方没有对这个验证码进行错误次数限制，则会存在可以爆破的问题，这是 目前比较常见的一种密码找回方式
    • 验证凭证算法简单，凭证可预测
      部分网站找回密码的Token是根据当前用户的 “用户名”+“邮箱”或者时间戳进行一次MD5后生成，这就存在一定的预测性，利用自己写的算法去碰撞即可拿到重置密码凭证
    • 验证凭证直接保存在源码里
      目前这种比较少，不过也存在一定比例，一种是在点击发送验证码的时候就可以直接在源码里看到给当前手机或者邮箱发送过去的验证码，还有一种就是在输入验证码的时候源码里面就直接保存了正确的验证码
  • 发送新密码阶段
    凭证未绑定用户：我们在找回密码的时候发送到邮箱的链接通常是如下这个样子
    http:///www.xxx.com//user.php?m=repwd&uid=用户ID&key=凭证密钥&email=邮箱
    当请求这个链接的时候，后端程序根据uid和key对应上了从而判断这个找回密码的链接是否有效，但是在将新密码提交到服务器的时候
    服务端并没有判断当前这个key是否跟uid或者email匹配，而是直接修改掉了uid或者email指定的用户密码这样我们只要拦截修改密码的请求包，将里面用户参数修改成我们要篡改密码的用户账户即可
  • 密码找回漏洞修复建议
    1.接受验证码的邮箱和手机号不可由用户控制，应该直接从数据库中读取出来
    2.加强验证凭证复杂度，防止暴力破解
    3.限制验证凭证错误次数，单个用户在半个小时内验证码错误三次，半小时内精致找回密码。
    4.验证码凭证设置失效时间
    5.验证凭证不要保存在页面
    6.输入用户邮箱或ID，手机号取验证凭证的地方需要设置验证码防止短信炸弹和批量找回等
  • 找回漏洞修复建议
    1.接受验证码的邮箱和手机号不可由用户控制，应该直接从数据库中读取出来
    2.加强验证凭证复杂度，防止暴力破解
    3.限制验证凭证错误次数，单个用户在半个小时内验证码错误三次，半小时内精致找回密码。
    4.验证码凭证设置失效时间
    5.验证凭证不要保存在页面
    6.输入用户邮箱或ID，手机号取验证凭证的地方需要设置验证码防止短信炸弹和批量找回等
    7.验证凭证跟用户名、用户ID、用户邮箱绑定、找回密码是验证当前凭证是否是当前用户的
• 验证码漏洞
• 支付漏洞
  攻击者通过修改交易金额、交易数量等从而利用漏洞，如Burp修改交易金额、使交易数量为负数或无限大等。
  1、支付过程中可直接修改数据包中的支付金额
  金额后端没有做校验，传递过程中也没有做签名，导致可以随意篡改金额提交。
  2、没有对购买数量进行负数限制，购买数量无限大，
  无限大时则程序可能处理出错，从而实现0金额支付
  3、请求重放，实现”一次购买对此收货”
  4、其他参数干扰
  在支付时直接修改数据包中的支付金额，实现小金额购买大金额商品
  修改购买数量，使之为负数，可购买负数量商品，从而扣除负积分，即增加积分，
  或使购买数量无限大，无限大时则程序可能处理出错，从而实现0金额支付
  请求重放，在购买成功后重放请求，可实现"一次购买对此收货"
  基本案例：
  • 案例一，会员注册用户：
    test
    test
    验证码0566
    登录密码没有验证码，可以直接暴力破解用户名和密码，因为服务端没有及时销毁，就可以使用burp批量注册，每个参数都可能存在逻辑漏洞，修改参数，看能不能提交成功。
    burp发送到爆破，变量，username,password，email
    然后加载3个字典，批量注册了，发现响应都是200,证明存在这个漏洞
    这个时候所有的用户都可以登陆
    修改密码：
    1234567
    1234567
    拦截数据包，查看参数值，发现当我们把用户修改成别人的，然后可以修改成功，这个时候越权漏洞就产生了。
    投票系统：
    我们抓包，删除cookie信息，或者是ip地址判断的
    然后使用burp跑字典
  • 案例二：后台地址，访问，提示不能直接访问，查看源代码，发现后台是referer判断，这个容易绕过，burp抓包，然后进到了后台页面，
    然后找到数据备份，找到referer,
    然后普通用户，添加referer伪造地址，
    接着看到了script限制，我们使用chrome,不允许script，然后重新访问
    就直接突破了，这个不能使用firebox
• 投票/积分/抽奖
• 短信轰炸

逻辑漏洞的挖掘

基本步骤:

1，先尝试正确操作流程，记录不同找回方式的所有数据包
2，分析数据包，找到有效数据部分
3，推测数据构造方法
4，构造数据包验证猜测

比如说，加入购物车，我是不是可以修改购买的数量，修改成负数，商品的价格是不是可以修改；
确认购物车信息时，是不是可以修改商品的数量为负数，是不是可以突破打折的限制；
输入运费，可不可以被修改；
确认订单后，能不能直接修改支付金额，可否不支付直接跳转到交易成功；

逻辑漏洞的利用

• 用户凭证暴力破解：
  四位或者六位的纯数字，无需验证码，直接burp爆破；
  四位或者六位的纯数字，需要验证码，但是验证码没有及时撤销，也可以直接burp爆破；
  四位或者六位的纯数字，需要验证码，但是验证码没有及时撤销，也可以直接burp爆破；
  如果验证不是很验过，burp抓包，在后面手机号后面添加特殊字符绕过第一次防御
  • 防御手段
    防御----对它提交的次数做一个过滤
    防御----只要尝试超过三次，就加入黑名单
• 返回凭证：
  burp抓包的时候，url返回验证码及token，时间戳的md5，修改token为1或0，绕过凭证。
  • 修复建议：
    对激活邮件限制发送次数
    越权其他用户信息:
    登录抓取cookie信息，有手机号码在Cookie
    这个时候，我们修改cookie中的手机号，查看其他用户的信息

认证

一个验证凭证的过程，载体如帐号密码，cookie（session）、token，数字证书，手机验证码。一般分为登录过程的认证与保持登录的认证。

会话管理

HTTP协议是无状态无连接的协议，服务端对于客户端每次发送的请求都认为它是一个新的请求，上一次会话和下一次会话没有联系。
即在切换页面保持登录状态的认证过程即是会话管理，对用户透明。

单因素认证与密码强度

长期以来，网站的建设者认为持有正确密码的用户是可信的，需要防御的仅仅是弱口令的问题。

凭证填充攻击

凭证填充是自动注入用户/密码对以欺骗性地获取用户权限、这是暴力攻击的一个子集，大量益处的凭据会自动输入网站，直到它们与现有账户相匹配。
一家公司受到凭证填充攻击，不一定表示它自身的安全已受损（或密码强度不足），通常关联为一个网站沦陷。

非登录过程的认证

• 基于session的认证
• 基于token的认证
  

证书验证