逻辑漏洞~~~

1、什么是逻辑漏洞

之所以称为逻辑漏洞，是因为代码之后是人的逻辑，人更容易犯错，是编写完程序后随着人的思维逻辑产生的不足。sql注入、xss等漏洞可以通过安全框架等避免，这种攻击流量非法，对原始程序进行了破坏，防火墙可以检测，而逻辑漏洞是通过合法合理的方式达到破坏，比如密码找回由于程序设计不足，会产生很多问题，破坏方式并非向程预防思路
————————————————
1.cookie中设定多个验证，比如自如APP的cookie中，需要sign和ssid两个参数配对，才能返回数据。

2.用户的cookie数据加密应严格使用标准加密算法，并注意密钥管理。

3.用户的cookie的生成过程中最好带入用户的密码，一旦密码改变，cookie的值也会改变。

4.cookie中设定session参数，以防cookie可以长时间生效。序添加破坏内容，而是利用固有不足。这样并不影响程序运行，在逻辑上是顺利执行的。这种漏洞一般的防护手段或设备无法阻止，因为走的都是合法流量，也没有防护标准。

2、访问：

主体与客体之间的信息流动。主动的是主体，被动的是客体。

主体访问客体的四个步骤：

身份标识->身份验证（数据库匹配信息，判断身份是否合法）->授权（判断身份是谁，管理员或正常账户）->审计（记录操作）

访问控制模型：

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

强制访问控制（MAC 军方或重要政府部门用）：安全策略高于一切，由管理员配置，访问控制由系统实施。

角色型访问控制（RBAC）：使用集中管理的控制方式来决定主体和客体如何交互，更多用于企业中，根据不同的职位来分配不同的权限。

逻辑漏洞：

代码之后是人的逻辑，人更容易犯错，所以逻辑漏洞一直都在，而且由于逻辑漏洞产生的流量多数为合法流量，一般的防护手段或设备无法阻止，也导致了逻辑漏洞成为了企业防护中的难题。

逻辑漏洞分类：

验证机制缺陷

会话管理缺陷

权限管理缺陷

业务逻辑缺陷

登录缺陷

支付逻辑缺陷

API乱用

验证机制

身份标识：whoknows、who has、who is

最常见的方式是信息系统要求用户提交用户名与密码。

权限控制：

从控制力度看，可以将权限管理分为两大类：

功能级权限管理

数据级权限管理

从控制方向看，也可以将权限管理分为两大类：

从系统获取数据比如查询

向系统提交数据比如删除修改

业务逻辑：

每个业务系统都具有不用的业务逻辑，而业务逻辑在人，充分了解程序员思维有助于找到其中的问题所在。

暴力破解

可利用多余的提示信息（登录失败存在的一些特殊提示信息）和可预测信息（类似user100、user101的用户名、手机号等信息或者初始密码）

弱口令攻击

无效的防重放措施：

比如防止CSRF的token。可以利用Burp Suit Macros（宏）绕过。

无效的登录失败功能处理：

图片验证码绕过：验证码不生效、不更新、不失效，验证码可预测、删除、获取，验证码可识别，寻找其他登录页面。

短信验证码绕过：4/6位暴力破解，篡改手机号，篡改response。

会话管理问题

令牌（或是Request）具有含义的数据，如：

用户名称：user、admin、system

用户标识：0001、0002、0003

用户权限：admin、00101、01000

令牌可预测：

用户令牌具有一定的规律，可被其他人预测，如身份证号、学号、手机号、时间等

思考：十位的时间戳和十位的顺序码是否安全？

理解：每一秒都会产生十的十次方的可能，爆破难度极大。

令牌可获取：

用户令牌采取不安全的传输、存储，易被他人获取：

用户令牌在URL中传输：明文传输、发送给他人。

用户令牌存储在日志中：未授权用户易获取。

令牌不失效（会造成固定会话攻击）：

用户令牌采取不安全的传输、存储，易被他人获取：

令牌有效期过长（在一段时间内使令牌失效）、令牌尝试次数过多（提交次数一定时要使令牌无效）、无效令牌的重置。

越权操作

越权操作是信息系统中较为常见的一种漏洞，指的是信息系统对用户的操作权限审核不严，从而使得用户进行了自己权限之外的操作。

权限控制的方法：

防火墙ACL策略：主体-规则-客体

Linux文件权限：主体-读写、执行-客体

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

RBAC：web应用系统常采用此模型。

未授权访问

未授权访问需要安全配置或权限认证的地址、授权页面存在缺陷，导致其他用户可以直接访问，从而引发重要权限可以被操作、数据库、网站目录等敏感信息泄露。

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

Web应用权限

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

防御解决方案：

隐藏：只能组织用户无法猜测到后台页面，进行大量爆破还是可能扫描出来的。

页面权限控制：可以阻止非认证用户登录后台。

最好是管理员在内网进行管理。用户在外网进行搜索。

测试方法：

Google-Hacking

域名爆破

端口服务扫描

域名关联

越权操作：

水平越权：攻击者尝试访问相同级别的用户资源。

垂直越权：攻击者尝试访问更高级别的用户资源。

修复总结：

水平越权：

设置合理的会话管理机制，将有关用户标识存在服务器上。

涉及到关于用户隐私的操作时从session中取出用户标识（如id）进行操作。

不要轻信用户的每个输入。

垂直越权：

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

API逻辑漏洞

现在是APP盛行的时代，客户端使用API与服务器进行数据传输，所以API安全问题频出。比如：参数校验、短信邮箱炸弹、关键参数不加密等等。

未加密风险：凭据、传输数据公开、资源信息泄露。

常见的逻辑漏洞：

一：订单金额任意修改

解析

很多中小型的购物网站都存在【订单金额任意修改】漏洞。在提交订单的时候抓取数据包或者直接修改前端代码，然后对订单的金额任意修改。

二：验证码回传

解析

这个漏洞主要是发生在前端验证处，并且经常发生的位置在于

账号密码找回 、账号注册 、支付订单等

验证码主要发送途径：

邮箱邮件 、手机短信

预防思路：

response数据内不包含验证码，验证方式主要采取后端验证，但是缺点是服务器的运算压力也会随之增加。

2.如果要进行前端验证的话也可以，但是需要进行加密。当然，这个流程图还有一些安全缺陷，需要根据公司业务的不同而进行更改。

三．未进行登陆凭证验证

解析：

有些业务的接口，因为缺少了对用户的登陆凭证的较验或者是验证存在缺陷，导致黑客可以未经授权访问这些敏感信息甚至是越权操作。

四：接口无限制枚举

解析

有些关键性的接口因为没有做验证或者其它预防机制，容易遭到枚举攻击。

预防思路：

1. 在输入接口设置验证，如token，验证码等。

   如果设定验证码，最好不要单纯的采取一个前端验证，最好选择后端验证。

   如果设定token，请确保每个token只能采用一次，并且对token设定时间参数。

2. 注册界面的接口不要返回太多敏感信息，以防遭到黑客制作枚举字典。

3. 验证码请不要以短数字来验证，最好是以字母加数字进行组合，并且验证码需要设定时间期限。

4. 优惠券，VIP卡号请尽量不要存在规律性和简短性，并且优惠券最好是以数字加字母进行组合。

五：cookie设计存在缺陷

解析：

Cookie的效验值过于简单。有些web对于cookie的生成过于单一或者简单，导致黑客可以对cookie的效验值进行一个枚举。

预防思路：

1.cookie中设定多个验证，比如自如APP的cookie中，需要sign和ssid两个参数配对，才能返回数据。

2.用户的cookie数据加密应严格使用标准加密算法，并注意密钥管理。

3.用户的cookie的生成过程中最好带入用户的密码，一旦密码改变，cookie的值也会改变。

4.cookie中设定session参数，以防cookie可以长时间生效。

六：找回密码存在设计缺陷

解析：

1.auth设计缺陷

经常研究逻辑漏洞的人可能会对以下URL很熟悉

www.xxx.com/resetpassword.php?id=MD5

用户修改密码时，邮箱中会收到一个含有auth的链接，在有效期内用户点击链接，即可进入重置密码环节。而大部分网站对于auth的生成都是采用rand()函数，那么这里就存在一个问题了，Windows环境下rand()最大值为32768，所以这个auth的值是可以被枚举的。

2.对response做验证：

这个漏洞经常出现在APP中，其主要原因是对于重置密码的的验证是看response数据包。

预防思路：

1.严格使用标准加密算法，并注意密钥管理。

2.在重置密码的链接上请带入多个安全的验证参数。

七：单纯读取内存值数据来当作用户凭证

解析：

实际上这个应该算作一个软件的漏洞，但是因为和web服务器相关，所以也当作WEB的逻辑漏洞来处理了。最能当作例子是《腾讯QQ存在高危漏洞可读取并下载任意用户离线文件（泄漏敏感信息）》这个漏洞，但是我相信这种奇葩的漏洞不一定只有腾讯才有，只是还没人去检测罢了。

产生这个漏洞的主要原因是程序在确定一个用户的登陆凭证的时候主要是依靠内存值中的某个value来进行确认，而不是cookie。但是内存值是可以更改和查看的。

预防思路：

1. 走服务器端的数据最好做cookie验证。

2. 不反对直接在进程中确定用户的登陆凭证，但是请对进程进行保护，或者对进程中的value做加密处理。