阿里巴巴Java开发手册第四章-安全规约篇

1.[强制] 隶属于用户个人的页面或者功能必须进行权限控制校验。

说明: 防止没有做水平权限校验就可随意访问、修改、删除别人的数据，比如查看他人的私信内容、修改他人的订单。

老四附言:
有的时候写文章也是一种缘分，在恰当的时机写恰当的内容。老四最近正好在接手前后端分离的相关的项目，其中就涉及到水平权限校验的这种问题。首先什么是水平权限校验呢?和它对应的垂直权限校验又是什么呢?说之前了解两个专业术语词汇:

• RBAC(Role Based Access Control): 基于角色的访问控制。
• ACL(Access Control List): 访问控制列表，包含了对一个对象或一条记录可进行何种操作的权限定义。

水平权限校验:

作用在相同角色但不同数据之间。例如A与B都是高老四博客的用户，对我的网站上的资源拥有相同的权限，但各自有自己不同的个人资料以及评论数据等。所以拿我们经常使用的REST风格项目来讲，如果不做好水平校验，A用户很容易通过改造url中的用户id拿到B用户的信息以及隐私数据等。这是不允许的。再拿之前提到的前后端分离来讲，一个企业级的项目可能动辄就上百个接口了，每个都需要进行权限判断的，否则就是风险。所以我们在开发的时候尤其需要注意这方面的事情，前后端分离中，既要使用例如OAuth登录机制等来验证用户，也要采用类似jwt(JSON WEB Token，基于JSON的、用于在网络上声明某种主张的令牌token)的token机制等来进行鉴权。

垂直权限校验:

垂直权限校验其实就是类似于前面提到的ACL了，这个很多框架都会对应业务来进行集成。例如A是注册用户，B是管理员，不同的角色对应不同的权限列表。说到这里，好像Spring Security好像越来越火了。

2.[强制] 用户敏感数据禁止直接展示，必须对展示数据进行脱敏。

说明: 个人手机号码显示为: 158****9119，隐藏中间4位，防止隐私泄露。

老四附言:
对于脱敏很早就已经成为互联网中的规定了，隐私或者敏感数据的泄露会对客户、公司等造成严重的利益损害，甚至威胁人身安全。常见的需要脱敏的数据: 手机号、邮箱、真实姓名、收货地址、身份证号码等。至于具体的脱敏规则以及脱敏程度需要结合具体的业务场景处理了，也有手机号码脱敏处理成1********9这样婶儿的。除了敏感数据这种掩码脱敏的方式，还有以下几种脱敏方式供你参考。

• 替换: 如统一将女性用户名替换为F，这种方法更像”障眼法”，对内部人员可以完全保持信息完整性，但易破解。
• 重排: 序号12345重排为54321，按照一定的顺序进行打乱，很像”替换”，可以在需要时方便还原信息，但同样易破解。
• 加密: 编号12345加密为23456，安全程度取决于采用哪种加密算法，一般根据实际情况而定。
• 截断: 13811001111截断为138，舍弃必要信息来保证数据的模糊性，是比较常用的脱敏方法，但往往对数据利用上不够友好。
• 掩码: 就像说明里面的示例一样，将完整的手机号变成”158****9119″的墨阳，保留了部分信息，并且保证了信息的长度不变性，对信息持有者更易辨别。
• 日期偏移取整: 20180530 11:11:11 —-> 20180530 11:00:00，舍弃精度来保证原始数据的安全性，一般此种方法可以保护数据的时间分布密度。

3.[强制] 用户输入的SQL参数严格使用参数绑定或者METADATA字段值限定，防止SQL注入，禁止字符串拼接SQL访问数据库。

老四附言:
什么是METADATA字段值限定?METADATA就是元数据的意思。元数据的意思你应该知道的，就是描述数据的数据，比如一首歌曲对于我们说是一个数据，那么歌名、作词作曲就是这首的歌曲的元数据，描述了这首歌曲。

所以孤尽的意思就是用户输入的参数要严格遵守参数绑定或者数据的原生对应，从而对用户的输入的内容进行更好的校验，这样避免sql注入的问题。至于字符串拼接，想必你都这么对付过别人数据库，所以自己注意不要这样写是程序员的基本美德!

4.[强制] 用户请求传入的任何参数必须做有效性验证。

说明: 忽略参数校验可能导致:

• page size过大导致内存溢出
• 恶意order by导致数据库慢查询
• 任意重定向
• SQL注入
• 反序列化注入
• 正则输入源串拒绝服务ReDoS

说明: Java代码用正则来验证客户端的输入，有些正则写法验证普通用户输入没有问题，但是如果攻击人员使用的是特殊构造的字符串来验证，有可能导致死循环的结果。

老四附言:

我们常说防君子不防小人，指的就是上述这类东西。初期在我们编码经验少的时候，基本也就能想到一些基本的校验，以为项目也就没什么大问题了。但是随着经验的积累，关于安全的方面是我们不得不重视的方面。勤写(必须)junit测试，测试各种边界值等是必修课。

简单解释一下正则输入源串拒绝服务ReDoS(regular expression denial of service)这一项，当正则表达式写得不完美的时候，就有可能被恶意输入和利用，从而消耗大量的服务器资源，造成DoS(Denial of Service，拒绝服务)。所以利用正则表达式进行攻击的叫做ReDoS。多了可能老四也讲不明白，第一次听说的可以参考一下维基百科的介绍: ReDoS介绍。

5.[强制] 禁止向HTML页面输出未经安全过滤或未正确转义的用户数据。

老四附言:

拿mvc来讲，就是model中存放的数据一定都是干货，别整一些有的没的，在对象以及一些零落的数据等一定进行安全扫描以及字符串的转义等，别你给页面传输一个字符串直接把页面整崩溃了~~~~还有就是，把你的互联网注册用户名统一使用”null”这个字符串，你总能发现bug，相信老四。

6.[强制] 表单、AJAX提交必须执行CSRF安全过滤。

说明: CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在CSRF漏洞的应用/网站，攻击者可以事先构造好URL，只要受害者用户一访问，后台便在用户不知情情况下对数据库中用户参数进行相应修改。

老四附言:

引用《图解http》的内容再来相对详尽的说明一下这个csrf攻击。之前在搞前后端分离的时候老四也是碰到了这个问题。另外这里安利一下图解系列的书。推荐《图解HTTP》、《图解TCP/IP》、《图解网络硬件》三本，该系列是由几个牛逼的日本友人写的，很符合书名的定义，书中配图丰富，很容易理解各种逻辑概念，丰富的图表、详实的参数汇总、逼真的实物照，甚或带有卡通色彩的趣味图示，图文并茂，不但讲解了网络通信的关键知识体系，还阐述了关于不断更新换代、功能繁多的网络硬件设备的配置、使用管理等相关知识。今年的618老四就会支持一波。已经放入了购物车。我知道，有很多人看到这里肯定想要免费的电子版，还是那句话，有能力尽量去买纸质书，我依然会在文末给你提供pdf电子版，但是这是为了理解那些真正没有多少钱买书却又真心想学习的人的。

闲言少叙，说一下这个CSRF攻击。跨站点请求伪造(Cross-Site Request Forgeries，CSRF)攻击是指攻击者通过设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或设定信息等某些状态更新，属于被动攻击。

跨站点请求伪造有可能会造成以下等影响:

• 利用已通过认证的用户权限更新设定信息等
• 利用已通过认证的用户权限购买商品
• 利用已通过认证的用户权限在留言板上发表言论

案例:

下面以留言板功能为例，讲解跨站点请求伪造。该功能只允许已认证并登录的用户在留言板上发表内容。

在该留言板系统上，受害者用户A是已认证状态。它的浏览器中的 Cookie 持有已认证的会话ID。

攻击者设置好一旦用户访问，即会发送在留言板上发表非主观行为产生的评论的请求的陷阱。用户A的浏览器执行完陷阱中的请求后，留言板上也就会留下那条评论。

触发陷阱之际，如果用户A尚未通过认证，则无法利用用户A的身份权限在留言板上发表内容。

7.[强制] 在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重放限制，如数量限制、疲劳度控制、验证码校验，避免被滥刷导致资损。

说明: 如注册时发送验证码到手机，如果没有限制次数和频率，那么可以利用此功能骚扰到其它用户，并造成短信平台资源浪费。

老四附言:

你知道嘛，盛行一时(包括现在)的短信、电话轰炸机其实就是调用了各个网站、公司平台的电话或者短信接口对目标手机号码进行轰炸的，包括老四偶尔随手抓一个借贷平台的短信接口报复一下一些坑过老四的恶人，至于为什么是借贷平台?你懂的~~~话说回来，除了骚扰用户的考虑，这里面也涉及到成本问题等，所以关于防重放机制，除了成熟的第三方，如果自己接手，一定要好好设计一番，注意各方面的漏洞情况。

8.[推荐] 发贴、评论、发送即时消息等用户生成内容的场景必须实现防刷、文本内容违禁词过滤等风控策略。

老四附言:

这个就不用说了，看看人家百度贴吧，多爱国。另外推荐一下这个视频，了解一下和谐的关键词机制的演变进程-《如何科学地消灭敏感内容》

文末《图解HTTP》、《图解TCP/IP》、《图解网络硬件》下载自助获取。

更博不易，如果觉得文章对你有帮助并且有能力的老铁烦请赞助盒烟钱，点我去赞助。抱拳。