逻辑漏洞
2020-09-01 本文已影响0人
文景大大
一、什么是逻辑漏洞
逻辑漏洞是指程序流程设计上存在漏洞，从而导致被黑客利用，造成业务上的危害。常见的逻辑漏洞场景有以下这些。
二、逻辑漏洞场景及预防
2.1 订单金额修改
- 用户在页面上选取所有商品开始进行结算；
- 使用开发者工具或者BP等工具拦截请求，进行商品总额、数量、单价等信息的修改；
- 后端收到请求后并未做校验以收到的总额对客户发起收款；
- 用户付款后本次订单生效；
该种场景下的逻辑漏洞就体现在服务器端没有对前端的请求内容进行校验，没有意识到订单中任何数据都有可能被篡改的风险。
常见的预防方法有两种：
- 订单总金额的计算交给后端服务器来计算，在返回总金额的时候同时返回订单内所有商品信息的一个hash值，要求后续前端发起提交订单请求时，必须带上该hash值，服务器会对订单内商品的信息和该hash值做校验，判断数据是否被篡改，如果没有那再对客户发起收款及后续操作。
- 后端在收到前端的订单信息时，不使用前端传递的单价或者总金额数据，而是针对订单中的每一个商品计算总额，根据最后计算的总金额对客户发起收款及后续操作。
- 特别的，对于大额订单，在客户发起付款之后，应该增加人工审核的步骤，人工审核订单中商品的数量、单价、总额以及客户实际付款金额信息，这些都没问题再进入下一步操作。
2.2 验证码回传
- 用户在注册、修改密码、支付等需要用户身份认证的情况下，会遇到需要输入验证码进行验证的场景；
- 验证码一般都是通过短信或者邮件的形式发送给用户的；
- 当用户在界面点击发送验证码的时候，后端直接将验证码返回给了前端，让前端去校验用户输入的内容是否和验证码匹配；
- 黑客完全可以使用开发者工具或者拦截返回内容直接获取验证码；
这种场景下的逻辑漏洞体现在后端没有对验证码做任何防护直接返回给了前端，一旦返回被拦截那么验证码也就没有意义了。
常见的预防方法：
- 验证码不要回传给前端，而是由前端提交后在后端进行验证；
- 后端可以将验证码进行加密后发送给前端，用户在输入验证码后，前端使用相同的方法进行加密，判断两个密文是否匹配；但是这种方法有可能被单步调试绕过，安全性存疑。
2.3 未进行登录验证
- 网站的管理页面或者接口没有验证是否登录就能被访问到；
- 查询客户敏感信息的时候没有做登录验证就能查询；
- 某敏感文件的下载未做登录验证就能下载；
这样的逻辑漏洞场景很多，主要的原因就是在处理请求前没有对请求者的身份做校验，或者是认为前面步骤已经做过了校验，后面的就不需要了，这才导致逻辑漏洞。
常见预防方法：
- 对于每一个需要身份信息才能操作的请求都需要进行用户身份的校验；
- 常见方法是拿cookie或者token校验；
2.4 接口无限制枚举
- 网站的登录功能没有做次数限制，导致被黑客使用弱密码库枚举攻击；
- 网站的验证码验证功能没有做次数限制，很容易被枚举攻击；
- 网站的优惠券兑换功能没有做次数限制，导致被枚举攻击；
这样的逻辑漏洞都是因为没有对失败的请求做次数限制导致的，从而让黑客有机会枚举各种值进行破解。
常见预防方法：
- 对失败尝试次数做限制，视功能的敏感度可以设置疲劳时间和锁定处理；
- 如果采用了token机制，需要给token设置有效期；
- 失败返回信息不要透露过多，防止被黑客猜测出来；
- 验证码不使用短的纯数字，很容易被破解；
- 优惠券等号码不要存在规律性或者简短性，最好是以数字、字母和特殊符号的组合；
2.5 cookie设计缺陷
- cookie验证值太多简单，有的时候是简短性的数字或者明文用户名等，很容易被黑客破解；
- cookie不更新，即使黑客盗取了用户的cookie，用户更改了帐密，黑客还是可以使用原来的cookie进行访问；
- cookie的加密算法太过简单，比如base64，很容易被破解；
常见预防方法：
- 使用标准的安全的加密算法对cookie进行加密；
- cookie需要过期处理，防止长时间有效。
2.6 密码重置设计缺陷
- 重置密码链接参数过于简单，比如是间断性的纯数字，很容易被黑客枚举；
- 用户请求重置密码时，需要输入验证码，黑客没有收到验证码，随便输一个，服务器返回验证错误，但是response被拦截，黑客修改状态码为成功，从而欺骗前端程序，从而进入密码重置流程，而后端没有对后续的密码重置流程做校验；
常见预防方法：
- 重置密码链接参数使用多个复杂的无规律的参数值；
- 重置流程需要对前置流程做校验；
