Java业务开发常见错误100例
朱晔
贝壳金服资深架构师
立即订阅
7175 人已学习
课程目录
已完结 45 讲
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个常见错误,你都明白其中缘由了吗?
结课问卷获奖用户名单
答疑篇 (5讲)
答疑篇:代码篇思考题集锦(一)
答疑篇:代码篇思考题集锦(二)
答疑篇:代码篇思考题集锦(三)
答疑篇:设计篇思考题答案合集
答疑篇:安全篇思考题答案合集
Java业务开发常见错误100例
15
15
1.0x
00:00/00:00
登录|注册

27 | 数据源头:任何客户端的东西都不可信任

朱晔 2020-05-19
你好,我是朱晔。
从今天开始,我要和你讨论几个有关安全的话题。首先声明,我不是安全专家,但我发现有这么一个问题,那就是许多做业务开发的同学往往一点点安全意识都没有。如果有些公司没有安全部门或专家的话,安全问题就会非常严重。
如果只是用一些所谓的渗透服务浅层次地做一下扫描和渗透,而不在代码和逻辑层面做进一步分析的话,能够发现的安全问题非常有限。要做好安全,还是要靠一线程序员和产品经理点点滴滴的意识。
所以接下来的几篇文章,我会从业务开发的角度,和你说说我们应该最应该具备的安全意识。
对于 HTTP 请求,我们要在脑子里有一个根深蒂固的概念,那就是任何客户端传过来的数据都是不能直接信任的。客户端传给服务端的数据只是信息收集,数据需要经过有效性验证、权限验证等后才能使用,并且这些数据只能认为是用户操作的意图,不能直接代表数据当前的状态。
举一个简单的例子,我们打游戏的时候,客户端发给服务端的只是用户的操作,比如移动了多少位置,由服务端根据用户当前的状态来设置新的位置再返回给客户端。为了防止作弊,不可能由客户端直接告诉服务端用户当前的位置。
因此,客户端发给服务端的指令,代表的只是操作指令,并不能直接决定用户的状态,对于状态改变的计算在服务端。而网络不好时,我们往往会遇到走了 10 步又被服务端拉回来的现象,就是因为有指令丢失,客户端使用服务端计算的实际位置修正了客户端玩家的位置。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Java业务开发常见错误100例》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 看不到de颜色
    不太理解老师说到的”真实的网站 + 钓鱼的 redirectUrl“是什么样的情况。为什么在真实的网站中会有黑客的钓鱼连接呢?

    作者回复: 在把匿名用户重定向到登录页面的时候,我们一般会带上redirectUrl,这样用户登录后可以快速返回之前的页面。黑客可能会伪造一个链接,替换了其中的redirectUrl为钓鱼网站,那么用户登录后就会直接不知不觉来到钓鱼网站。

    有几种解决做法可以参考:
    第一种,固定重定向的目标URL。
    第二种,可采用编号方式指定重定向的目标URL,也就是重定向的目标URL只能是在我们的白名单内的。
    第三种,合理充分的校验校验跳转的目标地址,非己方地址时告知用户跳转风险,小心钓鱼网站的威胁。

    2020-06-27
    2
  • Darren
    第一个问题:统一登陆获取x-toekn(jwt) 统一鉴权(解析x-toekn),前端请求过网关,网关处理x-toekn,根据x-toekn解析用户ID,用户名等,存放到header中,同时也保留x-toekn,后面的微服务直接获取即可。全局base包,里面定义header中的userid,username,x-toekn等信息,这样既是该服务调用别的服务,别的服务也涉及x-toekn也是可以的。

    第二个问题不知道。

    另外老师给Demon.Lee童鞋写错了 应该是jwt java web token 不是jtw

    作者回复: 嗯是jwt 笔误

    2020-05-19
    2
    2
  • ddosyang
    第一个订单例子的right方法,第六行是不是应该改为if (!order.getItemPrice().equals(item.getItemPrice()))? 因为是想判断不等于的情况,所以这里是不是漏了一个叹号?

    作者回复: 是的,我改一下

    2020-05-24
    1
  • 汝林外史
    1. 就是用面试中经常问的单点登录实现。说白了就是把token专门放在一个地方存着,再给客户端个凭证,等客户端需要校验是否登录的时候就用这个凭证去存token的服务器校验下,通过了就直接登录,不通过就跳转到登录页。
    2. 可以校验下redirectUrl吧
    2020-05-20
    1
  • Demon.Lee
    1. 未想到特别方便的方法,很快就能打通
    2. 查询资料,一般对redirectUrl进行域名校验,并先跳转到一个统一的页面,并提示用户会离开当前网站,类似的“知乎”,“简书”都是这么设计的。

    作者回复: 1、可以使用JWT Token进行打通,或走SSO体系

    2、抛砖引玉:

    1)、固定重定向的目标URL;
    2)、可采用编号方式指定重定向的目标URL;
    3)、合理充分的校验校验跳转的目标地址,非己方地址时告知用户跳转风险;

    2020-05-19
    1
    1
  • 梦倚栏杆
    1.是统一登录
    2.老师介绍的这些是说端上的内容不可信,那后层服务呢?假如我问有一个统一的网关,可以确认用户登录,那么我们应该相信网关吗?如果相信,是不是强依赖网关了,网关有问题,服务就有问题。但是如果不相信,网关就起不到作用了

    作者回复: 如果网关做了正确的身份认证那么可以相信,一般把用户Token转换为用户ID的这个工作就是由网关来做的,网关后面的微服务无需再处理身份认证的工作

    2020-05-19
  • 那时刻
    讨论题,谈谈我的不成熟想法。
    1.不同系统用户标示,可以采用设备ID。或者采用统一的登陆系统来标示用户。
    2.开放重定向问题,首先,不能采用传来的url作为redirect的base url。其次,redirect url写全包含host。不知还有没有其它防御手段?
    2020-05-19
  • fly12580
    还可以对请求参数进行加密,在服务端进行解析判断。加强安全性。
    2020-05-19
    1
收起评论
8
返回
顶部