这是一个创建于 3507 天前的主题，其中的信息可能已经有所发展或是发生改变。
为了防止伪造请求，想了各种办法，唉。。。
像服务器端拿到 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  1
http协议本来就是无状态的。所以你让http做这个事情太难了。建议你开一个websocket 定时服务器端下发随机的密钥，然后前端使用密钥来做一些请求。可以一定程度上防止。
|
 |
37
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 1
服务端和客户端都保存一份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 1
深层次的话要分析对方的动机和成本，别人为什么要刷你，刷你有什么好处，能否提高对方刷你的成本，当成本高到一定程度时就不值得去刷你了。
直接的话就是验证码，严谨地说是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双向证书验证+不要用安卓....
|
Select Language