这是一个创建于 2096 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们公司主要做手机话费充值的，昨天突然被个人盗刷了，用 fiddler，然后修改参数，支付了上百笔。 每笔都是 1 分钱
框架用的是 vue，加前端端分离，公众号上的功能，支付是微信支付，支付的过程中是调用后端的接口。
知道大部分安全是由后端去弄，但请教下，前端能够做好哪些或者说哪些需要注意的？ 之前没接触过安全这块
现在已经改好了
第 1 条附言 · 2019-02-14 17:52:33 +08:00
我发贴的目的，不是说甩锅什么的，我只是想知道下，在安全这块，前端有哪些可以做的。我知道基本上都在后端，我只是想多了解下，前端能做的有哪些，之前没接触过安全这块。突然碰到了，就想请教下.
 |
1
CodingMonkey 2019-02-14 09:33:41 +08:00
1. 上 https
2. 将参数用服务端提供的公钥加密后再传输 |
 |
2
ranxfan 2019-02-14 09:36:37 +08:00
主要问题还是在后端，不如让后端重新考虑一些问题？
|
 |
3
Colorful OP |
 |
5
madNeal 2019-02-14 09:38:46 +08:00
是不是逻辑漏洞 前后端都得考虑
|
 |
7
loading 2019-02-14 09:42:59 +08:00 via Android
前端按我的理解是，没法做安全，只能提高成本。
|
 |
8
yamedie 2019-02-14 09:43:13 +08:00
每笔都付 1 分钱? 后端开发得背锅啊, 你们接口难道是把商品的 price 作为入参, 由前端传入后台?
|
 |
11
whileFalse 2019-02-14 09:48:51 +08:00
这和前端有个毛线关系。人家直接构造参数调后端接口，关前端 P 事。
|
 |
12
micean 2019-02-14 09:49:03 +08:00
要不把请求参数全部加密吧……费力不讨好
|
 |
13
yidinghe 2019-02-14 09:50:12 +08:00
前端需要注意的安全问题包括：
1、会话不能被窃取或伪造。因为所有的请求都可以通过 F12 看到，所以不能在请求参数当中带上用户 ID 之类的，否则用户换一个 ID 就能冒充其他用户。 2、页面内容注入和跨站点攻击。其实这当中有一部分是需要后端来防范，但前端也需要注意脚本方面的安全。比如不要引用非 HTTPS 的外部资源。 3、权限方面的安全。首先后端开发时刻都要把一条原则放在心上，就是任何请求和会话都是可以不经浏览器直接构造的，所以后端的接口设计应该尽可能保守，参数应该尽量少。而前端也需要在这点上配合，不能为了图自己开发方便而要求后端接受多余的参数。 |
 |
14
yhxx 2019-02-14 09:50:42 +08:00
这个和前端没多大关系
甩锅给后端吧 前端能做的很少 |
 |
15
learnshare 2019-02-14 09:51:32 +08:00
跟前端没有半毛钱关系
|
|
16
madNeal 2019-02-14 09:51:33 +08:00
@Colorful 老实说 像这种 主要还是后端还要做验证 感觉这个漏洞利用的思路可能是这样 它请求支付 让后修改了支付价格 然后你们收到了微信支付的成功的响应，就认为支付成功了，应该做进一步的校验。
前端可以做的，我觉得主要也就是配合后端一起做，防 XSS，CSRF 这种的，注重逻辑这一块吧 |
 |
17
tomczhen 2019-02-14 09:51:49 +08:00 via Android
请求加 signature，后端不能无条件相信前端返回数据。
|
 |
18
FakeLeung 2019-02-14 09:51:53 +08:00
无疑是后端的锅，前端的安全，有心搞你，基本都能摸索出来。
|
|
19
yamedie 2019-02-14 09:53:53 +08:00
总之是接口参数定义的有问题, 应该只传商品 ID 就可以, 但你们鬼使神差的由前端决定商品价格
|
|
20
ranxfan 2019-02-14 09:54:19 +08:00
@Colorful 前端没啥好做的（上 https，请求参数签名），但是并无作用，完全可以分析你的代码，伪造请求。
你的问题看似是服务端没有验证微信支付收到的金额，完全相信前端发的数据。 |
 |
21
Greenm 2019-02-14 09:55:58 +08:00
这不是前端的问题，甚至跟前端一段关系都没有。
绝大部分安全问题都是后端，纯前端的问题较少且一般危害较小，如 XSS |
 |
22
whypool 2019-02-14 09:57:33 +08:00  2
目前用了一个抖机灵的方式传参数的，大概流程是
前端把参数做 base64，然后在获得的字符串最前面拼接一个 5 位随机字符串，生成的新字符串发给后端 后端解 base64 之前先把最前面 5 位字符串删了，其他流程不变 虽然没有对称加密安全，但是能节省很多解密的开销，不了解的要破这样的 base64 还是有点难度 |
 |
26
python35 2019-02-14 10:02:43 +08:00
前端能做的都能绕过，只是成本大小问题，金额校验本就应该后端做的呀，果断甩锅给后端吧。
弱弱问一句，盗刷的追回来没？ |
 |
28
dko 2019-02-14 10:04:08 +08:00
是不是有些限制只在前端做了，后端压根没做？
|
 |
29
ded 2019-02-14 10:04:47 +08:00
每笔支付 1 分钱，这个问题与前端没有关系，服务端在风控做得不好，最简单的处理办法，服务端收到支付回调验证支付金额与实际物品金额-自己的优惠金额-支付渠道优惠金额即可。就算要做加密或者签名，也应该由后端来定义这个逻辑，而不是前端，其实，就算你拿服务端给的公钥做签名，一样可以伪造请求数据，对应他们而言可能是开始的破译的时候多一步而已
|
 |
30
chinvo 2019-02-14 10:04:59 +08:00 via iPhone
支付传参和支付校验要在后端做啊，前端传过来充多少，后端就生成多少的支付订单
|
 |
31
yzkcy 2019-02-14 10:06:32 +08:00
这个逻辑漏洞跟前端没半毛钱关系。
傻吊后端锅肯定得全背，这么弱智的逻辑都写得出。 |
|
33
whypool 2019-02-14 10:15:14 +08:00
@yamedie 主要是因为 APP 安全扫描需要，明确规定不能明文传参，所以才有这方法，任何客户端加密基本是骗自己，无非就是提高一下破解难度而已
|
 |
35
x86 2019-02-14 10:17:47 +08:00
这个前端再怎么改，最终还是后端处理啊
|
 |
36
shuimugan 2019-02-14 10:20:32 +08:00 1
0 元支付属于逻辑漏洞,归属后端.
前端能做的安全比较少,常做的有 * 富文本过滤:一些实时预览功能或者后端没有一个业界最好用的富文本过滤方案时,需要前端做富文本 XSS 过滤,可以使用* js-xss 库处理.防界面伪造 /劫持:2015 年左右,淘宝商品详情页,可以自己构造 div 和特别的 css,覆盖中差评区域,使得中差评* 无法点击. * 保护隐私,通过 meta 标签控制 referrer 信息不外传 * 通过 meta 标签加入 CSP 策略 |
|
37
Colorful OP @shuimugan
* 富文本过滤:一些实时预览功能或者后端没有一个业界最好用的富文本过滤方案时,需要前端做富文本 XSS 过滤,可以使用* js-xss 库处理.防界面伪造 /劫持:2015 年左右,淘宝商品详情页,可以自己构造 div 和特别的 css,覆盖中差评区域,使得中差评* 无法点击. * 保护隐私,通过 meta 标签控制 referrer 信息不外传 * 通过 meta 标签加入 CSP 策略 你说的这些我全部都不知道了，也没用过 |
 |
38
momocraft 2019-02-14 10:29:51 +08:00
在这个例子中，别人如果自己写请求总是可以绕过前端的...
保证代码混淆，增加逆向的成本 要求后端加上 csrf 和验证码 然后你自己写 UI 时可以顺便测后端的问题 |
 |
39
tookbra 2019-02-14 10:30:41 +08:00
后端怎么判断支付成功的？不是微信支付发起的通知是否成功吗，难道通过 jsapi 前端返回？
|
 |
40
domty 2019-02-14 10:33:31 +08:00
·然后修改参数，支付了上百笔。 每笔都是 1 分钱·
这锅你直接甩给后端 订单价格由前端提交? |
 |
41
ByZHkc3 2019-02-14 10:37:27 +08:00
明显是没有对价格参数做校验啊
|
 |
42
amazingrise 2019-02-14 10:40:13 +08:00 via Android
@Colorful 楼上有个人说的对，post 时传商品 id 就可以。公钥加密也不行。fiddler 通过 mitm 把 https 都给破了。。公钥加密也是属于密码学的忌讳，自己造轮子了，还不如 https。。改成传商品 id 就 ok
|
|
44
Colorful OP @amazingrise 这倒是个不错的想法
|
|
45
yamedie 2019-02-14 10:42:41 +08:00
上 HTTPS,
既然是微信公众号项目, 至少不要让页面在非微信浏览器里被访问 (用微信 snsapi 静默授权可以保护起来) |
|
46
amazingrise 2019-02-14 10:42:49 +08:00 via Android
哦对了还要设定同一 ip 交易间隔，防止恶意刷单。不过我感觉这不太像前端的锅，前端手段解决得不是很彻底。。
|
 |
47
otakustay 2019-02-14 10:43:17 +08:00
这是标准的重放攻击了，跟前端没啥关系，加验证码加手机短信验证吧
|
|
49
Colorful OP @amazingrise 同一 IP 交易间隔，这个确实不错
|
|
50
amazingrise 2019-02-14 10:44:28 +08:00 via Android
@yamedie 虽然 https 对 fiddler 无效，但是微信授权这个很棒！
|
|
51
amazingrise 2019-02-14 10:47:30 +08:00 via Android
如果非要在前端动手脚，可以学学 Google 登录的套路，我记得有个文章分析过。个人水平局限，了解不深，lz 可以去搜索一下相关分析文章。不过这个难度不小。。。
|
|
52
Colorful OP @amazingrise 好的，感谢，我去找找
|
 |
53
cyclone 2019-02-14 11:01:59 +08:00
《 Web 前端黑客技术揭秘》 钟晨鸣 / 徐少培
不想深入可以只看最后一章 |
 |
54
kisshere 2019-02-14 11:42:00 +08:00
第一次听说前端还和安全挂钩。。。
|
 |
55
M4ster 2019-02-14 11:55:15 +08:00
对提交参数进行签名，签名算法的代码做好混淆保护，很大程度上可以提高攻击 /测试者的门槛。
|
 |
56
nekoneko 2019-02-14 12:01:54 +08:00
杀死前端
|
 |
57
lutla 2019-02-14 12:33:37 +08:00
……前端被迫干安全？
|
 |
58
chairuosen 2019-02-14 12:35:13 +08:00
绝对是设计不合理造成的
|
|
59
loading 2019-02-14 12:38:01 +08:00 via Android
所谓的提高成本是把菜鸟挡一下，在金钱面前，抓包花点时间就搞定了。
后端职业操守:永远不相信用户发来的数据。 |
 |
60
killerv 2019-02-14 13:33:01 +08:00
前端需要注意的安全一般是 xss 这些，你说的这个问题是后端的范围。
|
 |
61
iAcn 2019-02-14 13:39:04 +08:00 via Android
后端开发第一条就是 永远不要相信前端
|
 |
62
janxin 2019-02-14 13:59:19 +08:00 via iPad
你们后端都在装死嘛？
|
 |
63
shuax 2019-02-14 16:02:52 +08:00
和前端有屁关系
|
 |
64
xpsilvester 2019-02-14 17:48:56 +08:00 via iPhone
这个跟前端无关吧
|
Select Language