84669 person learning
152542 person learning
20005 person learning
5487 person learning
7821 person learning
359900 person learning
3350 person learning
180660 person learning
48569 person learning
18603 person learning
40936 person learning
1549 person learning
1183 person learning
32909 person learning
现在要做这样一个判断，用户下载了某个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认证方式不错
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
移动app可以考虑自签名ssl证书。ssl pinning保证请求安全。除非反编译源码，否则几乎为0的可能性伪造请求。
update：
看到这问题又被顶上来了，忍不住更新一下回答。
首先，把问题细分化看。
假设情景1 - App请求内容为公共内容（例如：新闻列表、文章列表、发布评论(假设评论不需要登录)）：
如上的回答，自签名SSL（所谓的自签名目的是节省那一年几十或几百、几千块的证书费用）即可。
假设情景2 - App请求内容为私有内容（比如网银、内部客户端等需要用户登录）：
1.登录，获取用户唯一证书（每次登陆都生成新的证书，覆盖已有证书）
2.App端请求携带该用户唯一证书请求
这个问题可以进一步升级为:http的请求,如何不被拦截并伪造.
因为 web 是不安全的, 所以很难做到请求会被拦截. 因此, 我们假设请求一定会被拦截.
所以也带来一个问题: 如果请求所携带的参数一直不变, 那么肯定请求就很容易被伪造了.
因此, 把思路转向:每次请求所携带的参数都不一样.
很容易就能想到公钥私钥的解决方案. 使用公钥对某一参数进行加密, 然后到服务端进行解密.
同时, 为了让这一参数随时变化, 很明显一个比较简单的参数就是时间了.
在对时间进行加密后, 服务端就可以解密出来, 得到时间. 然后时间进行验证.
考虑到时间会有误差, 所以服务端可以加一个误差值.
这个方案的漏洞是: 如果 app 被破解了, 公钥和参数可以获取了之后, 就可以认为伪造加密后的数据, 进行请求.
没有绝对的安全, 只是把破解的难度加大而已.
想要传输的安全就用https
请求参数可以参考软件序列号的机制，比如通过某种算法把mac地址和时间戳加密，然后把mac地址和加密后的mac地址、时间戳一同传过来服务器校验
http没有很好的防破解方法 只有加强破解的难度
digest认证方式不错