逻辑漏洞基础

访问控制

在某种程度上来说，信息安全就是通过控制如何访问信息资源来防范资源泄露或未经授权修改的工作。
访问控制（Access Control）指系统对用户身份及其所属的预先定义的策略组限制其使用数据资源能力的手段。通常用于系统管理员控制用户对服务器、目录、文件等网络资源的访问。访问控制是系统保密性、完整性、可用性和合法使用性的重要基础，是网络安全防范和资源保护的关键策略之一，也是主体依据某些控制策略或权限对客体本身或其资源进行的不同授权访问。
访问是主体（Subject）和客体（Object）之间的信息流动，访问控制的主要目的是限制访问主体对客体的访问，从而保障数据资源在合法范围内得以有效使用和管理。为了达到上述目的，访问控制需要完成两个任务：识别和确认访问系统的用户、决定该用户可以对某一系统资源进行何种类型的访问。

访问控制三个要素

访问控制包含三个要素，即主体、客体和访问控制策略。

主体（Subject）是指访问中一个发出请求或要求的主动实体，可以是某个用户，也可以是用户启动的程序、进程或设备等；
主体访问客体通常需要4个步骤：

Identification        身份标识
Authentication        身份验证
Authorization        授权
Accountability        审计
客体（Object）是接受其他实体访问的被动实体，凡是可以被操作的信息、资源、对象都可以被看作客体，可以是文件、光盘、数据库等。
控制策略（Attribution）是主体对客体的访问规则集，限制主体对客体的访问权限。

访问控制模型

访问控制模型是规定主体如何访问客体的一种架构，目前主要分为三种：

自主访问控制（Discretionary Access Control,DAC,大部分使用）
由客体的属主自主的对客体进行管理，自主的决定是否将访问权限授予其他主体。
该控制模型与所有数据和权限被操作的系统控制不一样，允许用户控制自己的数据的访问权限，根据用户的身份以及他们所属的分组来限制对对象的访问权限。用户可以通过ACL 定义什么人或什么等级的人可以访问什么资源，每一个ACL都包含一个用户和组的列表，以及它们的访问权限。
缺点：主体权限太大就可能泄露信息；当用户的数量多、管理数据量大时，ACL就会很庞大，不易维护。
强制访问控制（Mandatory Access Control, MAC）
安全策略由管理员配置，访问控制由系统实施，安全策略高于一切的存在。
该控制模型是非常严格的访问控制模型，起初由政府和军方设计并使用。所有的权限由管理员预定义，并且由操作系统控制，实现了数据的权限分类和用户的权限分类，在验证的时候可以对比用户和数据的权限等级对应关系，从而知道是否有访问权限。
缺点：管理不便，不够灵活，而且过重强调保密性，对系统连续工作能力、授权的可管理性方面考虑不足。
角色型访问控制（Role-Based Access Control, RBAC）
使用集中管理的控制方式来决定主体和客体如何交互，更多的用于企业中，根据不同的职位来分配不同的权限。
用户被分配一个角色，而它只能拥有角色里包含的权限，没有可以绕过的方法，通过角色分离了工作职责。

什么是逻辑漏洞

随着网络安全法的实施、企业和用户安全意识的提高,Web安全已经成为了重点关注的方向。诸如使用安全开发框架、部署安全防护设备等防护手段的使用，使得网站的常规漏洞越来越少。以SQL注入为例，由于其危害巨大，常年稳居OWASP Top 10的第一位，目前很多Web开发框架在底层就直接杜绝的SQL注入问题。
但“逻辑漏洞”一词现在却更加热门，很可能成为Web漏洞的主战场。之所以称之为“逻辑漏洞”，是因为在代码之后是人的逻辑，人更容易犯错，是编写完程序后随着人的思维理解产生的不足，所以逻辑漏洞一直都在。 
相比SQL注入、XSS漏洞等传统安全漏洞，SQL注入、XSS等漏洞可以通过安全框架等避免，并且攻击流量非法，对原始程序进行了破坏，防火墙可以检测；所以现在的攻击者更倾向于利用业务逻辑层的应用安全问题，逻辑漏洞就是指攻击者利用业务的设计缺陷，获取敏感信息或破环业务的完整性。一般出现在密码修改（没有旧密码验证）越权访问、密码找回、交易支付等功能处。而且由于逻辑漏洞产生的流量多数为合法流量，传统的安全防御设备和措施收效甚微，一般的防护手段或设备无法阻止，这类问题往往危害巨大，可能造成了企业的资产损失和名誉受损，所以导致了逻辑漏洞成为了企业防护中的难题。

逻辑漏洞分类

验证机制缺陷

会话管理缺陷

权限管理缺陷

业务逻辑缺陷

验证机制

在网络中，身份是区别于其他个体的一种标识，为了与其他个体有所区别，身份必须具有唯一性。网络中，身份不仅仅用于标识一个人，也可以用于标识一个机器、一个物体，甚至一个虚拟的东西（如进程、会话过程等）
网络中的认证不是对某个事物的资质审查，而是对事物真实性的确认。身份认证的目的是鉴别通信中另一端的真实身份，防止伪造和假冒等情况发生。
根据身份认证的对象不同，认证手段也不同，但针对每种身份的认证都有很多种不同的方法。
如果被认证的对象是人，则有三类信息可以用于认证：

Who knows:        某人所知道的内容，这类信息通常理解为口令
Who has:        某人所拥有的物品，这类信息包括密码本、密码卡、U盾
Who is:        某人的身份，这类信息包括指纹、虹膜、脸型、语音特征等
一般情况下，对人的认证只需要一种类型的信息即可，如口令（常用于登录网站）指纹（常用语登录电脑和门禁设备）、U盾（常用于网络金融业务），而用户的身份信息就是该用户的账户名。

如果被认证的对象是一般的设备，则通常使用“挑战—应答”机制，即认证者发起一个挑战，被认证者进行应答，认证者对应答进行检验，如果符合要求，则通过认证；否则拒绝。
验证机制是信息系统安全机制中最简单、最前沿的一种机制。最常见的方式是信息系统要求用户提交用户名与密码，正确则允许用户登录，错误即拒绝用户登录。

会话管理 

在人机交互时，会话管理是保持用户的整个会话活动的互动与计算机系统跟踪过程。会话管理分类：桌面会话管理、浏览器会话管理、Web服务器的会话管理。
桌面会话管理器是一个程序，可以保存和恢复桌面会话，桌面会话是所有正在运行的窗口和当前的内容。受会话管理的应用程序，在保存会话的设置时，会话管理器会保存受该会话管理的所有应用程序。如果注销后再次登录，会话管理器会自动启动受该会话管理的应用程序；不受会话管理的应用程序，必须手动启动这些应用程序。
浏览器会话管理是打开网页浏览器时，用户可以保存所有打开的网页和设定，并在以后恢复他们的日期。为了帮助恢复系统或应用软件崩溃，页面和设置也可以在下次运行恢复。
HTTP是一种无状态协议，一次请求结束，客户端与服务端的连接就会断开，服务器再次收到请求时，无法识别此次请求是哪个用户发过来的，需要重新建立连接。为了判断发送请求的用户，需要一种记录用户的方式，也就是Web应用会话管理。它也可以简单理解为一个用户从登录到退出应用的一段期间。
常见的Web应用会话管理的方式有以下3种：

基于server端session的管理方式
cookie-based的管理方式
token-based的管理方式

 HTTP协议

无连接
每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。
无状态
指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送HTTP请求之后，服务器根据请求，会给我们发送数据过来，但是发送完，不会记录任何信息。
会话
执行会话最简单、最常见的方式是向每名用户发布一个唯一的会话令牌或标识符，用户在每一个请求中提交这个令牌。

权限管理

权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。权限管理几乎出现在任何系统里面，只要有用户和密码的系统。很多人常将“用户身份认证”“密码加密"系统管理”等概念与权限管理概念混淆。
用户身份认证是用户要告诉系统“我是谁”，不属于权限管理范畴。
密码加密，隶属用户身份认证领域，不属于权限管理范畴。
系统管理，一般是系统的一个模块。而且该模块一般还含有权限管理子模块。系统管理里面的权限管理模块，只是一个操作界面，让管理员能够设置角色等安全策略。系统背后还有很多权限验证逻辑，这些都并不属于该模块。总体来说，该模块相当于给权限管理模块提供了一些数据。
从控制力度来看,可以将权限管理分为两大类：

功能级权限管理
数据级权限管理
从控制方向来看,也可以将权限管理分为两大类：

从系统获取数据,比如查询订单、查询客户资料
向系统提交数据,比如删除订单、修改客户资料

业务逻辑

不同的项目有不同的功能，不同的功能需要不同的实现，实现这些核心功能的代码就叫业务逻辑。
很多先接触分层结构，然后对每层产生了初步认识。其中，由于表示层和数据访问层的代码职责清晰明确，基本能正确认识。但是，由于接触的分层架构的Demo大多业务极其简单，又基本是CRUD（常说的增删改查）操作集中型的业务，就会狭义的认为业务逻辑基本就是对数据访问简单的封装。
业务逻辑广义的认知应该是：软件产品都是在某个领域内实现某些特定业务，所以，软件产品天生应该分解为界面交互部分和业务逻辑部分，其中业务逻辑部分是软件产品的核心，它客观存在于软件产品内部，但是无法对使用者产生直观刺激，因此业务逻辑不能与使用者直接交互。而界面交互部分是业务逻辑与使用者进行交流的接口，使用者通过界面交互部分，与业务进行交流，从而使得软件产品发挥其作用。

验证机制

身份验证是核心防御机制中最薄弱的环节，身份验证机制也是攻击者的主要攻击目标之一。
验证机制是应用程序防御恶意攻击的中心机制。它处于防御未授权的最前沿，如果用户能够突破那些防御，他们通常能够控制应用程序的全部功能，自由访问其中的数据。缺乏安全稳定的验证机制，其他核心安全机制（如会话管理和访问控制）都无法有效实施。
验证机制最常见的方式是信息系统要求用户提交用户名与密码，正确则允许用户登录，错误则拒绝用户登录。
验证机制问题主要要分为两个方面：分别为设计缺陷和执行缺陷

Web应用程序常用的验证机制有：
基于HTML表单的验证（最常用）
多元机制，如组合型密码和物理令牌（多用于安全性要求较高的应用程序比如说提供进行巨额交易服务的私人银行）
客户端SSL证书或智能卡（成本非常昂贵，通常只有那些用户不多的安全性极其重要的应用程序才会使用）
HTTP基本和摘要验证（内网使用较多，建立在域环境及内网对用户的访问控制之上的）
使用NTLM或Kerberos整合windows的验证
第三方验证服务（尚未得到大量使用）
验证机制设计缺陷
可预测的用户名 
有些应用程序需要用户注册时用户名符合某一特定规则，比如需要满足“姓名缩写数字”的这种形式，其中数字是为了防止用户名重复，也就是说如果在存在姓名缩写相同的情况下后面要跟数字或者进行数字累加。这种在学校邮箱注册时是比较常见的。通过这种方式攻击者可以很方便的获得大量有效用户名。

非唯一性用户名
极少部分的应用程序不要求用户名的唯一性，这就可能造成这样的问题：
在恰巧有两名用户使用相同的用户名及密码的情况下，应用程序要么阻止第二个用户设置密码，要么允许其设置相同的密码。前者这种情况可能导致第一名用户的密码泄露给第二名用户，这种情况下攻击者如果想获得某个已知用户名对应的密码则可以通过注册功能针对于此用户名使用不同的密码注册，如果应用程序返回禁止注册，那么我们可以推测出此次注册时的密码就是这个用户名对应的密码。后者则可能导致第二名用户可以访问第一名用户的状态。

弱口令
弱口令（Weak Password）指容易被他人猜到的口令，除123456、12345678、admin等常见口令外，生日、姓名、手机号、1qaz@WSX也被称为弱口令。
为节省攻击成本，通常会适用弱口令字典进行字典攻击
密码确认不完善
些应用程序在用户注册设置密码时，出于一些原因往往会对密码进行如下处理：

截断前n个字符
大小写不敏感
删除特殊字符
上述操作均会减少应用程序的密码空间，攻击者通过仔细分析应用程序的密码处理规则后，可以适当修改自己的暴破字典从而提高暴破的成功率。

可预测的密码 
在像学校，企业这种存在批量注册大量用户需求的应用程序中，经常会为批量用户设置默认密码，这种默认密码可以是相同的也可以是与用户名或者其身份证信息等有关系的。这种情况下攻击者可以通过Google hacking来在公开信息汇总收集大量初始密码，也可以根据默认密码规律推测出大量密码。

暴力破解
暴力破解（Brute Force），也可称为蛮力攻击，指利用穷举法将所有的可能性一尝试，理论上可以破解所有密码问题。实际测试中，考虑到攻击成本问题，通常使用字典攻击（DictionaryAttack）， 即逐一尝试用户自定义词典中的可能密码（单词或短语）的攻击方式。 
如果应用程序允许用户在登录失败很多次后，仍能继续尝试登录，那么这种情况下此应用可能存在暴破攻击。为了防止暴破攻击，应用程序应该设置用户登录失败次数上限，当用户失败的登录次数达到上限后应用程序应该阻止用户进一步的登录。但是通过前端脚本或者Cookie来统计用户失败的登录次数是不可靠的，因为这些都是攻击者可以接触到并且可以修改的，如果服务器端使用Session来存储用户失败登录的次数这样就可靠的多。除了用户登录次数的统计问题外，如何处理失败登录次数达到上限的用户也是一个需要谨慎处理的问题，如果用户在登录失败很多次后被锁定，但是锁定状态下的用户使用正确密码登录时和使用错误密码登录时Web应用程序的响应信息不同那么此时此应用还是存在暴破漏洞。 
对于暴力破解，还有一些多余的提示信息可以利用。比如登录失败后，提示“用户名不存在”密码错误”、“用户未注册”等提示信息，通过这些信息可以更加快速的推断出用户名及密码。
可利用信息
多余的提示信息

登录失败后，不应该提示如“用户不存在”、“密码错误”、“用户未注册”等详细信息，通过这些信息可推断出用户名、密码等其他信息
可预测信息

类似user100、user101的用户名，手机号信息
类似于ABC123、123456的初始密码
在暴力破解的时候，若拥有验证码还需要绕过验证码，验证码常见的有图片验证码和短信验证码。
图片验证码

验证码不生效/不更新/不失效
验证码可预测/删除/获取
验证码可识别
短信验证码

4/6位验证码
篡改手机号
篡改Response
密码重置
在逻辑漏洞中密码重置问题是比较常见的一种场景，常见于用户修改密码页面、用户找回密码页面等涉及到网站重置密码功能的页面。

修改密码
目前的修改密码的方式大概可以分为两种，第一种是要求用户键入用户名、旧密码、新密码、确认新密码四部分，一些Web应用程序会忽略修改密码处旧密码错误输入次数过多的问题，这就容易被攻击者利用来进行密码暴破；还有一种最不安全的情况就是只需要用户键入用户名、新密码、确认新密码即可更改用户名相应的密码，这种情况下攻击者无需暴破即可获得正确的用户名及密码组合。

找回密码
忘记密码功能往往通过设置一组问题来验证用户身份，比如这些问题可以是“我最喜欢的颜色”这些问题的答案组合次数相对于密码来说小的多，并且可以通过信息收集工作来提供辅助。攻击者可以收集一组用户名并逐个遍历然后记录相应的问题在其中选择最简单的那个下手可以获得更高的成功率
忘记密码处可能不会设置错误次数限制从而允许攻击者猜测上述问题的答案
通常Web应用程序也会设置密码暗示来代替上述问题，这些密码暗示往往能够辅助攻击者猜测密码，有些用户甚至直接把密码设置为密码暗示。攻击者同样可以通过枚举收集到的用户名然后获得一组密码暗示，从而寻找出最容易获得的密码
当前Web应用程序可能通过向用户邮箱发送密码重置链接来帮助用户修改密码，这种链接是随机的攻击者很难对其进行猜解。但是有些应用在设计这个逻辑时可能允许Web应用程序将用户密码修复的邮件发送至攻击者，有时邮箱地址并没有直接显示出来而是存储在隐藏的表单中这时攻击者可以将邮箱修改为自己的邮箱。在最差的情况下攻击者可以尝试推测密码重置的URL来重置用户密码
 常见密码重置问题
用户名枚举：网站反馈多余信息，可猜测用户信息
验证码返回前端处理：可截获、修改
修改Request：用户名、手机号、Cookie等信息可修改
修改Response：操作结果成功/失败可修改
暴力破解验证码：验证码长度有限，或验证码未设置可靠的失效时间
拼凑密码重置链接：重置密码链接有规可循
记住密码 
一些应用程序为了方便用户访问通常会提供“记住密码”的功能，此功能通常仅通过cookie中的某个字段来实现。比如Cookie中会设置一个存储用户名的字段来实现基础我的功能如果这样的话攻击者仅需要随便注册一个用户然后将Cookie中用户名修改为其想要访问用户的用户名即可实现对目标用户的访问。Cookie中还可能通过存储个ID字段来唯一的标识用户，这种情况下攻击者可以遍历ID从而实现遍历访问用户。

证书分配不安全
目前很多应用程序在注册时都会要求用户填入邮箱信息，并在稍后发送给用户一封激活邮件，如果邮件中保存有用户的初始用户名及密码并且这种邮件有没有及时的删除，在邮件泄露或者邮箱被攻击者攻破的情况下，则会泄露应用程序的密码。
除此之外有些激活URL可能存在某种规律，攻击者可以通过注册，连续地注册用户来观察这种规律，从而推测其他用户的激活URL。
证书传输易受攻击
如果Web应用程序在网络环境中以明文的方式传递证书，那么攻击者则可能通过嗅探、中间人等各种方式获取。

异常开放登录机制
验证机制在代码实现过程中也可能由于编码者某些疏忽造成安全问题。

使用控制的一个账户执行一次完整、有效的登录。使用拦截代理服务器记录提交的每一份数据、收到的每一个响应
多次重复登录过程，以非常规方式修改提交的数据。比如，对于客户端传送的每个请求参数或Cookie
提交一个空字符串
完全删除键值对
提交非常长和非常短的值
提交字符串代替数字或相反
针对某一参数，尝试重复提交相同和不同的值
仔细检查应用程序对提交的每个畸形请求的响应，确定任何不同于基本情况的差异
根据这些观察结果调整测试过程。如果某个修改造成行为改变，设法将这个修改与其他更改组合在一起，使应用程序的逻辑达到最大限度
 多阶段登录机制中的缺陷
有些对于安全性要求较高的应用可能会采取多阶段登录验证机制，比如一个多阶段验证机制可以有以下三个过程组成：

提交用户名及密码
响应一个质询，答案可能使PIN中的特殊数字或者一个值得纪念的词
提交物理令牌上的值
多阶段登录机制确实可以明显的提高登录验证的安全性，但是更多的阶段同样意味着可能潜在有更多的执行缺陷。比如可能存在以下几个常见的缺陷:

应用程序认为访问第三阶段的用户已经完成了一二阶段的认证。这种情况下仅拥有部分登录凭证的攻击者可以成功登录
在每个阶段的验证过程中，应用程序会保存相应的标志，比如账户是否过期、是否被锁定、是否属于管理员、是否需要完成更多的登录验证阶段。如果攻击者可以在某一个登录阶段接触到上一个阶段设置的标记，那么攻击者可以对这些标记进行修改从而完成一定程度的攻击行为
应用程序有可能会认为各阶段认证过程中用户的身份都不会发生变化，并且不会在每一个阶段检查用户身份的统一性，那么如果攻击者在第一阶段输入的用户名及密码与后面阶段输入的验证凭证不一致，且应用程序会以两种或三种验证凭证任一对应的用户身份登录的话，这就存在严重的安全问题。这种情况下攻击者只需要知道目标用户的部分验证信息就可以登录，而其他信息则可以通过自己注册获得部分信息，这种攻击的严重程度取决于应用程序用于确定用户身份的验证凭证的易获得度（比如应用程序以第一阶段的用户名及密码来确定身份，那么存在上述缺陷的情况下攻击者可以使用自己的后两个阶段的验证凭证来进行登录，PIN码内容及物理令牌相对于用户名及密码来说更难获得，所以这种情况下攻击的严重程度比较高) 
测试多阶段验证机制可以按照以下步骤进行

记录一次有效账户完整的登录过程，并使用代理记录每一阶段的数据
收集那些由服务器返回的且重复提交的数据，这些数据往往放置与Cookie，URL预设参数，隐藏表单字段等位置
对于上述收集到的重复提交的数据试着在另一阶段将其修改为不同的值看看是否能够登录成功
还需要注意任何提交到服务器且不是用户直接输入的数据，这些数据可能是登录进展的状态信息，比如stage2complete=True，攻击者可以直接修改这些值进入下一阶段
尝试各种畸形的登录过程