替代前端Form/POST向支付服务商传参的安全实现方案咨询

完全不需要重写现有3页面的串联流程，只要做最小链路调整就能从根上把支付凭证从前端剥离，适配旧版Bambora API要求，堵死carding攻击通道：

核心链路改造（工作量<2人天） #

• 彻底移除前端代码中所有硬编码的商户侧支付凭证（商户号、API密钥、安全哈希值这类本来就不该暴露的字段），所有凭证仅存储在服务器本地的配置文件/环境变量中，全程不向任何前端页面输出
• 把原来「前端表单直接POST提交到Bambora接口」的逻辑，改成前端仅向你自己的站点服务器POST两类信息：用户填写的信用卡信息、当前会话关联的唯一交易标识，不携带任何商户侧凭证
• 服务器端接收请求后，在服务端完成全量请求参数拼接：从本地配置读取商户支付凭证、从SESSION读取该会话预先存好的订单固定金额、订单关联信息，结合前端传来的用户信用卡字段，用cURL/服务端HTTP请求库直接向Bambora旧接口发服务端POST请求
• 拿到Bambora返回的交易处理结果后，按照原有3页面流程的逻辑把结果渲染到前端，走后续的支付成功/失败跳转，完全不改动原有的SESSION存储、页面跳转流转逻辑

这个方案本质是用你自己的服务器当合法请求的中转代理，Bambora旧API本来就没有限制必须由浏览器前端发起POST请求，完全符合接口的调用规则，不存在兼容性问题——之前的前端直传模式本身就是不符合接口安全设计的选择，服务端发起请求才是旧API原生支持的调用方式。

配套防攻击加固（和改造同步上线） #

• 中转接口加多层频控：服务端校验单IP每分钟最多发起3次支付请求、单SESSION10分钟内最多发起1次有效支付，触发阈值直接返回429状态码，直接把攻击者批量跑脚本的速率压下来
• 加一次性交易授权码：用户进入支付流程第一个页面时，服务端生成随机字符串存在SESSION里作为一次性授权码，前端提交支付请求时必须携带该码，服务端校验有效且未被使用才会转发请求，处理完立刻把码标记失效，防止攻击者绕过前端直接打中转接口
• 金额强制服务端校验：不管前端传来的金额是多少，服务端只读取SESSION/数据库里预先存好的对应订单的真实交易金额去请求支付接口，从根上杜绝攻击者篡改金额刷1分钱测试卡的行为
• 邮件回执逻辑调整：把原来每笔交易触发一次邮件发送的逻辑改成按小时聚合同IP的交易结果统一发信，避免被邮件服务商限流

方案优势 #

• 支付凭证全程不落地前端，攻击者就算爬遍所有前端页面源码，也找不到可以滥用的凭证，自然没法绕过你的站点借通道做盗卡测试——之前删服务器文件也挡不住攻击的核心原因就是凭证已经泄露在前端源码里，攻击者根本不需要访问你的服务器就能直接用凭证发请求，这个改造直接把这个根源堵死
• 改造量极小，不需要对接Bambora的新版JS API，等新站点筹备完成切换新支付流程的时候可以无缝替换，没有迁移成本
• 上线后之前设置最低支付金额、接验证码的措施都可以保留作为二次防护，不存在逻辑冲突

内容的提问来源于stack exchange，提问作者dasick