分享
电子商务的支付信息在提交订单时候有哪些技术可以保证交易金额、数量、等相关参数不被主动攻击篡改提交？
电子商务的支付信息在提交订单时候有哪些技术可以保证交易金额、数量、等相关参数不被主动攻击篡改提交？之前也在乌云看到很多类似被挖出的逻辑设计部严禁，导致在生成订单时候金额为负数或者小额 支付的情况。例如 乐视商城支付设计不当可修改订单支付金额酷我音乐会员0.01元购买成功存在支付逻辑漏洞如果放在前端逻辑进行计算，就可能被篡改的可能。但是如果放在后端的话，当结算逻辑比较复杂的话，后端如果放在数据库端的话，可能需要频繁变更。即使放前端的话，后端在写入数据也是必须要验证。还是前端页面–前端计算规则计算结果–验证引擎（前端程序验证还是后端DB验证？）–写入后台DB 这样子的模式哪一种比较好？还是有更好的方案？
回复 ( 10 )
1，订单金额必须服务器进行计算（防止客户端作弊）
2，所有订单必须进行价格监控（主要是防止程序bug或者运营人员事故)
题主提到的问题，虽然是防篡改问题，但大部分情况下防篡改问题，都会涉及防抵赖、防泄密等安全问题。
大的思路：
尽量在服务器端对数据进行计算、加密、签名、验签，避免将加密/签名算法及加密/签名密钥暴露给外界，降低被攻击的可能性。
针对防篡改的方案，Web端与移动端的方案不完全相同。
一、针对Web应用的一般的方案
1、网络通讯链路层面采用SSL（https）。大部分互联网公司都是采用单向SSL方案（客户端、浏览器认证服务器端证书）。如果对信息要求较高，可以采用双向SSL方案（需要浏览器安装数字证书）。
之所以采用双向SSL要安全些，主要是避免了中间人攻击（MITM）。
2、采用诸如浏览器安全控件等机制，在浏览器端对页面表单提交数据进行加密、防窃听等。此种方案在银行、第三方支付、互联网金融类公司采用较多，但由于需要安装安全控件，成本较高、对诸如电商等公司基本上不可行。
3、商户平台交易订单校验：电商等商户平台的用户将页面表单提交到服务器，服务器必须对订单信息进行计算、校验，包括金额、数量、商品信息、用户身份、session中的信息等。
4、支付请求订单签名：商户平台将支付请求信息提交给支付平台时候，需要同时带上签名信息，一般是用与支付平台约定的商户密钥串及签名算法对订单关键进行进行签名，例如md5(订单id+金额+商户id+商品id+密钥串)。支付平台接收到支付请求后，首先对请求验证签名。
此部分一般有两种方式：a、网页页面重定向方案 b、后台接口调用方案（直连接口）。
5、支付结果验证签名：商户平台在接收到支付平台请求后，一方面要对支付结果的签名进行验签，以避免被伪造支付结果。
此部分一般会采用页面重定向通知+后台通知结合的方式，一般尽量以后台通知结果为准。
二、针对APP等客户端的方案
整体方案思路与Web端类似，但由于APP必须在客户端对请求进行签名、验签，就面临加密算法及加密密钥存储在客户端，被恶意破解攻击的情况。这在android平台尤为突出。
一般采用代码混淆、对核心算法采用动态库、对密钥/证书加密存储等措施。
创建订单的时候严格校验涉及到金额的所有字段的合法性（根据产品id获得真实价格，判断数量的正负数），同时生成sign值返回到客户端，支付的时候客户端带上sign去支付接口支付。
这么理解吧，
前端验证是为了用户体验，如果说还有一点点贡献的话，就是帮助服务器分担一点运算压力。
而后端验证纯粹是为了安全性，保证不会有脏数据影响正常的业务流程。
你说的db验证是指的用sql验证吗？不必要吧，后端程序验证就好了，数据库压力够大了。
所以，不管你前端验证不验证，后端一定要验证输入的合法性。
在现实社会中，客户针对商户的购买消费行为，永远不会出现负数的情况；
解决这个问题，在服务端取 购买数量的绝对值，金额单价从数据库通过物品id，取得价格
最后在支付结算的过程，判断order的abs(总价)，金额为0，直接封号报警
第三方支付一直以来都存在这样的问题。可以说是无法避免的。支付宝还好一点点，微信的才叫差。
我想说，数据打碎和多数据流提交订单。比如通过重新打包，多次并发提交的办法。好比是集束炸弹，包和包之间不做差异化。这种方法出问题的可能性比较小一点，扰乱了劫持数据流被破解的可能性。
还有目前的sid签名鉴权的方法还有很多不足。一是绕圈子。在高并发的条件下暴露接口下限。开发各种拼字段，各个语言之间加密算法有区别还有效率的问题。最关键sid本身是可以泄露的。在sid泄露之后，修改相关信息补全漏洞不会那么顺利。
有必要硬件或者中间件解决鉴权的问题，这一点支付企业要做得更好。在服务器端像本地的中间件提交订单信息。
总之在目前流行的支付体系框架内，存在安全的问题。
关注
所有验证客户端和服务端各自处理
旅途
SSL证书加密和双向验证。