共计 670 个字符，预计需要花费 2 分钟才能阅读完成。
原文地址:【BUG】url 参数 AES 加密和解密问题
欢送拜访我的博客: http://blog.duhbb.com/
引言
bug 复盘, 让你少写 bug!
明天剖析的是一个 url 参数加密解密的问题, 起因毁坏了加密后的字符串导致解密失败.
参数的加密解密
状况形容
url 有个参数是地址, 比方 http://www.hello.com/, 申请这个 url 的时候试图把最初的正斜杠给 trim 掉.
当初有个平安问题须要将这个地址参数给加密, 而加密后的字符串尾部可能呈现 /.
所以解决这个问题的时候肯定要留神:
- 加密之前能够 trim
- 加密之后的字符串不能再 trim 了, 否则加密的后果不残缺
同理
- 解密之前的字符串是不能 trim 的
- 解密之后的字符串能够 trim 的
为什么始终没有暴露出这个问题呢?
起因是, 加密的盐值是用了日期, 导致 / 的呈现是个概率问题, 摸不准那天就触发了这个雷了.
问题起因
如上, 就是因为解密的时候没有判断是否启用了加密, 而先去 trim 而后在解密, 会导致如果加密字符串尾部有 /, 最初解密的加密字符串是不对的.
正斜杠 / 须要本义吗?
Chrome + SpringBoot 测试
?a=/sdfsdf/sdfsf&b=/ 这种组合的话在 Spring 中是能够获取到带 / 的 a 和 b 的值的.
用 %2F 或者 %2f 的话也能够获取 / 参数, emmmmm.
算了, 不编码了 / 也能对付用, 所以是 chrome 帮忙咱们编码了吗?
wget + SpringBoot 测试
wget http://192.168.213.161:8088/xxx/main.htm?a=/adsf/asdfsf/asdfasdf/ 也能收到正斜杠 /.
正文完