逻辑漏洞概述

普及访问控制与访问控制模型，进而了解逻辑漏洞的定义及分类

访问控制概述

在某种程度上来说，信息安全就是通过控制如何访问信息资源来防范资源泄露或未经授权修改的工作。

访问控制（AccessControl）指系统对用户身份及其所属的预先定义的策略组限制其使用数据资源能力的手段。通常用于系统管理员控制用户对服务器、目录、文件等网络资源的访问。访问控制是系统保密性、完整性、可用性和合法使用性的重要基础，是网络安全防范和资源保护的关键策略之一，也是主体依据某些控制策略或权限对客体本身或其资源进行的不同授权访问

访问是主体（Subject）和客体（Object）之间的信息流动，访问控制的主要目的是限制访问主体对客体的访问，从而保障数据资源在合法范围内得以有效使用和管理。为了达到上述目的，访问控制需要完成两个任务：识别和确认访问系统的用户、决定该用户可以对某一系统资源进行何种类型的访问。

访问控制包含三个要素，即主体、客体和访问控制策略。
主体（Subject）是指访问中一个发出请求或要求的主动实体，可以是某个用户，也可以是用户启动的程序、进程或设备等；
客体（Object）是接受其他实体访问的被动实体，凡是可以被操作的信息、资源、对象都可以被看作客体，可以是文件、光盘、数据库等。
控制策略（Attribution）是主体对客体的访问规则集，限制主体对客体的访问权限。

主体访问客体通常需要4个步骤：
ldentification--身份标识
Authentication---身份验证
Authorization--授权
Accountability--审计

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

自主访问控制（Discretionary Access Control，DAC，大部分使用）
强制访问控制（Mandatory Access Control，MAC）
角色型访问控制（Role-Based Access Control，RBAC）

自主访问控制（DiscretionaryAccessControl，DAC，大部分使用）
由客体的属主自主的对客体进行管理，自主的决定是否将访问权限授予其他主体。

该控制模型与所有数据和权限被操作的系统控制不一样，允许用户控制自己的数据的访问权限，根据用户的身份以及他们所属的分组来限制对对象的访问权限。用户可以通过ACL定义什么人或什么等级的人可以访问什么资源，每一个ACL都包含一个用户和组的列表，以及它们的访问权限。

缺点：主体权限太大就可能泄露信息；当用户的数量多、管理数据量大时，ACL就会很庞大，不易维护。

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

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

逻辑漏洞概述

什么是逻辑漏洞
随着网络安全法的实施、企业和用户安全意识的提高，Web安全已经成为了重点关注的方向。诸如使用安全开发框架、部署安全防护设备等防护手段的使用，使得网站的常规漏洞越来越少。以SQL注入为例，由于其危害巨大，常年稳居OWASPTop10的第一位，目前很多Web开发框架在底层就直接杜绝的SQL注入问题。
但“逻辑漏洞”一词现在却更加热门，很可能成为Web漏洞的主战场。之所以称之为“逻辑漏洞”，是因为在代码之后是人的逻辑，人更容易犯错，是编写完程序后随着人的思维理解产生的不足，所以逻辑漏洞一直都在。

相比SQL注入、XSS漏洞等传统安全漏洞，SQL注入、XSS等漏洞可以通过安全框架等避免，并且攻击流量非法，对原始程序进行了破坏，防火墙可以检测；所以现在的攻击者更倾向于利用业务逻辑层的应用安全问题，逻辑漏洞就是指攻击者利用业务的设计缺陷，获取敏感信息或破环业务的完整性。一般出现在密码修改（没有旧密码验证）、越权访问、密码找回、交易支付等功能处。而且由于逻辑漏洞产生的流量多数为合法流量，传统的安全防御设备和措施收效甚微，一般的防护手段或设备无法阻止，这类问题往往危害巨大，可能造成了企业的资产损失和名誉受损，所以导致了逻辑漏洞成为了企业防护中的难题。

逻辑漏洞的分类

验证机制缺陷
会话管理缺陷
权限管理缺陷
业务逻辑缺陷

验证机制

 

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

根据身份认证的对象不同，认证手段也不同，但针对每种身份的认证都有很多种不同的方法。
如果被认证的对象是人，则有三类信息可以用于认证：
Whoknows：某人所知道的内容，这类信息通常理解为口令

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

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

会话管理

   在人机交互时，会话管理是保持用户的整个会话活动的互动与计算机系统跟踪过程。会话管理分类：桌面会话管理、浏览器会话管理、Web服务器的会话管理。
   桌面会话管理器是一个程序，可以保存和恢复桌面会话，桌面会话是所有正在运行的窗口和当前的内容。受会话管理的应用程序，在保存会话的设置时，会话管理器会保存受该会话管理的所有应用程序。如果注销后再次登录，会话管理器会自动启动受该会话管理的应用程序；不受会话管理的应用程序，必须手动启动这些应用程序。
   浏览器会话管理是打开网页浏览器时，用户可以保存所有打开的网页和设定，并在以
后恢复他们的日期。为了帮助恢复系统或应用软件崩溃，页面和设置也可以在下次运行
恢复。

HTTP是一种无状态协议，一次请求结束，客户端与服务端的连接就会断开，服务器再次收到请求时，无法识别此次请求是哪个用户发过来的，需要重新建立连接。为了判断发送请求的用户，需要一种记录用户的方式，也就是Web应用会话管理。它也可以简单理解为一个用户从登录到退出应用的一段期间。
常见的Web应用会话管理的方式有以下3种
基于server端session的管理方式
cookie-based的管理方式
token-based的管理方式

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

 权限控制

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

权限管理（Authorization）

从控制力度来看，可以将权限管理分为两大类
功能级权限管理
数据级权限管理
从控制方向来看，也可以将权限管理分为两大类
从系统获取数据，比如查询订单、查询客户资料
向系统提交数据，比如删除订单、修改客户资料

业务逻辑

  不同的项目有不同的功能，不同的功能需要不同的实现，实现这些核心功能的代码就叫业务逻辑。
  很多先接触分层结构，然后对每层产生了初步认识。其中，由于表示层和数据访问层的代码职责清晰明确，基本能正确认识。但是，由于接触的分层架构的Demo大多业务极其简单，又基本是CRUD（常说的增删改查）操作集中型的业务，就会狭义的认为业务逻辑基本就是对数据访问简单的封装。

业务逻辑广义的认知应该是：软件产品都是在某个领域内实现某些特定业务，所以软件产品天生应该分解为界面交互部分和业务逻辑部分，其中业务逻辑部分是软件产品的核心，它客观存在于软件产品内部，但是无法对使用者产生直观刺激，因此业务逻辑不能与使用者直接交互。而界面交互部分是业务逻辑与使用者进行交流的接口，使用者通过界面交互部分，与业务进行交流，从而使得软件产品发挥其作用。