有没有什么思路可以防止伪造请求

[whatisnew]

为了防止伪造请求，想了各种办法，唉。。。
像服务器端拿到 uuid 之后怎么验证这个 uuid 是正确的呢？
比如有没有一个什么标准数据库可以检查 uuid 是正确的。

或者有别的什么思路可以解决伪造请求的问题。。。像微信这种是怎么做的呢

[whatisnew]

检查ip地址＋token不现实
检查 uuid 其实吧 uuid 也可以伪造

真心头大

[whatisnew]

单独 token 更容易伪造

[whosesmile]

不太理解 单独 token更容易伪造是什么意思？

常见的思路都是form表单提交的时候同时提交token, token生成的机制是这样：
服务器端设置一个任意的字符串作为秘钥，简称为secretkey, 然后将用户的某个不可变信息+secretkey做md5或者sha加密，然后服务器接收到请求的时候，自己算一次，然后匹配这个token是否一致，如果你觉得依然不够安全，就将token在做一个时效性。

前提是你的secretkey一定要足够安全。

[whatisnew]

@whosesmile 问题是客户端的任何信息都不可信

其实可以这么理解：
如何区别一个请求是由机器(工具或者什么软件之类的)发出的，还是正常的用户发出的。


因为我发现机器伪造成正常用户太简单了，而我们好像没有什么好办法去鉴定这个。

[clino]

"如何区别一个请求是由机器(工具或者什么软件之类的)发出的，还是正常的用户发出的。"
这个应该是无法区分的吧...

应该还是要从行为上来区分比较靠谱哈

[whatisnew]

@clino 腾讯这个鬼怎么做的，像微信这种。

[virusdefender]

过年的时候想过这个问题，只能无限的增大难度，基本无解。

[whatisnew]

@whosesmile 就算你通过了这一步验证，你返回回去的 token 认证信息，他拿到之后，再用机器请求这个 token 是一样的效果。。。比如 12306 通过他那个验证码之后，拿到 token 值，就可以任意买票了。

[virusdefender]

最主要原因客户端是可以被反编译和被抓包的。服务器和服务器之间的通信保证安全应该还是比较简单的。

[whatisnew]

@virusdefender 我和你一样，吃饭的时候都在想，最后采用了严格的注册机制比如绑定手机＋身份证人肉认证＋资源限制的方式，去解决的。

[whatisnew]

@virusdefender 是啊。其实我们现在采用的方式稍微安全一些，但是有些机器不停的扫用户密码，验证错误超过5次账号锁定了ip屏蔽了，有正常的用户就来找我们怎么登录不了了。。。我晕死

[whatisnew]

@clino 行为上的话，比如 ios 他打开应用肯定就是直接点登陆按钮啊。那么机器也是一样。。。
如果他已经登录过了，那么就直接鉴权＋获取资源了。问题是鉴权用的 key+token 被机器拿到一样可以获取资源。。。

[kemingcao]

以前也想过，此问题无解 ； ）

[pi1ot]

提高伪造成本，降低伪造收益，HTTP层面杜绝是不可能的。

[whatisnew]

@pi1ot 所以我很好奇像微信、支付宝这种是怎么做的。。。

[clino]

"验证错误超过5次账号锁定了ip屏蔽了"不锁定帐号屏蔽IP而是强制需要验证码? 这样会不会友好些
或者对异常ip限制请求频率

[xenme]

两个人用一台电脑，公用一个账号密码，你怎么区分是一个人还是两个人？
增加注册难度，比如绑手机，帮身份证啥
增加单位时间的限制（一段时间内只能访问多少资源，人的话一般有个限度）
变态点的，每次操作都搞一个验证码，机器不会烦死，人肯定烦死了。

[whatisnew]

@clino 这个本来就有验证码的。错误2次就会出现验证码。再错3次就锁定。24小时候后自动解锁。

[whatisnew]

我分析日志，各国的ip都有，各种ip，一部分还是连号的，不知道我们是不是被什么组织盯上了。
ip 那么容易伪造吗？

[whosesmile]

@whatisnew 我明白你的意思了，但是不太懂你具体要做什么？类比微信、支付宝的某个业务，你可以举个例子么？

[whatisnew]

@xenme 像微信这种你怎么增加单位时间限制。。。只能从实名认证注册入手。
然后，保护登录后的 token＋key 也是很头疼的，他人肉注册一个抓包把 key＋token 拿出来就可以了。

[whatisnew]

@whosesmile 比如在线金融－基金类的业务。当然实名，当然绑手机，但是这还不够。。。

[11]

@whatisnew HTTPS 怎么抓包？难道他们替换了 CA？

[whatisnew]

@11 问题不在 https 那些 token+key 你得存到本地吧。存本地另外再加密也不行。。。

[whosesmile]

@11 楼主的意思貌似是说不是中间人劫持，而是用户故意分析自己的数据，然后去伪造人工行为发送数据，举例就是通过浏览器插件来分析html代码之后，购买火车票的方法是没法避免的。

[whatisnew]

@11 从日志分析情况来看，我怀疑 https 也被破了，不知道他们是怎么做到的。现在只能是有异常的账号先锁定再人肉解决。

[whosesmile]

我自己感觉也是无解，这就是游戏外挂，所有数据都合法，能想到的也是通过用户行为分析了。

[whatisnew]

@whosesmile 两种情况都是避免

[11]

@whosesmile 了解了。。自己理解错了。。

[whatisnew]

特别是 android 机，java 太烂了！反编译也太容易了。。。

[whosesmile]

@whatisnew 微信获取access_token的时效性是2小时，他要求服务器端做分发机缓存这个token，如果不做缓存，每次都访问微信服务器，它是有次数限制的，会拒绝访问的。从这个角度出发，其实你也可以评估一个合理的上限，然后拒绝服务，不过毕竟微信只提供认证，它没有具体业务，因此比较容易，至于其他的新版的SDK也都有上限限制的。

[justfly]

如果你有客户端的话 使用rsa 客户端保存私钥 保证不泄漏 根据整个请求做签名 时间戳参与签名 服务端用公钥校验签名 同时对完全相同的签名拒绝访问 使用https 防止中间人

[whatisnew]

@justfly 客户端任何信息都不可信。 rsa 同样也要保存在客户端。同时认证太慢。不如 key＋token

[knightlhs]

你这个不是解决的思路
如果客户端可以信任 那就加密通信数据
如果客户端不可疑信任那……他怎么样都能拿到一个 token 实在不行我注册一个真用户总可以了吧
其次 你需要判断用户的行为 1秒钟看了10次列表肯定不正常 没完没了的刷列表也不正常
你可以给一个行为特征判断 一旦满足 就封禁一段时间 靠数据加密是不可能的

[cdffh]

http协议本来就是无状态的。所以你让http做这个事情太难了。建议你开一个websocket 定时服务器端下发随机的密钥，然后前端使用密钥来做一些请求。可以一定程度上防止。

[pi1ot]

@whatisnew 支付是有身份信息的。

[RIcter]

沒法防⋯真心的qwq

[mucid]

@whosesmile 没啥用，你比如tornado，只要取出cookie的xrsf照样可以伪造……

[fredcc]

2个部分吧
1、验证客户端的合法性(比如说google的二步验证、短信验证码等等
2、保证合法客户端的会话安全(这里https啊、证书验证啊之类之类咯

[kukat]

服务端和客户端都保存一份token，客户端一定不要明文保存最好混淆一下。
对每次请求签名 signature = md5(URL_PATH+QueryString+Timestamp+token)
请求参数里加上timestamp=xxx&signature=yyy
服务端收到请求检查 timestamp 是否在有效期内
计算签名 signature = md5(URL_PATH+QueryString+Timestamp+token)
判断签名是否匹配

基本能防住包括 repeat attack 在内的恶意请求了

[Ghoul2005]

深层次的话要分析对方的动机和成本，别人为什么要刷你，刷你有什么好处，能否提高对方刷你的成本，当成本高到一定程度时就不值得去刷你了。

直接的话就是验证码，严谨地说是CAPTCHA，验证码只是实现形式之一。

[clino]

@whatisnew "这个本来就有验证码的。错误2次就会出现验证码。再错3次就锁定。24小时候后自动解锁。"
这个只要做到对ip限制尝试次数是不是会更好些,因为真正的用户和攻击者用同一个ip的机会会比较小
而且你的限制太严,3次太少了
比如1天给一个ip 15次帐号出错的机会

[ZavierXu]

https双向证书验证+不要用安卓....