PHP安全：常见业务流程安全

gclome

原文链接：PHP安全：常见业务流程安全

逻辑漏洞主要是由于研发阶段对于程序逻辑的设计和限制存在缺陷导致的。此类漏洞防御难度高，现有的安全系统和策略基本无效，只能靠人工逐一检查，对系统的危害也是很大的。本文列举了常见的业务逻辑问题点。


1、注册安全

注册业务的主要安全问题有以下几个方面。

（1）恶意注册。恶意批量注册容易造成垃圾数据，给系统带来压力，增加维护成本。

（2）恶意遍历。注册时一般服务端会提供检测用户名、手机号是否被使用的请求接口，这容易被攻击者利用来遍历手机号和用户名。

注册流程的安全解决方案如下。

（1）注册功能增加人机认证，如图片验证码，防止恶意批量注册。

（2）记录IP的请求次数，控制单位时间内IP的请求次数，防止恶意遍历注册用户。

（3）用户名要经过敏感词过滤，防止出现非法内容。

（4）不要提供独立的用户名检测接口，防止被恶意利用，如果必须提供，同样需要进行人机验证。

图1是一个通用的安全注册流程。
​
图1  通用的安全注册流程

2、登录安全

登录相关的安全问题主要集中在以下方面。

（1）信息泄露。

登录错误提示信息太明确导致账号、密码被枚举攻击，比如“用户名不存在”“密码错误”“手机号不存在”这样的提示可以给攻击者提供很好的线索。

“记住我”功能中直接将用户的账号、密码信息保存在客户端，易于造成账号、密码的泄露。

（2）密码爆破。

登录次数未进行频率限制，没有图片验证码导致账号、密码被枚举攻击。

（3）验证码绕过。

进行了IP限制但攻击者利用代理池绕过，加了图片验证码但验证码太容易识别，攻击者利用打码平台绕过。

（4）手机号验证码登录主要问题为验证码使用不当，参考验证码安全方案。

（5）登录功能的图片验证码验证后未进行立即失效处理，参考验证码安全方案。

安全登录解决方案包括以下方面。

（1）手机号验证码登录，可参考验证码安全方案。

（2）登录错误提示建议使用“用户名或密码错误”。

（3）登录进行密码尝试频率限制，每个账号每天可登录失败三次。

（4）增加人机验证，如图片验证码，可参考验证码安全方案。

（5）强行要求密码复杂度，如必须为特殊符号、英文大小写、数字等组合。

（6）“记住我”功能可通过将Token过期时间延长来实现，在校验Token同时校验浏览器登录环境是否已经改变。

图2是一个通用的安全登录流程。
​
图2  通用的安全登录流程

3、密码找回安全

通常的密码找回流程为填写用户名或手机号或邮箱、发送验证码或校验邮件、系统校验信息、设置新密码，如图3所示。
​
图3  密码找回流程

在密码找回整个环节中，如果在进入重置密码功能前，对身份验证流程控制不够严格，就会导致执行填写用户名/手机号/邮箱后，直接跳过短信校验和邮件校验进行修改密码这一步，从而导致任意用户密码重置漏洞。

在找回密码流程中要注意以下几点安全问题。

（1）验证码使用不当。

手机验证码重置密码的主要问题为验证码使用不当，可参考验证码安全方案。

（2）密码恶意重置。

邮箱链接里的Token未使用复杂的随机数，而是使用了用户名、固定散列值等可预测字符串，导致攻击者重置其他用户密码。

重置密码操作，服务端仅验证了邮箱链接里Token的有效性，未验证和被重置账号的对应关系，导致攻击者重置其他用户密码。

针对找回密码的通用安全方案如下。

（1）手机验证码重置密码，可参考验证码安全方案。

（2）邮箱链接重置密码方案。

①申请重置接口，让用户提交重置的用户名。

②服务端根据用户名查找到对应的邮箱。

③生成重置密码链接，链接里的Token使用复杂随机数，比如UUID，并保存Token与用户名的对应关系。

④将重置密码链接发送到对应的用户名的邮箱。

⑤用户点开邮箱中的链接，跳到设置密码页面，填好密码提交设置请求，请求将URL中的Token、密码一起提交到服务端。

⑥服务端根据Token找到用户名并为其设置密码。

4、修改密码安全

通常的密码修改流程为用户登录、输入旧密码和新密码、校验旧密码、校验新密码、系统保存新密码，如图4所示。
​
图4  密码修改流程

密码修改中容易出现的安全问题有以下几点。

（1）未校验旧密码。

修改密码时没有对旧密码进行验证，导致攻击者利用CSRF等漏洞恶意修改他人密码。

（2）弱密码。

允许修改为弱密码，比如123456、admin、mysql等，很容易被攻击者猜解。

（3）未登录修改。

如果允许用户在未登录的情况下修改密码，则使用账号和旧密码验证功能很容易对他人密码进行爆破。

修改密码的通用安全方案如下。

（1）修改密码请求填写旧密码，服务端接口验证旧密码通过后为其设置新密码。

（2）修改密码接口必须登录才能访问，此接口不从客户端获取被修改的账号，而是利用Session或Token获取当前账号，防止利用账号+旧密码对他人密码进行爆破。

（3）校验密码的复杂度，如必须为英文大小写+数字+特殊字符，且不少于8位。

（4）为了防止暴力修改，应该使用人机认证，可参考验证码安全方案。

5、支付安全

通常的支付流程是商品下单、用户确认订单信息、用户支付、支付成功、系统确认支付信息、订单支付成功，如图5所示。
​
图5  支付流程

如果在商品下单或者确认订单过程中，对于正负数没有严格验证，则可以通过数量输入负数或者修改价格实现低价购买或者刷钱。如果在支付成功后，没有对前面下单、订单信息、支付进行严格验证，则可以跳过前面步骤，直接进入支付，然后成功支付。支付成功后未对支付的金额与购买的订单信息进行再次确认，很容易造成用非规定价格购买大量商品。

订单支付安全要注意以下几个方面。

（1）支付过程中数据包中的支付金额被篡改。

这种漏洞是支付漏洞中比较常见的。研发人员为了方便，在支付的关键步骤数据包中直接传递需要支付的金额，而这种金额后端没有进行校验，传递过程中也没有进行签名，导致可以随意篡改金额并提交。

（2）没有对购买数量进行限制。

产生的原因是研发人员没有对购买的数量参数进行严格限制。这种同样是数量的参数没有进行签名，导致可随意修改，经典的修改方式就是改成负数。当购买的数量是一个负数时，总额的算法仍然是“购买数量×单价=总价”。所以这样就会导致有一个负数的需支付金额。若支付成功，则可能导致购买到了一个负数数量的产品，并有可能返还相应的积分/金币到你的账户上。也有将数量改成一个超大的数或者负数，可能导致商品数量或者支付的金额超过一定数值而归零。

（3）订单请求重放。

未对订单唯一性进行验证，导致购买商品成功后，重放其中请求，可以使购买商品一直增加。

（4）其他参数干扰。

对商品价格、数量等以外的其他会影响最终金额的参数，例如运费、优惠卡，如果缺乏验证将可能导致最终金额被控制。

6、结语

安全无小事，安全的投入在一定程度上会影响用户体验。企业系统应该根据自己的业务特点，建立安全红线。特别在涉及人身信息、资金、敏感信息等方面，需要在效率、增长、系统性能做出取舍的情况下，保障安全放在第一位。

如果一个企业连基本的人身信息、资金、敏感信息等方面的安全都不重视，那随着业务的发展将可能会造成致命的内伤。如果漏洞被发现利用，造成人身信息损失、企业名誉损失、资金损失，这些基本上是无法弥补的。