Java 业务开发常见错误 100 例
朱晔
贝壳金服资深架构师
52944 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 48 讲
代码篇 (23讲)
Java 业务开发常见错误 100 例
15
15
1.0x
00:00/00:00
登录|注册

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

商品总价
商品数量
商品价格
商品ID
信任HTTP请求中客户端传给服务端的信息导致的安全问题
预防开放重定向问题
打通不同系统的用户标识
HandlerMethodArgumentResolver
自定义注解@LoginRequired
用户登录后在Session中设置当前用户的标识
使用了客户端传给服务端的用户ID
IP地址或请求头信息只能用作参考
X-Forwarded-For请求头
判断用户的唯一性
使用Spring Validation进行参数校验
对参数进行校验
服务端支持的国家列表
误以为客户端的数据来源是服务端
重新计算商品总价
重新设置商品单价
重新查询商品
订单信息Order
思考与讨论
用户标识不能从客户端获取
不能信任请求头里的任何内容
客户端提交的参数需要校验
客户端的计算不可信
数据源头:任何客户端的东西都不可信任

该思维导图由 AI 生成,仅供参考

你好,我是朱晔。
从今天开始,我要和你讨论几个有关安全的话题。首先声明,我不是安全专家,但我发现有这么一个问题,那就是许多做业务开发的同学往往一点点安全意识都没有。如果有些公司没有安全部门或专家的话,安全问题就会非常严重。
如果只是用一些所谓的渗透服务浅层次地做一下扫描和渗透,而不在代码和逻辑层面做进一步分析的话,能够发现的安全问题非常有限。要做好安全,还是要靠一线程序员和产品经理点点滴滴的意识。
所以接下来的几篇文章,我会从业务开发的角度,和你说说我们应该最应该具备的安全意识。
对于 HTTP 请求,我们要在脑子里有一个根深蒂固的概念,那就是任何客户端传过来的数据都是不能直接信任的客户端传给服务端的数据只是信息收集,数据需要经过有效性验证、权限验证等后才能使用,并且这些数据只能认为是用户操作的意图,不能直接代表数据当前的状态。
举一个简单的例子,我们打游戏的时候,客户端发给服务端的只是用户的操作,比如移动了多少位置,由服务端根据用户当前的状态来设置新的位置再返回给客户端。为了防止作弊,不可能由客户端直接告诉服务端用户当前的位置。
因此,客户端发给服务端的指令,代表的只是操作指令,并不能直接决定用户的状态,对于状态改变的计算在服务端。而网络不好时,我们往往会遇到走了 10 步又被服务端拉回来的现象,就是因为有指令丢失,客户端使用服务端计算的实际位置修正了客户端玩家的位置。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

这篇文章强调了在业务开发中需要具备的安全意识,特别是对客户端传来的数据不可信任的重要性。作者通过四个案例详细阐述了这一观点。首先,作者指出客户端的计算不可信,举例说明了在处理电商下单操作时,服务端需要重新计算订单价格,而不是直接信任客户端传来的数据。其次,作者强调了客户端提交的参数需要校验,提出了对客户端提交的参数进行有效性校验的方法。最后,作者还提到了服务端在使用网页隐藏域中的数据时需要小心。总的来说,本文通过具体案例向读者展示了在业务开发中需要注意的安全问题,强调了任何客户端的东西都不可信任的重要性。 文章还讨论了不能信任请求头里的任何内容,以及用户标识不能从客户端获取的问题。作者提出了一些解决方案,如通过登录或三方授权登录来获取用户标识,以及使用自定义注解和参数解析器来确保用户标识的安全性。此外,作者还提到了开放重定向问题,并提出了从代码层面预防开放重定向问题的建议。 总的来说,本文通过具体案例和解决方案向读者展示了在业务开发中需要注意的安全问题,强调了任何客户端的东西都不可信任的重要性,并提出了相应的解决方案。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Java 业务开发常见错误 100 例》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(13)

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

    作者回复: 在把匿名用户重定向到登录页面的时候,我们一般会带上redirectUrl,这样用户登录后可以快速返回之前的页面。黑客可能会伪造一个链接,替换了其中的redirectUrl为钓鱼网站,那么用户登录后就会直接不知不觉来到钓鱼网站。 有几种解决做法可以参考: 第一种,固定重定向的目标URL。 第二种,可采用编号方式指定重定向的目标URL,也就是重定向的目标URL只能是在我们的白名单内的。 第三种,合理充分的校验校验跳转的目标地址,非己方地址时告知用户跳转风险,小心钓鱼网站的威胁。

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

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

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

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

    2020-05-24
    3
  • Demon.Lee
    1. 未想到特别方便的方法,很快就能打通 2. 查询资料,一般对redirectUrl进行域名校验,并先跳转到一个统一的页面,并提示用户会离开当前网站,类似的“知乎”,“简书”都是这么设计的。

    作者回复: 1、可以使用JWT Token进行打通,或走SSO体系 2、抛砖引玉: 1)、固定重定向的目标URL; 2)、可采用编号方式指定重定向的目标URL; 3)、合理充分的校验校验跳转的目标地址,非己方地址时告知用户跳转风险;

    2020-05-19
    3
    3
  • Hex
    一般客户端参数都会进行加密传输到服务端,如果选择安全性高的加密方案,是不是可以解决大部分参数不可信的问题?

    作者回复: 检验还是要做

    2020-11-19
  • 汝林外史
    1. 就是用面试中经常问的单点登录实现。说白了就是把token专门放在一个地方存着,再给客户端个凭证,等客户端需要校验是否登录的时候就用这个凭证去存token的服务器校验下,通过了就直接登录,不通过就跳转到登录页。 2. 可以校验下redirectUrl吧
    2020-05-20
    2
    7
  • 鹏程万里
    第二个demo,如果request里没有设置商品价格非空,用前段传进来的商品价格.equals有可能空指针的,对于业务字段是不是都应该判空后再使用?
    2020-12-25
    1
  • 那时刻
    讨论题,谈谈我的不成熟想法。 1.不同系统用户标示,可以采用设备ID。或者采用统一的登陆系统来标示用户。 2.开放重定向问题,首先,不能采用传来的url作为redirect的base url。其次,redirect url写全包含host。不知还有没有其它防御手段?
    2020-05-19
    1
  • fly12580
    还可以对请求参数进行加密,在服务端进行解析判断。加强安全性。
    2020-05-19
    1
    1
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部