这是一个创建于 443 天前的主题，其中的信息可能已经有所发展或是发生改变。
产品出的页面要求基本是直接使用的，没有用户、登录机制。
因为利益问题，某些接口出现了一些恶意请求来捣乱，我基于 IP 、客户端特征做了一些频率限制、封 IP 策略。
但无法根治，攻击方应该是专业黑产，封完 IP 或者客户端特征后，对方也会针对性的做调整来刷接口，基本上对方每天能换上百个 IP 来刷。
和产品聊过，产品不愿意做登录机制，验证码机制之类的。
因为利益问题，某些接口出现了一些恶意请求来捣乱，我基于 IP 、客户端特征做了一些频率限制、封 IP 策略。
但无法根治，攻击方应该是专业黑产，封完 IP 或者客户端特征后，对方也会针对性的做调整来刷接口，基本上对方每天能换上百个 IP 来刷。
和产品聊过，产品不愿意做登录机制，验证码机制之类的。
 |
1
stinkytofu 2023-09-12 14:51:53 +08:00
无解, 只能增加预算, 提高抗刷能力. 其次就算你做了登录和验证码, 只要想搞你, 还是能搞
|
 |
2
Puteulanus 2023-09-12 14:56:25 +08:00  1
接口要求附带签名，签名代码 JS 混淆
签名可以使用慢 hash ，用户操作的时候卡那么一下问题不大，批量刷的时候就会严重拖慢他请求的速度 |
 |
3
jianyang 2023-09-12 15:00:32 +08:00
先查 IP 信息、如果是家宽就根据实际情况限流、如果是数据中心、机房 IP 就不返回正常数据
查 IP 信息有一定的误差、感觉这个误差应该不会好大 |
 |
4
codeself 2023-09-12 15:03:10 +08:00
不一定全部加验证码,针对某个 ip 请求频繁了加验证码,
这样的话, 一方面不影响正常用户请求(正常用户每分钟用人肉不可能请求这么频繁,所以不会触发验证码) 另一方面,可以加大攻击方的成本(当所得利益小于换 ip 的成本时,就不刷了) |
|
5
Puteulanus 2023-09-12 15:09:09 +08:00
防 headless 浏览器的话还可以试试帆布指纹
|
 |
6
lmq2582609 2023-09-12 15:09:22 +08:00
只能是参数加解密+混淆前端代码来提高破解成本了吧，但也只是提高破解成本而已
|
 |
7
hdczsf 2023-09-12 15:12:46 +08:00 6
如果高速刷可以试试 POW： https://www.cnblogs.com/index-html/p/web-pow-research.html
如果是抓取信息的话，检测到是爬虫不要直接拒绝，而是给返回的信息里搀屎，一会假一会真，真中有假，假中带真，总之找不到规律，让对方无从判断是不是被检测到了，主动权在你手里，早晚玩得对方欲仙欲死。 如果是提交接口也一样，返回都是正常的，后台默默的过滤掉就可以了，不要让对方知道提交是成功还是失败了。 |
 |
8
gogo789 2023-09-12 15:19:19 +08:00
可以试试滑块验证码，很多网站都有这个，用户也比较能接受，然后根据场景定义一些触发滑块的策略，能很有效的拦截。如果连滑块都不愿意用，单纯靠封 ip ，就很被动，只能发现一批处理一批，而且也可能存在误杀。当然如果公司有这一部分预算的话，可以去买阿里云或者腾讯云的 风险识别
|
 |
10
billzhuang 2023-09-12 16:09:29 +08:00
WAF 就可以看这个
|
 |
11
lincanbin 2023-09-12 16:12:05 +08:00
cloudflare 就有相关的防火墙吧
|
 |
12
myderr 2023-09-12 17:39:03 +08:00
就 web 应用，如果我先爬取一次页面，获取到一批 pow_ques,然后新的程序一直计算 Hash,提交程序在进行高频提交呢
|
 |
13
cs3230524 2023-09-12 17:53:57 +08:00
换个产品。
|
 |
14
xiangyuecn 2023-09-12 17:55:38 +08:00
既要 又要 这也不能 那也不能，无解。直接不管，多花钱升级服务器，加带宽，又不是花自己的钱，不要抠抠搜搜的
|
 |
15
javalaw2010 2023-09-12 18:00:20 +08:00
换个思路，从用户行为入手，假设正常用户的行为是 A 页面->B 页面->活动页面，而黑产的行为是直接打开活动页面的话，则在 A,B 页面中的接口中记录用户行为。活动页面的接口里面判断是否有 A/B 页面的行为，如果没有的话，判断为高风险用户，直接弹验证码。
如果普通用户和黑产都是直接进活动页的话，也可以在活动页记录用户产生的一些随机行为来判断高风险用户。 |
 |
16
yunfangyu7 2023-09-12 18:09:10 +08:00
@brader 可以加我聊聊 能解决 V d2l0aC0tdGVh
|
|
17
yunfangyu7 2023-09-12 18:14:05 +08:00
@brader 刷接口的这种情况，靠手动去封 ip 段，是非常麻烦的，有的 ip 并没有访问特征，甚至有的会模仿正常用户访问，这个情况容易封正常用户，导致体验感极差
|
 |
18
adoal 2023-09-12 18:22:56 +08:00
这个事是谁说了算的？
|
 |
19
lakehylia 2023-09-12 18:25:49 +08:00 1
不换思想就换人，把产品换了
|
 |
21
dongtingyue 2023-09-12 18:43:15 +08:00
cdn 的人机检测？
|
 |
22
fruitmonster 2023-09-12 19:09:06 +08:00
你不得说清楚是客户端，还是 H5 网页么？
|
 |
23
me1onsoda 2023-09-12 19:42:46 +08:00
我寻思登录也不是给你防刷啊？
一般来说，是就是套个 cf 做真人检验 |
 |
24
tutudou 2023-09-12 20:51:57 +08:00
用 js 判定一下页面的鼠标值，如果对方破解的话，发包的时候大概率会把鼠标值写死发过去，然后再判断一下对方的鼠标值是否有连续性，这样对方如果没注意随机值的范围的话也会露馅。不过建议使用字库加密的方法，某个电影票网站用的就是这个方法，然后再写一个小软件每天生成一下字库，每天都换新的字库。如果对方还那么坚持的话，那就没办法了。
|
 |
25
aulayli 2023-09-12 21:04:17 +08:00
没有验证码吗？加上类似谷歌验证码那样的选择图片的反人类验证码
|
 |
26
dayeye2006199 2023-09-13 01:23:22 +08:00 via Android
上个 CDN 的盾吧
|
 |
27
mmdsun 2023-09-13 09:30:27 +08:00 via iPhone
浏览器指纹
google recaptcha v3 验证无感知的，被拦截了再弹窗做验证码。 |
 |
28
zengxs 2023-09-13 12:08:30 +08:00
产品应该是想要保障用户体验才不想加验证码吧
可以考虑用 recaptcha v2 invisible 吧，用户环境低风险时不会弹验证码框，高风险用户才会图片验证码糊脸，对正常用户基本上是无感知的，不会影响用户体验 recaptcha v3 则是完全无感知的，无论如何都不会弹验证码，但是目前判断不是很准，不太推荐 |
 |
29
yagamil 2023-09-13 12:20:29 +08:00
主要是刷什么呢？ 如果是流量的话，套个 cdn 限速。
|
 |
30
starinmars 2023-09-13 16:54:59 +08:00
请求过来的时候先查一下 ip 是不是数据中心，是的话拉到黑名单（拉整段地址），请求频率也做一下限制。然后根据业务特性做一些针对性限制吧。
|
 |
31
brader OP |
Select Language