接口防重放 是不是存粹的脱了裤子放屁？

[bigbigeggs]

防重放解决的是攻击者拿到 url 和参数之后，不断地请求服务端。

1. 服务端针对下单，支付，转账这种操作肯定有幂等，肯定不能胡来乱来

2. 放重放生成一个 token ，这个 token 人人都知道如何生成的，比如 timestap+参数 用 md5 进行加密，攻击者也可以完全模拟这个 token 的生成规则，来绕过服务端

3. 像 https ，客户端私钥加签服务端公验证，都是解决过程中的安全，放重放解决“客户端”的安全，感觉完全没必要，反而增加了成本

上周面试被问到，感觉存粹为了面试而面试，包括 sync ，lock ，多线程等，工作中根本用不到，完全不问业务上的问题，上来就啪啪的八股文走起。

为了面试由此写了一篇接口放重放的文章，欢迎大家指正，真感觉多次一举，为了面试而面试。

我真不相信，哪一家，真的在项目中写了防重放的实现逻辑。

[binux]

最近做了一个买票刷票软件，虽然它对请求加密了，但是就是因为没有防重放，连解密都省了

[purrgil]

不防重放的话，抓包，下载个 curl 然后复制 http 请求到.bat 里循环执行，就直接刷得飞起了。

[weijancc]

我之前爬过许多大网站的接口, 防重放可以说是基操了.

[macaodoll]

一看就是没接触过电商抢购功能。

[yxzblue]

攻击者也可以完全模拟这个 token 的生成规则，来绕过服务端

攻击者怎么会知道服务端的生成规则？

[skuuhui]

在移动端刚兴起的年代，大部分防重放是为了解决弱网环境下重试导致的无效请求的问题。现在技术成熟了，确实失去了百分之 99 情况下的用处了。现在还执着追求这个的，要么历史原因，要么过于迂腐了。对于大部分程序员来说，模仿很容易，动脑真的很难

[crackidz]

重放不是指 TCP 流重放，是指 HTTP 的接口重放，不在同一层。
即便通过 token 防止重放，也不应该单纯使用三方都知道的信息生成，至少应该包含攻击方不知道的信息

[x2420390517]

你要不先看看你有多少错别字？
2.token 的生成，是一种对原信息的签名操作，因为只有服务器有秘钥，所以你不可以伪造
3.https 客户端什么时候能用私钥签？服务器用公钥验，你要不要看看你说的什么？

[darkengine]

想得挺美，我是不会点那个链接 /狗头

[InkStone]

1. 防重放的 nonce 可以服务端生成下发。
2. 仅客户端也可以做防重放的，加固了解一下。别说什么加固也可以破，现实是就是有很多加固现在还好好运行在那里没被破。

[wqhui]

https 保证的是传输过程安全，但你怎么保证发起请求的人是可信的
请求的 token 一般会混入一些像私钥一样的东西，要生成先得盗私钥

多线程之类的不算八股文，日常偶尔就用，除非问你底层 JVM 怎么实现 sync 跟 lock ，19 年的账号居然没用过多线程。。

[geligaoli]

接口的重放攻击，基本是必然遇到的。做过的项目，只要用户量一大，无论是否公开，必然在日志里面会记录到重放攻击。处理实际也好办，幂等或 hash 过滤。

[FawkesV]

sync ，lock ，多线程 这不是很常用的吗??

[dhb233]

一个很现实的问题，支付接口是幂等的，QPS 能支持多大？防重放能支持多大 QPS ？

[jqknono]

认清自己

[cnevil]

"放重放生成一个 token ，这个 token 人人都知道如何生成的，比如 timestap+参数 用 md5 进行加密，攻击者也可以完全模拟这个 token 的生成规则，来绕过服务端"
我怀疑你连 token 都没搞明白

[blankmiss]

包括 sync ，lock ，多线程等，工作中根本用不到 ， 你们是什么公司 还是说你菜的一匹

[salmon5]

https://news.ycombinator.com/item?id=35703789
https://www.163.com/dy/article/I3LRUBS3051189P5.html
防重放是基操，客户端的请求直接被 bing.com 拿走。

[salmon5]

你以为客户端 HTTPS 安全，客户端的浏览器可不老实。

[zhwguest]

接口上 timestamp + nonce ，nonce 在 now + timer 时间范围内缓存，非常简单基础的方案，自己把问题想岔了吧？