84669 人が学習中
152542 人が学習中
20005 人が学習中
5487 人が学習中
7821 人が学習中
359900 人が学習中
3350 人が学習中
180660 人が学習中
48569 人が学習中
18603 人が学習中
40936 人が学習中
1549 人が学習中
1183 人が学習中
32909 人が学習中
现在要做这样一个判断,用户下载了某个app(平台不限ios/android)后,在初次启动app时向服务器发起一个http请求,我想判断这个请求是从app发过来的而不是来自其他工具的恶意访问。因为想到http请求中带的参数是可能被截获,所以尽管服务器端通过请求参数的验证和user-agent等的验证,也不能完全确保请求来源的合法性。请教有没有高安全性的解决方案!谢谢!
拥有18年软件开发和IT教学经验。曾任多家上市公司技术总监、架构师、项目经理、高级软件工程师等职务。 网络人气名人讲师,...
移动app可以考虑自签名ssl证书。ssl pinning保证请求安全。除非反编译源码,否则几乎为0的可能性伪造请求。
update:
看到这问题又被顶上来了,忍不住更新一下回答。
首先,把问题细分化看。
假设情景1 - App请求内容为公共内容(例如:新闻列表、文章列表、发布评论(假设评论不需要登录)): 如上的回答,自签名SSL(所谓的自签名目的是节省那一年几十或几百、几千块的证书费用)即可。
假设情景2 - App请求内容为私有内容(比如网银、内部客户端等需要用户登录): 1.登录,获取用户唯一证书(每次登陆都生成新的证书,覆盖已有证书) 2.App端请求携带该用户唯一证书请求
这个问题可以进一步升级为: http的请求,如何不被拦截并伪造.
因为 web 是不安全的, 所以很难做到请求会被拦截. 因此, 我们假设请求一定会被拦截. 所以也带来一个问题: 如果请求所携带的参数一直不变, 那么肯定请求就很容易被伪造了.
因此, 把思路转向: 每次请求所携带的参数都不一样. 很容易就能想到公钥私钥的解决方案. 使用公钥对某一参数进行加密, 然后到服务端进行解密. 同时, 为了让这一参数随时变化, 很明显一个比较简单的参数就是时间了.
在对时间进行加密后, 服务端就可以解密出来, 得到时间. 然后时间进行验证. 考虑到时间会有误差, 所以服务端可以加一个误差值.
这个方案的漏洞是: 如果 app 被破解了, 公钥和参数可以获取了之后, 就可以认为伪造加密后的数据, 进行请求.
没有绝对的安全, 只是把破解的难度加大而已.
想要传输的安全就用https 请求参数可以参考软件序列号的机制,比如通过某种算法把mac地址和时间戳加密,然后把mac地址和加密后的mac地址、时间戳一同传过来服务器校验
http没有很好的防破解方法 只有加强破解的难度 digest认证方式不错
移动app可以考虑自签名ssl证书。ssl pinning保证请求安全。除非反编译源码,否则几乎为0的可能性伪造请求。
update:
看到这问题又被顶上来了,忍不住更新一下回答。
首先,把问题细分化看。
假设情景1 - App请求内容为公共内容(例如:新闻列表、文章列表、发布评论(假设评论不需要登录)):
如上的回答,自签名SSL(所谓的自签名目的是节省那一年几十或几百、几千块的证书费用)即可。
假设情景2 - App请求内容为私有内容(比如网银、内部客户端等需要用户登录):
1.登录,获取用户唯一证书(每次登陆都生成新的证书,覆盖已有证书)
2.App端请求携带该用户唯一证书请求
这个问题可以进一步升级为: http的请求,如何不被拦截并伪造.
因为 web 是不安全的, 所以很难做到请求会被拦截. 因此, 我们假设请求一定会被拦截.
所以也带来一个问题: 如果请求所携带的参数一直不变, 那么肯定请求就很容易被伪造了.
因此, 把思路转向: 每次请求所携带的参数都不一样.
很容易就能想到公钥私钥的解决方案. 使用公钥对某一参数进行加密, 然后到服务端进行解密.
同时, 为了让这一参数随时变化, 很明显一个比较简单的参数就是时间了.
在对时间进行加密后, 服务端就可以解密出来, 得到时间. 然后时间进行验证.
考虑到时间会有误差, 所以服务端可以加一个误差值.
这个方案的漏洞是: 如果 app 被破解了, 公钥和参数可以获取了之后, 就可以认为伪造加密后的数据, 进行请求.
没有绝对的安全, 只是把破解的难度加大而已.
想要传输的安全就用https
请求参数可以参考软件序列号的机制,比如通过某种算法把mac地址和时间戳加密,然后把mac地址和加密后的mac地址、时间戳一同传过来服务器校验
http没有很好的防破解方法 只有加强破解的难度
digest认证方式不错