这是一个创建于 150 天前的主题，其中的信息可能已经有所发展或是发生改变。
防重放解决的是攻击者拿到 url 和参数之后，不断地请求服务端。
-
服务端针对下单，支付，转账这种操作肯定有幂等，肯定不能胡来乱来
-
放重放生成一个 token ，这个 token 人人都知道如何生成的，比如 timestap+参数 用 md5 进行加密，攻击者也可以完全模拟这个 token 的生成规则，来绕过服务端
-
像 https ，客户端私钥加签服务端公验证，都是解决过程中的安全，放重放解决“客户端”的安全，感觉完全没必要，反而增加了成本
上周面试被问到，感觉存粹为了面试而面试，包括 sync ，lock ，多线程等，工作中根本用不到，完全不问业务上的问题，上来就啪啪的八股文走起。
为了面试由此写了一篇接口放重放的文章，欢迎大家指正，真感觉多次一举，为了面试而面试。
我真不相信，哪一家，真的在项目中写了防重放的实现逻辑。
94 条回复 • 2024-08-07 09:55:27 +08:00
 |
1
yuhaofe 150 天前  2
重点是看防谁、防什么吧，不就是你文章里说的增加攻击人的成本吗，看你想不想防比如我这种看到个接口就想调试下的脚本 boy😂，可能看到麻烦点就放弃了
|
 |
2
zjp 150 天前 via Android
云服务的接口都有防重放
没有可以实现幂等的地方，只能在请求参数上防止重复请求 |
 |
3
porjac233 150 天前 via iPhone 38
你出门好会锁门吗？ 你知道开锁师傅开个锁仅需几分钟吗？ 锁门是不是脱裤子放屁？
安全不绝对，所以安全措施就没必要存在？ 什么 2B 结论？ |
 |
4
kran 150 天前 via Android
甚至不知道哪家会不防请求重放
|
 |
5
whusnoopy 150 天前
我司写了
一是出于本能的安全防御 二是服务部署在平台方的私有云上，平台方的安全团队会时不时重放 URL 请求来做安全监测 |
 |
6
MMM25O7lf09iR4ic 150 天前
这是很常见的方案，你的最后一行疑问才是比较离谱的，没用过的话见也应该见过不少，特征为 timestamp+nonce 。
|
 |
7
IvanLi127 150 天前 8
不是拿不到 url 和参数的时候，把抓的包拿去重放吗？你开头是不是直接错了
|
 |
8
forvvvv123 150 天前
楼上正解，防止重放一般是考虑攻击者拿到了正常用户的流量，仿冒正常用户去请求的这种场景；
|
 |
9
StinkyTofus 150 天前 1
只要不是个人随便玩玩的项目， 接口防重放是必须做的， 参数加签都是标配的。 但凡对接过其他公司的 API 都不会有这样的疑问。
|
 |
10
LeeReamond 150 天前
说了半天感觉不对。我感觉问题可能是现在传输层都用 tls 保护了，是否还有必要实现业务防重放
|
 |
11
ysc3839 150 天前 via Android 1
按我个人理解，重放攻击属于中间人攻击，防重放攻击防不了客户端攻击，而 HTTPS 本身已经有防重放攻击的能力了，所以不需要自己特意去防重放攻击。你文章里提到的情况，实际不是重放攻击，而是“非官方客户端”，攻击者尝试绕过你的客户端逻辑，直接请求接口。
|
|
12
LeeReamond 150 天前
还有一个问题是，例如 select 类操作，实现幂等很容易。新添加数据，加入幂等也不难。但是例如 A 给 B 转账这种操作能实现幂等吗？
|
 |
14
Aloento 150 天前 1
安全不绝对 = 绝对不安全！
|
 |
15
wind1986 150 天前 2
包括 sync ，lock ，多线程等，工作中根本用不到
想问问工作几年了, 怎么会这些用不到 |
|
16
StinkyTofus 150 天前
@wind1986 #15 我估计他都没说完， 事务，分布式锁我估计他也用不到🐶
|
 |
17
xmumiffy 150 天前
是,大部分人要的不是防重放,而是 1. 防爬虫 2. 限频
|
 |
18
akira 150 天前 4
啊？ 重放最主要不是要解决用户手抖的问题么。。其他的都是顺带的呀
|
 |
20
angeni 150 天前 2
这种面试其实看的是你的下限，不是上限。
个人感觉八股文其实是软件发展的一个脉络，应该懂但是不要照本宣科 最后你的那句 `防重放用处不大` 是完全错误的，每个注入点都是血的教训我举个场景 验证码重放可以遍历用户弱口令，短信发送重放可以刷接口或者做短信轰 X 炸 |
 |
21
binux 150 天前 via Android 1
最近做了一个买票刷票软件，虽然它对请求加密了，但是就是因为没有防重放，连解密都省了
|
 |
22
purrgil 150 天前
不防重放的话，抓包，下载个 curl 然后复制 http 请求到.bat 里循环执行，就直接刷得飞起了。
|
 |
23
weijancc 150 天前
我之前爬过许多大网站的接口, 防重放可以说是基操了.
|
 |
24
macaodoll 150 天前 via Android 1
一看就是没接触过电商抢购功能。
|
 |
25
yxzblue 149 天前 7
攻击者也可以完全模拟这个 token 的生成规则，来绕过服务端
攻击者怎么会知道服务端的生成规则？ |
 |
26
skuuhui 149 天前
在移动端刚兴起的年代，大部分防重放是为了解决弱网环境下重试导致的无效请求的问题。现在技术成熟了，确实失去了百分之 99 情况下的用处了。现在还执着追求这个的，要么历史原因，要么过于迂腐了。对于大部分程序员来说，模仿很容易，动脑真的很难
|
 |
27
crackidz 149 天前
重放不是指 TCP 流重放，是指 HTTP 的接口重放，不在同一层。
即便通过 token 防止重放，也不应该单纯使用三方都知道的信息生成，至少应该包含攻击方不知道的信息 |
 |
28
dj721xHiAvbL11n0 149 天前 1
你要不先看看你有多少错别字？
2.token 的生成，是一种对原信息的签名操作，因为只有服务器有秘钥，所以你不可以伪造 3.https 客户端什么时候能用私钥签？服务器用公钥验，你要不要看看你说的什么？ |
 |
29
darkengine 149 天前
想得挺美，我是不会点那个链接 /狗头
|
 |
30
InkStone 149 天前
1. 防重放的 nonce 可以服务端生成下发。
2. 仅客户端也可以做防重放的，加固了解一下。别说什么加固也可以破，现实是就是有很多加固现在还好好运行在那里没被破。 |
 |
31
wqhui 149 天前
https 保证的是传输过程安全，但你怎么保证发起请求的人是可信的
请求的 token 一般会混入一些像私钥一样的东西，要生成先得盗私钥 多线程之类的不算八股文，日常偶尔就用，除非问你底层 JVM 怎么实现 sync 跟 lock ，19 年的账号居然没用过多线程。。 |
 |
32
geligaoli 149 天前
接口的重放攻击，基本是必然遇到的。做过的项目，只要用户量一大，无论是否公开，必然在日志里面会记录到重放攻击。处理实际也好办，幂等或 hash 过滤。
|
 |
33
FawkesV 149 天前
sync ，lock ，多线程 这不是很常用的吗??
|
 |
34
dhb233 149 天前
一个很现实的问题，支付接口是幂等的，QPS 能支持多大？防重放能支持多大 QPS ？
|
 |
35
jqknono 149 天前
认清自己
|
 |
36
cnevil 149 天前
"放重放生成一个 token ，这个 token 人人都知道如何生成的，比如 timestap+参数 用 md5 进行加密，攻击者也可以完全模拟这个 token 的生成规则，来绕过服务端"
我怀疑你连 token 都没搞明白 |
 |
37
blankmiss 149 天前
包括 sync ，lock ，多线程等，工作中根本用不到 ， 你们是什么公司 还是说你菜的一匹
|
 |
38
salmon5 149 天前
|
|
39
salmon5 149 天前
你以为客户端 HTTPS 安全，客户端的浏览器可不老实。
|
 |
40
zhwguest 149 天前
接口上 timestamp + nonce ，nonce 在 now + timer 时间范围内缓存，非常简单基础的方案，自己把问题想岔了吧？
|
 |
41
hallDrawnel 149 天前
你甚至已经分析到了掘金的点赞防重复逻辑，在进一步想放重放逻辑不是千篇一律的啊。我们所有有重放可能的接口都有防重放逻辑。
|
 |
42
Richared 149 天前
其实这些我一直有个疑问，不管用什么方式去做，都不能影响正常用户请求吧。比如 timestamp 过期了，正常的用户是给续期么？那么做攻击的人不是也可以续期。
|
 |
43
lovelylain 149 天前
防重放 token 可能是上一步接口后台生成返回，上一步接口可能是验证用户登录态是用户行为触发，登录态和 token 都有时效性。
|
 |
44
sampeng 149 天前 1
这个问题嘛。。。怎么说呢。只能说，你经验太少。所以觉得很无所谓。
我作为运维，要是谁的接口涉及到钱的不做防重放。我直接就贴脸放大了。是是是。你懒得做，然后我一看账单短信被刷几十万，被骂的人是我。研发来一句脱裤子放屁试试。。 这是主问题。次问题。。是是是，你用不到就是八股文。 那我是不是可以建一个画像： 1.crud Boy 2.不学习任何计算机底层知识。sync ，lock ，多线程在很多领域都要用。你只会 crud 当然涉及不到，你还不学。业务有啥？很高精尖吗？写个 crud 能写出花来？ 3.对于技术只停留在表象，不深究其原理和为什么要这么做 你一句不信，我默默看着我司代码库里面这都是啥？我们组十年前的项目不带防重放，技术评审都过不去 |
 |
45
tomkliyes 149 天前
我理解的防重放：一个请求发过去了，但是服务器没有响应，客户端不知道是否成功了，如果没有幂等 id ，客户端再发一个请求过去，服务器可能把两个请求当成独立的，分别处理了。
|
 |
46
aino 149 天前
我以前和你一样的想法，后面我明白了，面试官问的就是想得到他想要的答案罢了，你想那么多干嘛呢，管他什么呢，问啥就说啥，你爽我也爽，也许你瞧不起面试官，觉得他问的东西浅薄，但是你也确实需要这份工作
|
 |
47
iX8NEGGn 149 天前 2
你把“重放”理解错了，计算机网络和网络安全相关书籍中都提到“重放攻击”，防重放是 HTTP 时代的一种安全措施，它是网络层的东西不是应用层，防的网络层中间人抓包后原封不动把包发给服务端。
不做防重放即使加密通信也没用，但 HTTPS 自带加密和防重放功能，如果现在还使用原先的防重放做法，那它的主要用作就是提高反扒的难度。 |
 |
48
TeresaPanda 149 天前
可以增加一点攻击者的调试难度吧
|
 |
49
yankebupt 149 天前
@bigbigeggs 如果客户端不那么瘦，可以拿到自己的公网 ip 地址，那么在不那么信任时间戳（比如网络很差或 CPU 调度很差，NTP 精确不到 1 秒）的时候还能多一种选择
毕竟重放攻击大部分时候是时间不同，ip 地址不同（有 ip 一样的，少见，毕竟攻击者自己拿不到回复了） 猜测神经过敏一点的人甚至会用包 TTL 波动 filter 重放攻击要求重新登陆，我觉得太容易误判了…… |
|
50
iX8NEGGn 149 天前
至于 OP 说的 “我真不相信，哪一家，真的在项目中写了防重放的实现逻辑。”
我随便找了几个大厂的文档，签名中带有时间或者随机数的大都是用来放重放的： 阿里： https://help.aliyun.com/zh/sdk/product-overview/rpc-mechanism SignatureNonce 参数的描述：“签名唯一随机数。用于防止网络重放攻击，建议您每一次请求都使用不同的随机数，随机数位数无限制。” 腾讯： https://cloud.tencent.com/document/product/551/15615 Nonce 参数的描述：“随机正整数，与 Timestamp 联合起来，用于防止重放攻击。” 火山： https://www.volcengine.com/docs/6469/93892 t 参数的描述：“来自火山引擎的事件通知请求默认过期时间是 10 分钟，如果一条事件请求通知中的 t 值所指定的时间已经过期，则可以判定此条事件请求通知无效，通过此方法可以防止网络重放攻击。” |
 |
51
lyxxxh2 149 天前
第一次听说"接口防重放",查了下资料:
"一条消息表示用户支取了一笔存款，攻击者完全可以多次发送这条消息而偷窃存款。" --- 来自: https://juejin.cn/post/6890798533473992717 总结: 扯淡。 1. 发多次? 难道不校验金额? 2. 并发的话,接口幂和悲观锁是吃干饭的? 楼主第一句也说了: "服务端针对下单，支付，转账这种操作肯定有幂等，肯定不能胡来乱来" *** 重放攻击（英語：replay attack ，或称为回放攻击）是一种恶意或欺诈的重复或延迟有效数据的网络攻击形式。 这可以由发起者或由拦截数据并重新传输数据的对手来执行。这是“中间人攻击”的一个较低级别版本。 --来自: https://zh.wikipedia.org/wiki/%E9%87%8D%E6%94%BE%E6%94%BB%E5%87%BB 所以可知,防重放就是专门针对这种攻击。 不过正如楼主所说: 大部分都是 https,你都获取不到客户端请求。 我也赞同是脱了裤子放屁。 除非你项目是金融级别的。 |
 |
52
SSang 149 天前
很明显，你对重放的理解就不对。防重放是用来防中间人攻击的。不然你以为 https 的 seq_num 是用来干什么的。客户端攻击那不叫重放，最多叫 DDOS
|
|
53
SSang 149 天前 1
还有，幂等是幂等，重放是重放，看起来好像都是请求两次相同的数据，本质上一个是客户端行为，一个是中间人行为，一个是业务，一个是安全。
|
|
54
SSang 149 天前
1. 下单，支付，转账，这种一般是做幂等，但做不做幂等和做不做防重放没有关系。不是说你幂等了就不需要防重放了。
2. 客户端一般只生成 nonce ，生成 token 干嘛？除非你要搞回调。 3. 重放解决的是过程安全，你说的所谓客户端安全，那叫防抖或防 DDOS 吧。 |
 |
56
enumer 149 天前
安全不绝对就是绝对不安全
|
 |
58
Nosub 149 天前
op 主应该很少抓包，防止重放肯定不是脱裤子放屁；
很久之前我就写了一篇文章， HTTP 请求数据签名原理以及实战，https://nosub.net/posts/p/72 对所有 HTTP 请求和返回数据做签名校验，拒绝中间人攻击； https://nosub.net/posts/p/70 |
 |
59
zephyru 149 天前 3
安全上用处的确不大，防脚本小子的确是很有用...毕竟打开 F12 复制个接口请求，各种模拟组合拉数据成本实在太低了...
虽然逆向肯定是拿的到这些重放用的参数，但怎么都是成本不是 |
 |
60
dif 149 天前
多线程经常用到吧。
|
 |
61
dode 149 天前
领优惠礼品，网速慢，连点了几下，领到了好几份话费
|
|
62
dode 149 天前
接口幂等，岂不是在更高的层次上实现了接口防重放
|
 |
63
ShuWei 149 天前
op 还是太年轻了
|
 |
66
totoro52 149 天前
没接触过 = 没用
|
 |
67
index90 149 天前
1. 防重放和幂等是两码事，不要混为一谈。
2. 你在胡言乱语，你需要搞清楚票据和签名的概念。除非攻击者掌握私钥，否者即使知道算法也无法模拟真实用户请求。 3. https 也可以重放的，另外什么是“放重放解决“客户端”的安全”，又是胡言乱语。 |
 |
68
bigbigeggs OP @cnevil token=MD5(timestamp+参数)生成的，假设你的项目中使用了防重放，我难道不知道你的这个 token 的生成规则？普遍都是这样生成的，很容易就能猜到的
|
|
69
bigbigeggs OP @yxzblue token=MD5(timestamp+参数)生成的，假设项目中使用了防重放，很容易就知道这个 token 的生成规则，所以这也是我比较诟病的一点，我想过通过加 salt 来解决，但是前端怎么安全保证这个 salt 呢？
|
|
70
bigbigeggs OP 1. 大部分人回复还是比较友好的，一部分人戾气比较重，没必要哈，大家都相互不认识，纯纯上网冲浪
2. 多线程的确不是八股文会用到，写差了。sync ，lock 谁在工作中用到？这不纯纯的八股文，要也是分布式锁 3. 防重放我理解评论有些人应该讲清楚了，应该为了防止中间人攻击。但防不住真实的用户拿到 url ，去循环请求。比如掘金的那个点赞(掘金那个感觉是查了一边数据库，然后返回重复点赞的) 4. 防重放的 token 生成规则，token=MD5(timestamp+参数)生成的，这个我感觉没用啊，人人都知道这个规则，我随便用 f12 就知道怎么生成的了 |
|
71
yxzblue 149 天前
@bigbigeggs token=MD5(timestamp+参数)
已知 token: ff0ff58ff2b0901d47b8070ec0819812 ，timestamp: 1718117839 ，求解参数？ |
|
72
Nosub 149 天前 via iPhone
op 主的问题是，自己有了结论，要别人认同你的结论，而大部分人不认同。
其实这个问题很好理解，你家里有一把门锁，大家都觉得锁的存在是有价值的，有用的，你觉得没用，你的道理是门锁是都可以撬开，撬不开也可以砸开，安装了也是摆设。 很多人应该会认同一个观点：安全只是相对的，无非是你要花多大的代价去做这件事，当代价，成本足够高的时候，你自然就放弃了，既然 op 觉得前端加密毫无意义，你可以试试去破解抖音的前端加密逻辑，是不是如你所说的按下 F12 就可以搞定。 |
|
73
LeeReamond 149 天前
@zephyru 感觉除非搞前端加密，否则直接调到封装那里，我感觉所谓的成本也就是看五分钟代码的成本。。。至于前端加密，那更是神秘领域了。。
|
 |
74
GeruzoniAnsasu 148 天前
@bigbigeggs
1. 不要只考虑 CRUD ，多线程是软件架构中最最基础的特性之一，你只是目前没机会写到单机高性能非 HTTP 并发服务而已。 2. 重放是个应用层行为，TLS 传输层从抽象原理上就解决不了，就像地基稳不稳影响不了房子盖得丑不丑。拿 HTTPS 出来讲说明你没理解安全风险出在哪里。 3. 防重放不是在防中间人。是在防非法请求。 我合法用户自己把客户端的请求抓包下来，拿重放器短时高并发重放，有没有可能破坏业务系统的公平性或可靠性？我现在还是不是一个合法用户？ 4. 为什么「放重放的 token 规则」 与 MD5(timestamp+参数) 等价？ 生成唯一凭证仅有你说的这一种可能性吗？ 5. 实现幂等性是不是要考虑防重放？ 我怀疑你把防重放和防抖防重发混淆了 |
 |
75
yc8332 148 天前
redis 锁用 string ，get/set 能防住？这个水平到生产环境不会被搞死吗？
|
|
76
lyxxxh2 148 天前
@bigbigeggs
多线程 sync lock 我真用到。 https://imgur.com/uftrwPY sync,是说 async 吧, 基本都是 js,后端比较少。pip install asyncio 至于 lock,做接口幂需要啊。 https://learnku.com/docs/laravel/7.x/cache/7482#8a1c7c 再普遍点,db 锁不也是锁。 我用没问题,要是问八股文,我估计会 gg 。 |
 |
77
yxd19 148 天前
@x2420390517 虽然但是，密钥
|
 |
78
lizhisty 148 天前
你这认知太挫了，能防住 90%的普通人就行
|
 |
79
restkhz 148 天前
@bigbigeggs 其实我觉得你说的是很有趣的。不知道为什么现在人们戾气这么重。
这是很好的思考，这种质疑，是搞信息安全的素养。但是很明显基础知识不够。 然后结论说的比较武断了，防止重放是必要的。但是你说的这种方法的确不是好方法，你对它的质疑是正确的。 一般对抗重放都会引入随机和一次性。引入 Nonce 和速率限制可能是更有意义的做法。而不是用大家都知道的内容比如时间戳之类的 hash 得到 token 。 如果有 HTTPS 也不用特别担心中间人搞重放了。 话说你面试被问这个问题...你准备的这个答案可能就不好... |
 |
80
pkoukk 148 天前
所有问题都是 成本-收益 的取舍问题
没有绝对的安全，我想入侵你的系统，可以找黑鬼杀手绑架你，你说你系统还安全么？ 防重放措施虽然简陋，但手段也简单啊，成本也低啊，能防住同样简陋的人就行 提高别人搞事的成本就行 要不现在为什么这么多网站套一层 CF ？能彻底反爬么？能彻底防搞事么？ 不能，但能大幅提高你搞事的成本就行了 |
 |
81
uiosun 148 天前
> sync ，lock ，多线程等，工作中根本用不到
什么薪资、什么业务，怎么会连这些都不用……现在连 PHP 都考虑做单核并行化了，到底是什么水准很迷惑。 那不叫重试，那叫幂等性……给我看尴尬了。 |
|
82
uiosun 148 天前
@bigbigeggs #70
我看到你 70 楼的话了。怎么说呢，to C 业务 QPS 5~30k 起，并行化、分布式锁、链路熔断等，都会用到的。 譬如你要处理 50G 甚至更多的一份数据，流、ETL 或 Excel 等方式进来，你就需要并行化和锁来保证你的数据可靠性——同时提升效率。 只能说，多去大公司体验一下吧，QPS/数量级稍微高一些，很多问题都是需要你说的“用不到”的工具来更高效、可靠的解决。 |
 |
83
momo2789 148 天前 via iPhone
看了半天，也没看懂防重放的要点。
|
 |
84
9c04C5dO01Sw5DNL 148 天前
脱裤子只会被爆菊
|
 |
85
johnhuangemc2 148 天前
防重放在 99.9%的情况下都没有价值, 但遇到那 0.1%的情况轻些要花掉一个下午的时间梳理恢复数据, 重些年终奖就泡汤了
|
 |
86
FengMubai 148 天前
@bigbigeggs #69 客户端生成一对公私钥, 用私钥签名
|
|
87
cnevil 148 天前
@bigbigeggs 我做安全的不是专业开发本不想跟你扯这么多，既然你回我了，那就跟你友好探讨一下，首先我认为 token 应该是服务端生成告诉客户端的，客户端怎么会知道你是用什么参数生成的呢？客户端只需要请求的时候带上即可。即攻击者获得了 url ，例如 del?id=1&token=xxx ，攻击者不知道这个用户现在有效的 token ，这个请求到服务器经过校验是无效的啊，为什么不能防止重放呢？
其次，讨论的重点是重放，什么场景会有重放？重放有可能是想针对客户的攻击，例如我把嗅探到的其他用户转账的请求包重放；也可能是针对服务端的攻击，例如我把点赞重放来刷票，甚至也可能是用户觉得页面有点卡他又刷新了一下，你总不能说我在付款页面刷新一下你又扣了一遍款吧？重放不需要考虑你是怎么生成的，我只管把数据包重新发送就行，构造恶意的请求那是另一个范畴了。你可能把重放和 csrf 两个东西搞混了？ 反而我认为你还被其他人误导了，中间人和重放不是完全划等号的，逻辑应该是存在中间人攻击的话会出现在重放这个问题，因为我可以获取到你的数据包，但重放也不只在中间人攻击中存在，所以 token 防止不了 mitm ，只能用来解决重放。你想想我都能获取到你往来的请求了，你下一个 token 我也知道是什么，我完全可以构造一个请求带上服务端给你返回的有效 token 。但是我重放你请求的包是没用的，使用 https 才是可以解决 mitm 的方案，之一，https 也并不完全安全，尤其是支持一些老版本的 tls 。 所以我才说你连 token 都没搞明白，因为我从你的描述中感觉你只知道 token 应该怎么生成，但你不知道怎么用，也不知道为什么要用 |
 |
88
wushenlun 148 天前 via Android
如果所有人时间都是准的那么完全没问题
|
 |
89
ForkNMB 148 天前
@bigbigeggs
(1)业务幂等，这后端应该做的，没啥好讨论的 (2)保证请求参数合法，需要验证签名，确保参数是客户端发出的，客户端可以使用临时的密钥对，用私钥签名，请求的时候带上公钥，服务端验证签名。(用什么固定的 token 或者商量的盐值算 md5 什么的，都不太严谨，至于具体选择的算法不在此讨论 (3)防重放，这个防的是中间人攻击，一般做法请求参数里面有时间戳和 nonce 正常的项目，业务要关心的就是(1) 因为前人肯定搞定了(2)和(3)，这种通用的流程一次做好封装好就可以了的 |
 |
90
009694 148 天前 via iPhone
openai 做防重放了吗？
|
 |
91
l4ever 148 天前
> 放重放生成一个 token ，这个 token 人人都知道如何生成的，比如 timestap+参数 用 md5 进行加密，攻击者也可以完全模拟这个 token 的生成规则，来绕过服务端
？？？有点意思，你说的是知道 jwt token 吗？ 还是你自己选一些参数经过组合再 md5 加密，带着这个结果提交？你认为这就是 token ？ |
 |
92
harryWebb 147 天前
你太年轻了。。。。你根本不知道大部分的攻击者都是半桶水，只要稍微做一下防重放，他的破解成本就会几何倍上升，你要知道很多脚本 boy 都是没有阅读源码的能力的，你作为一个开发者，肯定会觉得破解很简单，这是处于你了解并且知晓的情况下，实际上破解人处于黑盒状态，完全不知道为什么请求会被拦截，造成信息紊乱，大大提高了破解的难度，就好像我之前为了防止别人功能，即使把公钥放前端代码里面加密，依然能挡住 99.999%的攻击，剩下 0.0001%的人，是真大神，也没必要防了
|
 |
93
zltningx 147 天前
CSRF Token 不是最基本的吗
|
Select Language