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