电子商务的支付信息在提交订单时候有哪些技术可以保证交易金额、数量、等相关参数不被主动攻击篡改提交？
之前也在乌云看到很多类似被挖出的逻辑设计部严禁，导致在生成订单时候金额为负数或者小额 支付的情况。
例如
如果放在前端逻辑进行计算，就可能被篡改的可能。但是如果放在后端的话，当结算逻辑比较复杂的话，后端如果放在数据库端的话，可能需要频繁变更。
即使放前端的话，后端在写入数据也是必须要验证。
还是前端页面--前端计算规则计算结果--验证引擎（前端程序验证还是后端DB验证？）--写入后台DB 这样子的模式哪一种比较好？还是有更好的方案？
题主提到的问题，虽然是防篡改问题，但大部分情况下防篡改问题，都会涉及防抵赖、防泄密等安全问题。
大的思路：
尽量在服务器端对数据进行计算、加密、签名、验签，避免将加密/签名算法及加密/签名密钥暴露给外界，降低被攻击的可能性。
针对防篡改的方案，Web端与移动端的方案不完全相同。
一、针对Web应用的一般的方案
之所以采用双向SSL要安全些，主要是避免了中间人攻击（MITM）。
2、采用诸如浏览器安全控件等机制，在浏览器端对页面表单提交数据进行加密、防窃听等。此种方案在银行、第三方支付、互联网金融类公司采用较多，但由于需要安装安全控件，成本较高、对诸如电商等公司基本上不可行。
3、商户平台交易订单校验：电商等商户平台的用户将页面表单提交到服务器，服务器必须对订单信息进行计算、校验，包括金额、数量、商品信息、用户身份、session中的信息等。
4、支付请求订单签名：商户平台将支付请求信息提交给支付平台时候，需要同时带上签名信息，一般是用与支付平台约定的商户密钥串及签名算法对订单关键进行进行签名，例如md5(订单id+金额+商户id+商品id+密钥串)。支付平台接收到支付请求后，首先对请求验证签名。
此部分一般有两种方式：a、网页页面重定向方案 b、后台接口调用方案（直连接口）。
5、支付结果验证签名：商户平台在接收到支付平台请求后，一方面要对支付结果的签名进行验签，以避免被伪造支付结果。
此部分一般会采用页面重定向通知+后台通知结合的方式，一般尽量以后台通知结果为准。
二、针对APP等客户端的方案
整体方案思路与Web端类似，但由于APP必须在客户端对请求进行签名、验签，就面临加密算法及加密密钥存储在客户端，被恶意破解攻击的情况。这在android平台尤为突出。
一般采用代码混淆、对核心算法采用动态库、对密钥/证书加密存储等措施。
作者：梁川
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。