1
min 2013-11-21 10:32:57 +08:00
服务器端怎么知道那些请求是来自盗用者的呢?
|
2
kstsca 2013-11-21 10:42:07 +08:00
矛与盾 基本无解
|
3
nocoo 2013-11-21 10:43:19 +08:00 1
|
4
akira 2013-11-21 10:51:50 +08:00 2
访问接口的时候,带上用户信息,例如用户id,udid之类的。
用户id不合法的禁止调用。 然后给每个用户设定个阀值就行了。 ps: 任何只依赖app本地代码的功能,都是可逆可破的。时间差别而已 |
5
Livid MOD 如果一开始就设计成 https 的,那么别人就更难看到 URL 了。
|
6
sun391 2013-11-21 10:57:09 +08:00 1
所有请求多加个验证信息 比如说是 userid+timestamp 对称加密
密钥写在c里 不过这也只是增加了破解难度而已,索性就在规则上限制,一个userid只能调用X次/天,user创建时+验证码、邮箱验证(总之不能让他全自动注册) |
7
wxstorm 2013-11-21 11:00:04 +08:00 1
https只能保证网络上数据被截获了是破解不了的。
但是如果客户端被破解,https有啥用。。。 |
8
adow OP |
9
binux 2013-11-21 11:13:26 +08:00 1
假如你的app是一个黑盒,黑盒的输入是用户操作,中间有个过程是将用户操作编码加密发送出去。
我都拿到你的app了,再不济,难道不能把用户操作去掉,直接黑盒使用编码加密功能吗? |
10
adow OP @binux 是啊,我也这么想,即使我用c封装成静态库,你反编译后看的也许麻烦点,不过我要是直接用这个库进行编码岂不是更容易了,越想越绕了,难不成真的无解么。
对了,我看到别人说,反向obj-c的工程貌似要难点么,而反向Android的java代码却似乎比较容易读。我们的Android项目是外包给另一个公司做的,我们想让他混淆一下java的代码,他们说项目涉及的模块还有第三方包太多,没法做混淆了,所以我才想到用c写一个,然后给iOS/Android用。 |
11
wxstorm 2013-11-21 11:20:16 +08:00
我觉得比较现实点的做法是 限制每个http接口在同一个客户端上的访问次数,比如同IP一天只能访问多少次,超过了要么就禁掉,要么弹个图片验证码让输入。
走加密之类的,只要你的密钥存在一个可以发现的地方,都是可破解的~~ |
12
humiaozuzu 2013-11-21 11:21:06 +08:00 1
@Livid 加一个证书中间人攻击一样拿API数据
|
13
icyalala 2013-11-21 11:21:29 +08:00 1
假设。。Android版本你已经在编译出了C的链接库,然后用Java调用。。
那黑客直也可以直接用.so文件来调用接口啊。。。 就是说,这些实际上都是用户的行为,只要黑客有心,你是很难区分出来的。。 你只能在服务端验证参数是否合法、用户行为是否正常、调用频率是否OK.做好监控足够了。 |
14
binux 2013-11-21 11:22:46 +08:00
@humiaozuzu 比如ingress就是这么被破解的
|
15
humiaozuzu 2013-11-21 11:29:49 +08:00
@binux 最近一直在分析各种 API 玩,Protobuf/HTTPS 都是很容易分析的
同步推的 API 加密没找到方法 |
16
jimrok 2013-11-21 11:37:50 +08:00 4
给你的建议,设备要注册,将device的token上送到服务器去。服务器给每个token下发唯一标识的令牌。如果同一个设备同时在多个ip同时访问,果断封掉这个token。
|
17
tabris17 2013-11-21 11:44:00 +08:00
每个设备或者客户端都需要唯一标识,每次请求都要发送这些标识,只要封掉那些异常请求的标识就行了。比如单位时间发送过多请求
|
18
darasion 2013-11-21 11:44:26 +08:00 2
我觉的可以这样:
1. 升级 app,升级接口,旧接口保留 2. 旧接口一直保留,但使用假冒的数据,做的像真的一些。 如果没有人注意你升级了接口,那利用你接口的人就懒得更新它的东西了。 |
19
Sfan 2013-11-21 11:45:51 +08:00 1
用c来写这个签名方法,包括密钥等,然后编译成静态库,iOS/android中来使用这个静态库;
我觉得还是这个可靠... |
20
sunwenjun 2013-11-21 11:47:33 +08:00 1
@humiaozuzu , 没有服务器的证书 https也能破解?
|
21
adow OP |
22
jimrok 2013-11-21 12:02:00 +08:00
@adow 这个是避免不了的,还是要验证这个device的合法性,例如为这个设备推送一个token.但总能找到办法获取这些信息。根本还是要限制api的请求次数。例如同一个api,客户端1分钟内不能超过100次请求。这样盗用就没有什么价值了,换个思路,如果有人盗用你的接口,是件很美好的事情,你应该开放你的接口,使用oauth注册,让调用者很爽,这样他就离不开你了。如果换了我还求之不得让人调用,害怕我的文档写的不够好,别人不会调用。
|
23
favormm 2013-11-21 12:12:50 +08:00 1
这个应没有办法,因为你的接口来本就是给你客户端用的。 无论如何在你的客户端都会还原为原始数据。hack最终是可以在app内存中拿到这些原始数据与你所有的数据流操作方法。然后反汇编为高级代码,并模拟一个客户端与你服务器通信。
|
24
zhujinliang 2013-11-21 12:18:17 +08:00 1
改成websocket的
|
25
txlty 2013-11-21 12:22:14 +08:00 1
这个问题,无解。你花多长时间限制,盗用者花多长时间破解。
限制设备的话,盗用者可以凭空虚拟出无数个设备。 封IP的话。。移动的出口IP并不多。都是单个IP配大量设备。 |
26
txlty 2013-11-21 12:34:58 +08:00
很好奇,盗用者是怎么个请求频率?
是用单台服务器发请求?还是做自己的客户端 在N台手机发请求? 这个盗用请求频率,和正常用户盯着手机看的请求频率,有什么区别? 如果大于正常用户请求,那盗用者图的啥? 如果和正常用户请求频率差不多。那从你的角度看,盗用者就是个合法客户端。 |
27
yangqi 2013-11-21 12:43:36 +08:00 1
把手机想象成普通的客户端就行了, 你服务器总要登录然后开session, 和普通网站验证类似
|
28
adow OP |
30
arron 2013-11-21 13:15:14 +08:00 1
要想完全防止,的加一个难识别的验证码,这样用户就不愿意了。
不然就真没辙的,android太好解了。只能限制下访问频率和IP,让人家采集得不那么舒服。 如果你的数据量很大。限制下频率和ip,即使人家用2000个ip去采集,一秒种采集一次,一年都采集不完的话,人家自然木有兴趣了... |
31
arron 2013-11-21 13:15:51 +08:00
然后就是找到采集你的人或公司, 告他去...
|
32
dorentus 2013-11-21 13:46:04 +08:00 1
法律问题就通过法律方式解决呗。
当然你可以故意提供一些钓鱼数据来证明对方确实是在未经授权使用你们的接口。 |
33
chundong 2013-11-21 13:51:16 +08:00 1
@adow 如果是用device token 的请求次数来判断是否是盗用的话,建议不要封掉它,返回一些假数据回去,貌似美丽说就是这么做的,讲ANTI-SPA的那段,但是跟你的情况不太一样,他们是想封掉推广链接,http://www.infoq.com/cn/presentations/Beautiful-architecture-development-change
|
34
wupher 2013-11-21 14:22:34 +08:00 1
使用非对称加密如何?
用户在注册时生成一对密钥,公钥提交,私钥存于本地钥匙链。 每次关键请求以私钥签名,服务器公钥验证。 发现该客户请求异常,予以锁定,要求用户改密或其它方式来更改密钥。 比直接用sha1,AES,3DES这类,应该会好点。 愿意的话,就再挂https也行。 |
35
lvye 2013-11-21 14:38:48 +08:00 1
破解与否在于成本,ios再难越狱,还是会有人会去破解。
你只能多设点限制,防住一部分人,让他的成本不断加大。 |
36
victor 2013-11-21 15:13:38 +08:00 1
|
37
adow OP 我现在想只让他的破解成本高一点
* 使用https的话,他通过伪造一个证书来解码数据有多麻烦; * 如果我为每个设备生成私钥,然后通过https传递,本机保存在iOS的keychains里,要想把他提取出来的话难度高不高,还有Android下面有没有类似的安全保存数据的方案啊; |
38
orzfly 2013-11-21 15:29:24 +08:00 1
@adow 拆 HTTPS 的其实很简单,例如 http://fiddler2.com/ 这种东西就行,几秒的事情。
|
39
tabris17 2013-11-21 15:32:16 +08:00 1
增加破解成本最好的办法就是采用私有通信协议
|
40
cxh116 2013-11-21 16:03:25 +08:00 1
@tabris17 提到的方法不错,不一定要私有协议,用http协议也可以,只是返回的数据加密. 密钥里应该包含设备token和时间等字段,生成密钥和解密最好都是用c写,这样难道应该会大很多.
|
41
missdeer 2013-11-21 16:03:49 +08:00 1
https是挡不住api分析的,现在好些工具都自带一个证书装到设备上再把设备代理指向工具开的端口就行了,比如上面XD说的fiddler2,mitmproxy等等
|
42
missdeer 2013-11-21 16:06:27 +08:00 1
另外,比较怀疑用C写代码能增加复杂度的说法,在Android上用NDK写的代码最后也是跑在dalvik上,反编译这个字节码相对机器码来讲还是容易的多吧
|
43
tabris17 2013-11-21 16:26:01 +08:00
多线程+私有协议能大大增加破解复杂度
|
44
jimrok 2013-11-21 16:30:03 +08:00 1
@victor 这个简单,你只需要一台redis就可以高速记录下来。每分钟产生一个hash表,存放每个token的调用次数。一旦某个计数超出了阈值你就执行你的策略就好了。
|
46
adow OP |
47
adow OP 看了大家的建议,我这样来做的话如何:
* 修改一下签名的方法使得不那么大众(现在是和OAuth里的签名方法一样的); * 每次App启动时到服务器上去获取密钥,密钥不保证在文件里,每次都启动都不一样,鉴于即使用https访问来获取密钥也能被看出来,我们想要不要直接写一个基于tcp/ip的通信的程序,用来创建和传递密钥,而传输的数据是一种自定义格式的,也可以再次加密解密什么的。不过我们都没写过这样的程序,感觉好像挺复杂的样子啊,真的要做到这样的地步么,我还真纠结; |
48
wwqgtxx 2013-11-21 21:52:03 +08:00 via Android 1
弄一个私有的协议,好好混淆一下,用c封装,apk校验不通过就不允许调用,在外侧调用jni就行了
|
50
VYSE 2013-11-21 22:41:48 +08:00 via Android 1
https协议,java客户端都是直接看通讯协议的节奏。
再防也顶多像腾讯一样搞得cracker烦到家,还是能搞出东西来。 直接封盗用ip和找律师吧 |
51
gluttony 2013-11-21 23:12:00 +08:00 1
@adow 用现成的SSL就行,客户端验证证书的正确性以防止中间人嗅探,app里存的证书要混淆一下。 http://www.inmite.eu/en/blog/20120314-how-to-validate-ssl-certificates-iOS-client
|
52
sprhawk 2013-11-22 13:51:20 +08:00 1
没有绝对的安全,我们先分析楼主的需求,楼主这个不用登录就可以使用的信息真的很重要,不能让别人访问吗?根据安全的等级,来确定要使用的策略吧
不管让app发什么,我们都很难确保app的身份,嵌在app内的信息及算法,无法100%保证不被别人获取到,所以只能提高对方拿到这个关键信息的门槛了。 |
53
gamexg 2013-11-29 21:07:09 +08:00 1
和对抗外挂类似,看过类似的文章。
不知道你的实际情况,比较好的办法是做一些小的标志来识别是否盗用的接口,发现是非法用户的话也不要立即报错,而是延时+随机的返回错误的数据。 小的标记可以是: 你的程序会按特定的顺序使用负载均衡的域名,如果顺序大量异常的就是非法客户端。 看似随机数或时间的参数,但其实和用户id或者其他的参数有一定的关系。 自己的程序每次请求之间的间隔必定在多少秒之间。 故意让服务器接口返回错误,你的程序会收到错误时会不更改序列号直接重发上次的请求。如果请求序列号变了就证明是非法的客户端。 可以找一些类似的东西来做标记,然后可以根据各个标记被触发的情况来锁定非法客户端。 |
54
gamexg 2013-11-29 21:20:31 +08:00
还有其他的小标记,例如你的程序必定会去取广告,或者检查更新,但是如果一个客户端没有检查版本更新就直接使用您的api了就有很大的可能性证明对方是非法客户端。
就是一个观点,从各种不引人注意的地方设套,找出非法客户端。 多弄些类似的标记就会让对方烦死的,不过你做起来也会比较麻烦了。 |
55
yinxingren 2013-12-06 19:00:32 +08:00 1
所有的这些动作只是加大盗用/破解的难度,但貌似也只能这么做了。
昨天crack一个android app时,发现有很多jnl调用,那个作者是写了一个库,编成了.so机器码 逆向了下能看到里面存放着的公钥,就是不去,由于个人能力有线没能搞定这个。 所以这种办法还是可以做的 |
57
woostundy 2017-02-28 15:30:36 +08:00
@humiaozuzu HTTPS 双向验证,中间人证书就没用了。然而 app 被破解怎么都是无解。
|