问题
这个问题是我公司的一个小业务问题，问题来源于我们发送请求的时候，请求路径上携带的是明文，比如http://xxx/xxx/id=12345，那么别有用心的人就可能会推测出id的生成策略，导致遍历id，自增id的方式来获取我们服务的数据，这是很危险的，所以我的mentor就叫我想一个解决方法。
比如如下的方式就有可能推测出id的生成策略，导致被攻击，我们需要解决的就是这种问题
思路
在解决问题之前，需要先考虑几个因素，先列出我们可能想到的解决方式以及这种方式的问题：
首先就是对id进行加密解密，也就是我们在前端和后端代码处都保存一份密钥，然后使用这一份密钥对id进行加解密，我们后端查出数据进行密钥加密之后再把数据（加密后的数据）返回给前端，然后前端再次使用密钥去解密这个密文。看上去好像可以，不是明文传输了，比如返回的路径可能如下：
但是这样子做仍然有问题，这个问题就在于，前端的代码是共享的可见的，也就是我们的密钥以及解密方法都是直接存储在浏览器并且可以使用F12去查看和修改的，那么得到了密钥之后进行解密然后再递推出ID依旧是可行的，所以这种方式不可以，这也是最开始我想到的方法。
解决
上面说到了，这种解决方式的问题就在于，你的密钥是存储再前端的，那么如果我们有一种办法可以让前端不存储密钥，但是也可以加密解密，那么就能解决这个问题了。文章来源：https://www.toymoban.com/news/detail-527356.html
我的思路是，我们的后端代码从数据库取出ID之后，使用后端代码存储的密钥进行加密，后端代码不开源，所以其他人是拿不到密钥的，那么加密方式只有我们开发者才能知道，然后我们将明文ID和加密好的密文一起传输给前端，前端使用明文进行展示，虽然HTTP请求中依旧可以看到明文和密文，但是如果不法分子想要发送一个对应的请求，他同时也需要同时传输一个明文和密文，由于他不知道密钥，也就无法对明文加密得到密文，它传输过来的密文即使存在，是正确的，但是由于密文是错误的，所以它的查询是失败的，他依旧是不知道我们具体的数据，也就一定程度上保证的数据的安全。文章来源地址https://www.toymoban.com/news/detail-527356.html
到了这里，关于【Java项目】解决请求路径上明文ID传输导致可能被攻击的方法的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
