Java业务开发常见错误100例
朱晔
贝壳金服资深架构师
立即订阅
6699 人已学习
课程目录
已完结 40 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 业务代码真的会有这么多坑？
免费
代码篇 (20讲)
01 | 使用了并发工具类库，线程安全就高枕无忧了吗？
02 | 代码加锁：不要让“锁”事成为烦心事
03 | 线程池：业务代码最常用也最容易犯错的组件
04 | 连接池：别让连接池帮了倒忙
05 | HTTP调用：你考虑到超时、重试、并发了吗？
06 | 20%的业务代码的Spring声明式事务，可能都没处理正确
07 | 数据库索引：索引并不是万能药
08 | 判等问题：程序里如何确定你就是你？
09 | 数值计算：注意精度、舍入和溢出问题
10 | 集合类：坑满地的List列表操作
11 | 空值处理：分不清楚的null和恼人的空指针
12 | 异常处理：别让自己在出问题的时候变为瞎子
13 | 日志：日志记录真没你想象的那么简单
14 | 文件IO：实现高效正确的文件读写并非易事
15 | 序列化：一来一回你还是原来的你吗？
16 | 用好Java 8的日期时间类，少踩一些“老三样”的坑
17 | 别以为“自动挡”就不可能出现OOM
18 | 当反射、注解和泛型遇到OOP时，会有哪些坑？
19 | Spring框架：IoC和AOP是扩展的核心
20 | Spring框架：框架帮我们做了很多工作也带来了复杂度
设计篇 (6讲)
21 | 代码重复：搞定代码重复的三个绝招
22 | 接口设计：系统间对话的语言，一定要统一
23 | 缓存设计：缓存可以锦上添花也可以落井下石
24 | 业务代码写完，就意味着生产就绪了？
25 | 异步处理好用，但非常容易用错
26 | 数据存储：NoSQL与RDBMS如何取长补短、相辅相成？
安全篇 (4讲)
27 | 数据源头：任何客户端的东西都不可信任
28 | 安全兜底：涉及钱时，必须考虑防刷、限量和防重
29 | 数据和代码：数据就是数据，代码就是代码
30 | 如何正确保存和传输敏感数据？
不定期加餐 (6讲)
加餐1 | 带你吃透课程中Java 8的那些重要知识点（一）
加餐2 | 带你吃透课程中Java 8的那些重要知识点（二）
加餐3 | 定位应用问题，排错套路很重要
加餐4 | 分析定位Java问题，一定要用好这些工具（一）
加餐5 | 分析定位Java问题，一定要用好这些工具（二）
加餐6 | 这15年来，我是如何在工作中学习技术和英语的？
结束语 (3讲)
结束语 | 写代码时，如何才能尽量避免踩坑？
结课测试 | 关于Java业务开发的100个常见错误，你都明白其中缘由了吗？
结课问卷获奖用户名单
30 | 如何正确保存和传输敏感数据？
朱晔 2020-05-26
你好，我是朱晔。
今天，我们从安全角度来聊聊用户名、密码、身份证等敏感信息，应该怎么保存和传输。同时，你还可以进一步复习加密算法中的散列、对称加密和非对称加密算法，以及 HTTPS 等相关知识。
应该怎样保存用户密码？
最敏感的数据恐怕就是用户的密码了。黑客一旦窃取了用户密码，或许就可以登录进用户的账号，消耗其资产、发布不良信息等；更可怕的是，有些用户至始至终都是使用一套密码，密码一旦泄露，就可以被黑客用来登录全网。
为了防止密码泄露，最重要的原则是不要保存用户密码。你可能会觉得很好笑，不保存用户密码，之后用户登录的时候怎么验证？其实，我指的是不保存原始密码，这样即使拖库也不会泄露用户密码。
我经常会听到大家说，不要明文保存用户密码，应该把密码通过 MD5 加密后保存。这的确是一个正确的方向，但这个说法并不准确。
首先，MD5 其实不是真正的加密算法。所谓加密算法，是可以使用密钥把明文加密为密文，随后还可以使用密钥解密出明文，是双向的。
而 MD5 是散列、哈希算法或者摘要算法。不管多长的数据，使用 MD5 运算后得到的都是固定长度的摘要信息或指纹信息，无法再解密为原始数据。所以，MD5 是单向的。最重要的是，仅仅使用 MD5 对密码进行摘要，并不安全。
确认放弃笔记？
放弃后所记笔记将不保留。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Java业务开发常见错误100例》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(11)
那时刻1.关于日志脱敏，可以在日志处理模块里通过正则表达式对于敏感词比如username匹配后，做模糊字符输出到日志里。
2.https双向认证指的是服务器额外校验客户端证书，方便控制某个接口是否允许客户端访问，用于第三方服务调用。流程上多了客户端提交自己证书和服务器校验证书等步骤。
小伙伴们讨论的云平台使用的secretid和secrestkey。云平台更推荐使用临时的IAM来替代吧。作者回复: 嗯，对于logback可以直接实现一个MessageConverter来做脱敏，脱敏的方式可以是屏蔽敏感信息的几位，或者是对敏感信息进行加密输出。
2020-05-26 3
大胖子呀、老师说不能直接对密码进行md5加密，那我心想可以加盐，老师又说盐不要写死，我又想可以用用户名作为盐，接着老师就又说不建议用用户名做盐，应该uuid生成，我就想那保存到数据库不也可以被黑客获取到吗？最后老师又说：有的同学可能又要问了……
可恶啊，这些都在你的计算当中啊！作者回复: 哈哈
2020-05-26 3
旅途老师 密码使用对称加密或非对称加密不行吗 使用自己的算法进行加密 别人也破解不了作者回复: 不行 源码也泄露了呢
2020-05-26 3
握了个大蚂蚱规模巨大的隐私数据尤其公司搞国际化的业务，应该都会有一个全局的点来管理隐私数据，业务流转的时候都不需要流转明文，相当于拿个令牌流转，到需要置换，显示时，再去兑换，根据需要兑换不同等级的明文（匿名值，完整明文）。
hash的盐我们是初始化一个map里面放10000个盐，然后把字符串的char转为int再对10000取模得到这个字符串对应的盐。这样好处是盐具有复杂性而又保证hash算法的根本：相同铭文hash后得到相同hash，缺点是用在密码上的话可能会被看出相同密码的数据，需要再加一层处理2020-06-05 1
Joker关于彩虹表的解释在这里：https://www.zhihu.com/question/19790488，简单想象成一个黑盒吧，你传进加密后的密码，就能得到解密后的密码。但是构造这黑盒的过程就比较麻烦了。但是如果密文都是根据一个字符串根据特定的规则得到的字符串，哪怕是根据用户信息来构造一个盐，那么就有很大的概率出现，构造了一个彩虹表就把整个数据库的密码给解密了的情况。构造彩虹表的过程虽然麻烦，却是一劳永逸的，那么就要想一个不那么一劳永逸的方法，所以就出现了每次都用一个随机盐的方式。
因为如果是固定的盐的话，那么黑客得到一套数据库之后，只要构造一套彩虹表就能得到结果了。如果每次的盐都不同，那么黑客就要每次都根据密文和盐构造一套彩虹表。
我就是这么理解的，不知道是否正确。密码学真的难。作者回复: 差不多
2020-05-28 1
Jeff.Smile记得一次面试，别人问我https的原理，其实我是理解的，但是记不住这个过程，怎么办？😂作者回复: 自己画一遍流程图
2020-05-27 1
👽敏感数据的话，其实还有一个：
就是第三方的一些验证数据。类似于阿里云的Id和key。
我未进行加密保存在配置文件中，并且还将其上传在了GitHub上，按理说，如果Github泄露了，任何人都可以调用我的资源了。因为是透支额度设置的很低，而且余额只有10￥，所以未作安全处理。因为最坏的结果，也就是把我余额全用完。
1，如果需要涉及到加密，我会考虑到分开存储：
可能ID存数据库，Key存本地文件。（鸡蛋分在多个篮子里存放，脱库或者服务器被黑，也只有一部分数据泄露，依然无法使用我的服务）
2，然后加密存放，因为调用服务需要读取，所以必须是可逆的加密算法。增加破译的成本。
3，定期监控，出问题及时发现。作者回复: 大家也可以继续探讨一下 SecretID和SecretKey应该怎么保存
2020-05-26 1 1- 👽我的理解，没有绝对的安全。现有的一切加密安全措施，其实只是增加破解的难度罢了。真正的安全，还是需要验证码之类的动态验证。
我一直以来，理解的加密就分两种：可逆的，不可逆的。
可逆的：规定了一种规律，只要应用这种规律就可以逆推其原始值。我认为其实雪花算法就是可逆的加密算法。知道其运算规律，也可以逆推其创建时间。虽然明文中无法体现其创建时间。
不可逆的：自己的密码是12，加密后是3，已知了算法是所有数位之和，但是并无逆推出原始数值是111，003，03，102......等。
但是，无论可逆还是不可逆，破解也是寻找其规律罢了。加密其实本质也是，对结果附加运算过程。
原始密码 x+a-b*c?d = 密文x1，在足够多的数据样本的时候，我觉得还是可以逆推出原始数据。（解方程嘛。。。）
我觉得，现在的密码加密，维持个三五年之后，也会被轻易破解。
其实要是简单粗暴一点，就手机验证码登录，就已经基本OK了，大平台似乎也都是这么做的。类似于某里云。在一些不太重要的数据，就处理的可以适当放开一些。作者回复: 其实深度学习就是通过大量样本寻找y=f(x)中的函数f，我们想一下，是否有可能通过深度学习来解密/获得密钥呢？
2020-05-26 1 1 
kacaric请问老师接口能否采用https双向认证保证接口安全，还需要在接口中额外增加签名字段吗？作者回复: https确保防止伪造篡改中间人窃取
双向https虽然限制了客户端，但是粒度还是很粗
如果我们还是防止调用方随意调用接口，那么还是需要在业务层进行业务加密和签名2020-06-13- 阿冲请问老师脱敏后的数据如何做SQL查询，这个条件怎么处理。比如身份证号和姓名字段？
作者回复: 脱敏（是指遮掩部分数据）后的数据只能呈现了，加密后的数据要做查询的话，2个办法：
1、加密后查询
2、数据库存一个哈希值，查询的话哈希后查询，需要展示的时候再解密2020-06-10 - Geek老师好，保护用户二要素AAD在实际会用在哪些场景中，是否用户忘记了自己设置的AAD就没办法类似于重置密码的方式找回AAD了，也就没办法再解密信息？
作者回复: 不是找回密码的场景，所谓找回密码是重置密码，这里演示的是保护需要用户授权才能获取的重要信息
2020-05-31
收起评论