前端如何做好安全这块？

[Colorful]

我们公司主要做手机话费充值的，昨天突然被个人盗刷了，用 fiddler，然后修改参数，支付了上百笔。 每笔都是 1 分钱

框架用的是 vue，加前端端分离，公众号上的功能，支付是微信支付，支付的过程中是调用后端的接口。

知道大部分安全是由后端去弄，但请教下，前端能够做好哪些或者说哪些需要注意的？ 之前没接触过安全这块

现在已经改好了

[Greenm]

这不是前端的问题，甚至跟前端一段关系都没有。

绝大部分安全问题都是后端，纯前端的问题较少且一般危害较小，如 XSS

[whypool]

目前用了一个抖机灵的方式传参数的，大概流程是

前端把参数做 base64，然后在获得的字符串最前面拼接一个 5 位随机字符串，生成的新字符串发给后端

后端解 base64 之前先把最前面 5 位字符串删了，其他流程不变

虽然没有对称加密安全，但是能节省很多解密的开销，不了解的要破这样的 base64 还是有点难度

[yamedie]

@whypool 感觉纯前端加密都是自己骗自己, 图个安心, 有心人打开 js 仔细分析都可以分析明白

[Colorful]

@madNeal 的确是这样的

[Colorful]

@loading 提高成本能做哪些？

[python35]

前端能做的都能绕过，只是成本大小问题，金额校验本就应该后端做的呀，果断甩锅给后端吧。
弱弱问一句，盗刷的追回来没？

[Colorful]

@python35 报警了，后续，估计得下周才知道吧

[dko]

是不是有些限制只在前端做了，后端压根没做？

[ded]

每笔支付 1 分钱，这个问题与前端没有关系，服务端在风控做得不好，最简单的处理办法，服务端收到支付回调验证支付金额与实际物品金额-自己的优惠金额-支付渠道优惠金额即可。就算要做加密或者签名，也应该由后端来定义这个逻辑，而不是前端，其实，就算你拿服务端给的公钥做签名，一样可以伪造请求数据，对应他们而言可能是开始的破译的时候多一步而已

[chinvo]

支付传参和支付校验要在后端做啊，前端传过来充多少，后端就生成多少的支付订单

[yzkcy]

这个逻辑漏洞跟前端没半毛钱关系。
傻吊后端锅肯定得全背，这么弱智的逻辑都写得出。

[TMDlw]

@whypool 这样做感觉没啥用，你前端加密都是在 js 里面写的吧？人家查看一下你 js 就知道你做了什么加密

[whypool]

@yamedie 主要是因为 APP 安全扫描需要，明确规定不能明文传参，所以才有这方法，任何客户端加密基本是骗自己，无非就是提高一下破解难度而已

[yamedie]

@whypool 了解

[x86]

这个前端再怎么改，最终还是后端处理啊

[shuimugan]

0 元支付属于逻辑漏洞,归属后端.

前端能做的安全比较少,常做的有
* 富文本过滤:一些实时预览功能或者后端没有一个业界最好用的富文本过滤方案时,需要前端做富文本 XSS 过滤,可以使用* js-xss 库处理.防界面伪造 /劫持:2015 年左右,淘宝商品详情页,可以自己构造 div 和特别的 css,覆盖中差评区域,使得中差评* 无法点击.
* 保护隐私,通过 meta 标签控制 referrer 信息不外传
* 通过 meta 标签加入 CSP 策略

[Colorful]

@shuimugan

* 富文本过滤:一些实时预览功能或者后端没有一个业界最好用的富文本过滤方案时,需要前端做富文本 XSS 过滤,可以使用* js-xss 库处理.防界面伪造 /劫持:2015 年左右,淘宝商品详情页,可以自己构造 div 和特别的 css,覆盖中差评区域,使得中差评* 无法点击.
* 保护隐私,通过 meta 标签控制 referrer 信息不外传
* 通过 meta 标签加入 CSP 策略

你说的这些我全部都不知道了，也没用过

[momocraft]

在这个例子中，别人如果自己写请求总是可以绕过前端的...

保证代码混淆，增加逆向的成本
要求后端加上 csrf 和验证码
然后你自己写 UI 时可以顺便测后端的问题

[tookbra]

后端怎么判断支付成功的？不是微信支付发起的通知是否成功吗，难道通过 jsapi 前端返回？

[domty]

·然后修改参数，支付了上百笔。 每笔都是 1 分钱·

这锅你直接甩给后端
订单价格由前端提交?