通过对攻击平台的请求进行分析得出了以下结论
一、所谓的通过注入支付平台来进行攻击,完全子虚乌有,和支付平台没任何关系
二、此漏洞波及范围可能非常广,只要对接时使用易支付通道来进行对接的支付平台都有被攻击的可能性,不限于源等支付系统,也就是说,无论是对接的哪个平台,只要你程序的支付对接文件调用的是之前的易支付SDK,或自己根据SDK验签模式写的对接文件,都有被攻破的可能性,这一套老的对接规则可能已经不再安全?
三、攻击原理很简单:
1、攻击者通过付款链接获取必要验签参数
2、通过未知方法给需要回调通知的内容进行签名
3、进行回调通知,完成回调模拟
攻击者期间并不需要访问支付平台,只需要对商城发起的提交参数进行解析即可完成攻击
攻击者的请求访问支付平台的唯一作用,可能只是确认下是否使用的是易支付对接通道,验签方式是否是MD5签名验证而已!
其中第2个步骤有一个难点,攻击者是如何计算出,或者获取到支付平台的对接秘钥的?他们所谓的SQL注入攻击并不存在,整个攻击流程并没有任何奇怪请求提交到支付平台,所以只能够得出是这套易支付签名验证规则出现了漏洞,或可以被逆推的结论,如果结论成立的话,就很恐怖了,回看结论二
四、如何预防这个问题?
1、换对接模式,用新规则来进行对接,需要支付系统开发者来对支付通道对接规则进行升级,商城也需要对新的接口进行适配,需要多方配合,很麻烦,这也是源作者直接放弃对v7进行更新支持的原因?因为是支付通道验签方式的问题,确实怎么修复都没用,毕竟验签规则在商城客户端,和支付平台没关系,无法预防,最多只能够屏蔽浏览器控制台,治标不治本!
2、和商城系统的解决方案一样,为自己的平台做针对性兼容,如同时使用正版授权官方,并且安装官方对接插件即可完美防护此类问题,解决原理很简单,额外加一层验证,回调后通过请求支付平台查单api,对订单真实付款状态进行查询即可!所以在目前没有很好解决方案的情况下,可以使用正版授权官方支付平台,并且用官方插件进行对接!这是最低成本的解决方案!
五、下面是部分攻击状态码,可以对此类状态码进行针对性屏蔽,治标不治本,毕竟参数是攻击者自定义的,如图所示,只需要屏蔽【trade_no】参数包含【tg_EpayHackerBot】请求的回调链接即可对此进行防御,可以在宝塔nginx免费防火墙内配置对应规则!
注意:此方案只能临时解决,如果攻击者调整回调内容,则失效!
下面是支付平台收到的请求内容截图:
支付平台收到的请求参数,没有任何异常,测试时平台也对请求的参数进行了拦截分析,无果,全部是正常请求!唯一有点不同的就是多了一个TelegramBot请求头的参数,这个是TG机器人携带的内容,也可以对此进行拦截处理!也可以屏蔽国外,具体效果自测!
Ps:以上分析仅供参考,具体自测!有任何问题或者想法可以在下方留言,这篇分析说明写的不是非常详细,有点赶时间,有错别字或者误区都可以在下方评论指出!
© 版权声明
注意:本站资源多为网络收集,如涉及版权问题请及时与站长联系,我们会在第一时间内删除资源。
THE END
- 最新
- 最热
只看作者