阿里巴巴Java开发手册———个人追加的见解和补充

Posted 2020-09-01

前言

手册在（一）中有原版下载，在（三）中有在线版本，建议对照手册食用。

在本文发布的时候前几天好像阿里做出了修改，在（一）中的地址下载的版本为1.0.2可能对一些之前的改动和修改。

本文依旧还是针对1.0.0的版本写的，不过出入应该不大。

有关编程规范（一）http://www.cnblogs.com/linkstar/p/6413402.html

有关异常日志（二）http://www.cnblogs.com/linkstar/p/6415788.html

有关数据库的（三）http://www.cnblogs.com/linkstar/p/6429770.html

有关项目工程（四）http://www.cnblogs.com/linkstar/p/6439871.html

该说的我觉得（一）里面我都说完了，那么就直接进入正题吧。

 

安全规约

说道安全，其实有很多地方都是需要注意的，可能你一开始写代码的时候，可能几乎不管安全问题。但是等到项目上线之后，有的可能会出现问题，有的可能不会。因为有的时候你的项目根本就没有人想要黑你，都是正常的用户，所以不会出现问题。但是一旦等项目做大了，用户多了，渐渐的，就有人想要用非正常的手段来获取利益，渐渐的所有的安全问题就会暴露出来。说实在话，项目被黑的还算少数，主要是服务器被黑的可能性高，经常会有人想要攻击你的服务。下面我就手册里面给出的总结几条进行分析补充。

 

权限控制

对于普通用户来说。需要限制用户的权限，让他不能看见他不应该看见的东西。

对于后台管理人员来说，常常使用的是RBAC，也就是基于角色去控制用户的访问权限。

权限的控制是十分必要的，它可以屏蔽掉很多不应该出现的非法操作，没有权限，你就不应该让他操作。

 

用户数据保护

对于用户的数据一定要进行保护，因为对于用户来说，其实把手机，姓名等给了平台，平台就有义务进行保护，不能让用户的隐私被泄露。这是对用户起码的尊重，如果用户因为平台的信息暴露而导致被骚扰，或者是利益上面的损失，那么是不可挽回的。而且，对于用户的密码等重要信息越加是。

 

sql注入

现在已经少了，虽然说这是一种常见的攻击方式，但是现在很多框架都已经帮我们很好的杜绝了这样的攻击，常见的如mybatis和hibernate，这样的框架在某种程度上面执行的sql已经不会存在sql注入的风险，至少我是没有遇到过了，不过也不排除有一些漏洞。所以sql注入这点还是能有保障的。#和$这里我就不多说了，手册在之前的sql规范中已经提到了。

 

用户输入的参数判断

对于用户的参数判断，有两个地方需要注意，第一个是页面上面的判断，使用js等对于用户输入的信息合法性进行判断，第二个是后台的判断，也就是java代码中的判断。很多人说，我后台判断不就好了吗？下面说说理由，首先如果只有前台判断肯定是不行的，对于哪怕是低级码农来说，绕过你的js简直轻而易举，js只能对于普通正常使用的用户进行判断；再者，有人说只进行后台判断，这样也不可以，如果所有的参数都进行了后台逻辑的判断，那么对于普通用户也是如此，那么服务器的压力可想而知有多大，举个简单的例子，用户名对不对，昵称对不对，密码对不对，等等一系列都给服务器，而且每个用户都一样，那么服务器也恼火了。大多数时候，用户还是正常使用的，js的判断能减少很多服务器的访问压力，最后可能到达服务器的时候，只需要一遍注册就通过了，而不需要访问三四次。

 

XSS

接着上面的说，如果对于用户输入的数据不进行很好的检测和过滤的话，就会让XSS攻击有可乘之机，关于XSS网上有很多原理的讲解，我这边也不多说，简单的说对于XSS我们只要对所有用户输入的数据进行过滤，把会出现问题的符号等进行检测，就可以防止这样的攻击，具体代码和防御方式请参考网上给很出的，我自己是利用xssfilter实现的。

 

页面的输出

在页面的输出时候，很多人会直接使用EL表达式去输出，但是这其实是很危险的，有些时候恶意用户会钻漏洞让你的页面上面输出一些奇怪的钓鱼链接，或是奇怪的html代码。所以我推荐是使用JSTL <c:out>标签去输出，这样即使输出的是html代码也不会被浏览器所解释运行，能避免一些麻烦。

 

限制访问方式

很多时候get访问方式需要被限制，不然会导致很多问题，如浏览器地址栏暴露信息，或者第三方get请求攻击等等，如果你使用的是springMVC，那么请一定要配置好你的method=RequestMethod.POST，对于不同的请求请进行访问方式的约束和限制。

 

CSRF

这是一种常见的攻击方式，但是可能对于一些新手来说，不会去注意，因为在他们眼中世界还是很美好的，所以脑子里面还没有安全这个概念。这个漏洞也就存在于很多的中小型网站中，而且用户是访问一些别的网站而导致你的网站出现问题，所以这种攻击隐蔽性很高，一般很难被察觉。具体CSRF攻击的方式以及原理，网上都有很多，如何防御也有，我这里也就不班门弄斧了，主要就是提醒一些同学需要注意一下这个问题，通常建议是加入随机token来防御这样的攻击。

 

重复提交

这个问题也是普遍存在的，有些是用户无意造成的，可能因为网速慢，一下子没加载出来，用户就疯狂的点击，而造成重复的递交多次请求。还有一些就是故意造成的，用户利用bug不停调用，导致你的短信接口疯狂调用，导致你的服务器资源不停的被访问占用，导致服务器最后宕机。所以对于重复提交来说必须进行严格的限制，特别还有一些ajax的请求也是一样的，需要进行限制。普遍采用的也是加入token，然后服务端进行验证的方式，虽然有点笨，但是严格可行。也许还有别的更好的方式，我也只能说，教练，我也想学。

 

关键词过滤

如果你玩过游戏，肯定知道，很多时候，你在游戏频道说话的时候，如果出现脏话，都会被变成***。这个在网站上面很多平台都没有注意。对于这些有违反规定的发言，都需要进行严格的审核，因为如果有关部门发现在你这个平台上面发现有什么政治言论啊。。。等等，你这个平台就等着被查水表咯。所以这点也是需要提醒大家的。如果发布的是全平台可见的消息，最好需要后台审核才能上线，如果是对话性质，最好进行关键词过滤，以防不测啊。

 

检测软件

现在对于一些已知的漏洞，很多检测软件已经能很好的检测出网站可能存在的漏洞了，很多时候可以利用这些软件去检测你写好的网站是否存在问题，当然这样的软件很多，这边我使用的是IBM Security AppScan，这个软件我使用的很多，检测出现的问题很详细，而且会给出一些普遍的解决方案，也比较容易使用和上手。

 

大致我遇到的安全上面的问题总结就是这些，手册上面也基本都给出了，有的我也进行了补充。因为我完成的网站其实访问量也并非大到被各种攻击，所以安全上面遇到的问题经验也不是很多，基本上也就这些了。其实安全这块的话，讲真，有的时候被攻击了就能涨经验了。。。