
为了防止伪造请求,想了各种办法,唉。。。
像服务器端拿到 uuid 之后怎么验证这个 uuid 是正确的呢?
比如有没有一个什么标准数据库可以检查 uuid 是正确的。
或者有别的什么思路可以解决伪造请求的问题。。。像微信这种是怎么做的呢
1 whatisnew OP 检查ip地址+token不现实 检查 uuid 其实吧 uuid 也可以伪造 真心头大 |
2 whatisnew OP 单独 token 更容易伪造 |
3 whosesmile 2015-04-17 15:42:56 +08:00 不太理解 单独 token更容易伪造是什么意思? 常见的思路都是form表单提交的时候同时提交token, token生成的机制是这样: 服务器端设置一个任意的字符串作为秘钥,简称为secretkey, 然后将用户的某个不可变信息+secretkey做md5或者sha加密,然后服务器接收到请求的时候,自己算一次,然后匹配这个token是否一致,如果你觉得依然不够安全,就将token在做一个时效性。 前提是你的secretkey一定要足够安全。 |
4 whatisnew OP @whosesmile 问题是客户端的任何信息都不可信 其实可以这么理解: 如何区别一个请求是由机器(工具或者什么软件之类的)发出的,还是正常的用户发出的。 因为我发现机器伪造成正常用户太简单了,而我们好像没有什么好办法去鉴定这个。 |
5 clino 2015-04-17 16:00:25 +08:00 "如何区别一个请求是由机器(工具或者什么软件之类的)发出的,还是正常的用户发出的。" 这个应该是无法区分的吧... 应该还是要从行为上来区分比较靠谱哈 |
7 virusdefender 2015-04-17 16:06:28 +08:00 过年的时候想过这个问题,只能无限的增大难度,基本无解。 |
8 whatisnew OP @whosesmile 就算你通过了这一步验证,你返回回去的 token 认证信息,他拿到之后,再用机器请求这个 token 是一样的效果。。。比如 12306 通过他那个验证码之后,拿到 token 值,就可以任意买票了。 |
9 virusdefender 2015-04-17 16:07:32 +08:00 最主要原因客户端是可以被反编译和被抓包的。服务器和服务器之间的通信保证安全应该还是比较简单的。 |
10 whatisnew OP @virusdefender 我和你一样,吃饭的时候都在想,最后采用了严格的注册机制比如绑定手机+身份证人肉认证+资源限制的方式,去解决的。 |
11 whatisnew OP @virusdefender 是啊。其实我们现在采用的方式稍微安全一些,但是有些机器不停的扫用户密码,验证错误超过5次账号锁定了ip屏蔽了,有正常的用户就来找我们怎么登录不了了。。。我晕死 |
12 whatisnew OP @clino 行为上的话,比如 ios 他打开应用肯定就是直接点登陆按钮啊。那么机器也是一样。。。 如果他已经登录过了,那么就直接鉴权+获取资源了。问题是鉴权用的 key+token 被机器拿到一样可以获取资源。。。 |
13 kemingcao 2015-04-17 16:25:49 +08:00 以前也想过,此问题无解 ; ) |
14 pi1ot 2015-04-17 16:31:57 +08:00 提高伪造成本,降低伪造收益,HTTP层面杜绝是不可能的。 |
16 clino 2015-04-17 16:41:01 +08:00 "验证错误超过5次账号锁定了ip屏蔽了"不锁定帐号屏蔽IP而是强制需要验证码? 这样会不会友好些 或者对异常ip限制请求频率 |
17 xenme 2015-04-17 16:44:39 +08:00 两个人用一台电脑,公用一个账号密码,你怎么区分是一个人还是两个人? 增加注册难度,比如绑手机,帮身份证啥 增加单位时间的限制(一段时间内只能访问多少资源,人的话一般有个限度) 变态点的,每次操作都搞一个验证码,机器不会烦死,人肯定烦死了。 |
19 whatisnew OP 我分析日志,各国的ip都有,各种ip,一部分还是连号的,不知道我们是不是被什么组织盯上了。 ip 那么容易伪造吗? |
20 whosesmile 2015-04-17 16:49:42 +08:00 @whatisnew 我明白你的意思了,但是不太懂你具体要做什么?类比微信、支付宝的某个业务,你可以举个例子么? |
21 whatisnew OP @xenme 像微信这种你怎么增加单位时间限制。。。只能从实名认证注册入手。 然后,保护登录后的 token+key 也是很头疼的,他人肉注册一个抓包把 key+token 拿出来就可以了。 |
22 whatisnew OP @whosesmile 比如在线金融-基金类的业务。当然实名,当然绑手机,但是这还不够。。。 |
25 whosesmile 2015-04-17 16:58:31 +08:00 @11 楼主的意思貌似是说不是中间人劫持,而是用户故意分析自己的数据,然后去伪造人工行为发送数据,举例就是通过浏览器插件来分析html代码之后,购买火车票的方法是没法避免的。 |
26 whatisnew OP @11 从日志分析情况来看,我怀疑 https 也被破了,不知道他们是怎么做到的。现在只能是有异常的账号先锁定再人肉解决。 |
27 whosesmile 2015-04-17 17:01:17 +08:00 我自己感觉也是无解,这就是游戏外挂,所有数据都合法,能想到的也是通过用户行为分析了。 |
28 whatisnew OP @whosesmile 两种情况都是避免 |
29 11 2015-04-17 17:05:27 +08:00 @whosesmile 了解了。。自己理解错了。。 |
30 whatisnew OP 特别是 android 机,java 太烂了!反编译也太容易了。。。 |
31 whosesmile 2015-04-17 17:06:46 +08:00 @whatisnew 微信获取access_token的时效性是2小时,他要求服务器端做分发机缓存这个token,如果不做缓存,每次都访问微信服务器,它是有次数限制的,会拒绝访问的。从这个角度出发,其实你也可以评估一个合理的上限,然后拒绝服务,不过毕竟微信只提供认证,它没有具体业务,因此比较容易,至于其他的新版的SDK也都有上限限制的。 |
32 justfly 2015-04-17 17:10:10 +08:00 如果你有客户端的话 使用rsa 客户端保存私钥 保证不泄漏 根据整个请求做签名 时间戳参与签名 服务端用公钥校验签名 同时对完全相同的签名拒绝访问 使用https 防止中间人 |
34 knightlhs 2015-04-17 17:32:51 +08:00 你这个不是解决的思路 如果客户端可以信任 那就加密通信数据 如果客户端不可疑信任那……他怎么样都能拿到一个 token 实在不行我注册一个真用户总可以了吧 其次 你需要判断用户的行为 1秒钟看了10次列表肯定不正常 没完没了的刷列表也不正常 你可以给一个行为特征判断 一旦满足 就封禁一段时间 靠数据加密是不可能的 |
35 cdffh 2015-04-17 18:14:15 +08:00 http协议本来就是无状态的。所以你让http做这个事情太难了。建议你开一个websocket 定时服务器端下发随机的密钥,然后前端使用密钥来做一些请求。可以一定程度上防止。 |
37 div class="sep3"> RIcter 2015-04-17 19:38:26 +08:00 via iPhone 法防真心的qwq |
38 mucid 2015-04-17 22:31:04 +08:00 @whosesmile 没啥用,你比如tornado,只要取出cookie的xrsf照样可以伪造…… |
39 fredcc 2015-04-17 23:25:01 +08:00 2个部分吧 1、验证客户端的合法性(比如说google的二步验证、短信验证码等等 2、保证合法客户端的会话安全(这里https啊、证书验证啊之类之类咯 |
40 kukat 2015-04-18 00:11:31 +08:00 服务端和客户端都保存一份token,客户端一定不要明文保存最好混淆一下。 对每次请求签名 signature = md5(URL_PATH+QueryString+Timestamp+token) 请求参数里加上timestamp=xxx&signature=yyy 服务端收到请求检查 timestamp 是否在有效期内 计算签名 signature = md5(URL_PATH+QueryString+Timestamp+token) 判断签名是否匹配 基本能防住包括 repeat attack 在内的恶意请求了 |
41 Ghoul2005 2015-04-18 02:09:04 +08:00 深层次的话要分析对方的动机和成本,别人为什么要刷你,刷你有什么好处,能否提高对方刷你的成本,当成本高到一定程度时就不值得去刷你了。 直接的话就是验证码,严谨地说是CAPTCHA,验证码只是实现形式之一。 |
42 clino 2015-04-18 08:09:06 +08:00 @whatisnew "这个本来就有验证码的。错误2次就会出现验证码。再错3次就锁定。24小时候后自动解锁。" 这个只要做到对ip限制尝试次数是不是会更好些,因为真正的用户和攻击者用同一个ip的机会会比较小 而且你的限制太严,3次太少了 比如1天给一个ip 15次帐号出错的机会 |
43 ZavierXu 2015-04-18 15:16:06 +08:00 https双向证书验证+不要用安卓.... |