【中培课堂】详解web测试中常见的逻辑漏洞问题

逻辑漏洞挖掘一直是安全测试中的常规性问题中培教育安全专家高老师表示，相比SQL注入、XSS漏洞等传统安全漏洞，现在的攻击者更倾向于利用业务逻辑层的应用安全问题，这类问题往往危害巨大，可能造成了企业的资产损失和名誉受损，并且传统的安全防御设备和措施收效甚微。高老师在这里分享Web安全测试中逻辑漏洞的挖掘经验。

一、订单金额任意修改

解析

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

关于支付的逻辑漏洞这一块还有很多种思路，比如相同价格增加订单数量，相同订单数量减少产品价格，订单价格设定为负数等等。

预防思路

1.订单需要多重效验，如下图所演示。

2. 订单数值较大时需要人工审核订单信息。

3. 两个预防思路相对简单，第二个甚至还有一些不足之处。这里需要根据业务环境的不同总结出自己的预防方式，最好咨询专门的网络安全公司。

二、验证码回传

解析

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

· 账号密码找回

· 账号注册

· 支付订单等

验证码主要发送途径

· 邮箱邮件

· 手机短信

黑客只需要抓取Response数据包便知道验证码是多少。

预防思路

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

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

三、未进行登陆凭证验证

解析

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

预防思路

对敏感数据存在的接口和页面做cookie，ssid，token或者其它验证，如下图所示。

四、接口无限制枚举

解析

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

预防思路

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

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

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

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

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

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

5. 以上这是部分个人建议，实际方案需要参考业务的具体情况。

五、cookie设计存在缺陷

解析

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

一些网站对于cookie的效验只单纯的采用了一组数字，并且数值为常量，不会改变，这样非常容易遭到黑客的枚举。甚至有一些网站做的更简单，直接以用户名，邮箱号或者用户ID等来作为cookie的判断标准。

2. cookie设置存在被盗风险

有很多时候，如果一个用户的cookie被盗取，就算用户怎么修改账号和密码，那段cookie一样有效。详情可以参考《BlackHat(世界黑帽大会)官方APP出现两个逻辑漏洞》。

国内大部分厂商都不会把这个地方当作安全漏洞来处理，他们认为这个漏洞的利用条件是黑客必须要大批量获取到用户的cookie。虽然事实如此，但是这个也是一个安全隐患。

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

有一些厂商为了图方便，没有对用户的cookie做太多的加密工作，仅仅是单纯的做一个静态加密就完事了。我之前就碰到一个，可以为大家还原一下当时的场景。

cookie中有个access token参数，看到value后面是两个等号，习惯性的给丢去base64解码里面，发现解出来后是我的用户名。因此只要知道一个人的用户名就可以伪造对方的cookie，登陆他人账户。

4.还有多个案例不再做重复说明，大家可以深入研究一下cookie中的逻辑漏洞。但是cookie中的漏洞大多都是属于一个越权漏洞。越权漏洞又分为平行越权，垂直越权和交叉越权。

· 平行越权：权限类型不变，权限ID改变

· 垂直越权：权限ID不变，权限类型改变

· 交叉越权：即改变ID，也改变权限 

预防思路

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

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

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

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

5.还有很多方法，不再一一例举，请根据业务不同而思考。

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

解析

1.auth设计缺陷

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

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

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

2.对response做验证

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

预防思路

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

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

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

解析

实际上这个应该算作一个软件的漏洞，但是因为和web服务器相关，所以也当作WEB的逻辑漏洞来处理了。

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

预防思路

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

2. 高老师表示自己不反对直接在进程中确定用户的登陆凭证，但是认为应该对进程进行保护，或者对进程中的value做加密处理。