【软件开发规范二】《禁止项开发规范》

一、 应用禁止项 4

二、 数据库禁止项 7

三、 生产环境禁止项 10

一、应用禁止项

1. 【强制】禁止未经过测试的代码发布到生产环境。

说明：测试很重要，因为软件错误可能很昂贵甚至很危险，一个bug越长越不被发现，它就可能带来更大的隐患。此外，如果测试团队错过了准确详尽地捕捉或识别风险和软件问题，会导致一些灾难发生，那么就需要付出昂贵的代价来检测bug，所以软件漏洞或是Bug可能会导致货币和人员的损失。

2. 【强制】禁止无需求、无设计文档的功能上线。

说明：设计文档是产品经理、项目经理、研发人员、销售人员、运营推广人员沟通的一个桥梁，一份好的功能需求设计文档是软件产品是否能成功的关键。有了设计文档，可以保证我们大的方向没有错，设计不当之处可以马上得到纠正，模糊不清的部分也会马上有了思路，大大减少了开发的时间和降低了编码的难度，也提高来团队及公司的工作效率。

3. 【强制】禁止不使用Maven管理Jar。

4. 【强制】禁止在应用系统的业务工作时间段内执行对数据库性能产生影响的批处理。

说明：影响用户的正常使用，用户体验性差，导致系统崩溃，出现预想不到的后果。

5. 【强制】禁止同一个批处理的两个批次执行时间有交叉。

说明：因为容易出现系统数据处理重复而出错。

解决方案：增加任务锁处理，批处理的执行采用轮询的机制。

6. 【强制】禁止批处理、接口或Ftp配置信息写在程序中，禁止在代码中硬代码主机名、IP、用户、密码。

说明：可维护性不强。

规避方案：配置信息写在外部的配置文件中。

7. 【强制】禁止提供后台管理员删除或修改日志的功能。

8. 【强制】禁止应用程序更改应用日志记录。

9. 【强制】禁止应用系统中的用户帐号口令明文存储

说明：存储在数据库的数据面临很多威胁，有应用程序层面、数据库层面的、操作系统层面的、机房层面的、员工层面的，想做到百分百不被黑客窃取，非常困难。如果密码是加密之后再存储，那么即便被拖库，黑客也难以获取用户的明文密码。

10. 【强制】禁止通过使用System.out、System.err进行信息输出到控制台中。

说明：

Ø 此方式输出的信息无法保留：由于在生产环境中控制台是固定的，因此控制台的信息不进行保留；

Ø 此方式将影响系统运行性能：由于无法输出，将影响生产运行效率。

解决方案：

Ø 采用通用的日志框架，对于System.out输入采用：Logger.debug记录。

Ø 对于System.err采用Logger.error进行记录。

11. 禁止在异常处理时仅直接使用Exception.printStackTrace()将异常堆栈直接打印到控制台。

说明：printStackTrace()打印出的堆栈日志跟正常输出或者业务代码执行日志是交错混合在一起的，在并发大日志输出多的情况下，查看异常日志就变更的非常困难。并且直接输出到控制台，堆栈信息太长太多时内存会被填满。

正例：

try {

...

} catch (Exception e1) {

log.error("data报文加密失败！", e1.getMessage());

}finally{

......

}

反例：

try{

...

}catch (Exception e1) {

e1.printStackTrace();

log.error("data报文加密失败！");

}finally{

......

}

12. 【强制】禁止用double或float定义金额类型的变量和进行运算。

说明：由于double/float在表示金额时可能出现小数，对于金融项目中的金额，误差是不能容忍的。

正例：使用BigDecimal控制精度。

13. 【强制】禁止应用程序使用非预编译（PreparedStatement）模式进行数据库操作。

说明：

Ø 直接使用Statement方式，将导致每次SQL执行都需要进行SQL编译；

Ø 拼SQL可能引起SQL注入的安全漏洞。

14. 【强制】禁止应用程序中自行开发或使用非开发框架提供的基于线程的应用。

说明：线程较难控制，用不好将可能导致服务器宕机。

解决方案：使用线程池管理线程。

15. 【强制】禁止从数据库中加载没有数量限制的数据集，对可能大于10万条数据的表必须采用分页模式查询。

说明：对于没有大小限制可能在查询条件不合适出现，一次性查询出上万条数据，可能引起内存溢出错误。在执行任何数据库操作时必须要进行数量限制。

16. 【强制】禁止在应用系统中采用大字符串使用正则表达式运算。

说明：正则表达式太大将影响运行效率。

17. 【强制】文件上传需要限定文件大小和类型，上传后不能使用原文件名保存。

18. 【强制】禁止使用Object.finalize() 。

说明：JVM会在需要时通过GC的垃圾回收线程来进行调用finalize函数，但由于调用时间不确定等我们无法控制的原因，不能可靠地使用finalize（）完成关闭任务，例如作为关闭的I / O流，可能造成资源浪费、泄漏，从而影响性能。

19. 【强制】禁止互联网应用中完整显示客户的隐私数据（如：身份证号，信用卡号）。

20. 【强制】禁止互联网应用在没有图形验证码的情况下使用邮件和短信发送功能。

21. 【强制】输入验证禁止仅仅在用户端进行验证，必须在服务器端进行验证。

说明：用户端的验证往往依赖于浏览器，如果恶意用户的恶意攻击不通过浏览器提交，用户端验证就形同虚设。

22. 【强制】禁止使用不安全的算法进行数据加密，如仅仅使用MD5算法。

说明：MD5散列后的数据，在几分钟内就可被破解。

规避方案：应使用SHA2及以上强度的散列算法。

23. 【强制】禁止使用可逆算法加密用户密码。

24. 【强制】禁止在客户端明文存储客户的联系方式、证件号码等敏感数据（如：永久性cookie，SQLite）。

说明：禁止将密码保存到本地客户端，即便是加密后的密码也不建议保存在本地，攻击者可利用密文格式的密码登录或修改其他账户的密码。

25. 【强制】禁止外网应用采用明文传输敏感数据。

说明：当我们在网站上面提交敏感数据到服务器的过程中未进行相关加密处理，导致攻击者通过中间人攻击方式（劫持、嗅探等）即可获取到这些未加密的敏感数据。当攻击者获取到这些数据之后，就可以用这些信息以合法用户的身份进入到应用系统中——甚至可能进入到应用系统后台中，一旦进入到应用系统中那么就可以获取更多的敏感数据，以及更有机会发现更多的漏洞。

26. 【强制】禁止暴露在公网上的应用接口调用时不经过身份认证和权限控制。

说明：由HTTP协议进行通信的数据大都是未经加密的明文，包括请求参数、返回值、 cookie、 head等等数据，因此，外界通过对通信的监听，轻而易举便可根据请求和响应双方的格式，伪造请求与响应，修改和窃取各种信息。所以我们还需要对每次请求进行认证，来判断发起请求的是不是就是该用户，以及请求信息是否被篡改。

二、数据库禁止项

27. 【强制】禁止出现无数据库设计文档或文档与数据库实际不一致。

说明：

28. 【强制】禁止出现无数据库设计文档或文档与数据库实际不一致。

说明：数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件。无数据库设计文档或文档与数据库实际不一致，会给后期维护增加了很多工作量。

29. 【强制】禁止出现数据库变更不兼容前一个版本程序。

说明：防止出现数据库结构变更直接删除原来使用的列，导致程序无法回退。

30. 【强制】禁止出现关键业务数据操作表的设计中缺少创建时间和最后修改时间字段。

31. 【强制】新开发的应用系统或新模块(oracle数据库平台上的应用) 禁止使用Oracle TEXT在数据库内部做文本检索（效率很低）。

32. 【强制】禁止JDBC查询时传入的变量类型跟表的列定义数据类型不一致。

说明：会出现一些不可预期的bug,查找愿意会耗费很多时间。

33. 【强制】禁止在数据库事务中进行远程系统调用。

说明：远程调用有可能比较慢，会延长事务对数据库锁的时间，增加死锁的概率。

解决方案：采用把远程调用和对数据库的更新操作分开处理，先远程调用再统一更新数据库。

34. 【强制】禁止使用以下字段类型，包括：

1) 过时老类型：RAW，LONG，LONG RAW；

说明：新版Oracle已不建议使用这些类型，推荐使用CLOB，BLOB，都是内部的LOB(Large Object)类型，最长4G。

2) 非标准：

VARCHAR2(n CHAR)、CHAR(n CHAR)

VARCHAR2(n CHAR)改为VARCHAR2(n)；

CHAR(n CHAR)改为 CHAR(n)；

3) 国家字符集相关：

NCHAR、NVARCHAR2、NCLOB。

NCHAR改为CHAR；

NVARCHAR2改为VARCHAR2；

NCLOB改为CLOB。

35. 【强制】禁止应用程序使用具备DBA特权的用户访问数据库(主要为数据安全）。

36. 【强制】禁止应用程序连接数据库的用户（应用用户）拥有select any dictionary权限（可以具体授予查询特定的数据字典表的权限）(主要为数据安全）。

37. 【强制】 禁止把视频、音频等多媒体文件存放Oracle数据库内部，禁止使用Oracle的Mutlimedia功能，多媒体文件应保存在数据库外包的文件系统中。

38. 【强制】新开发的应用系统或新模块，除临时表外，禁止使用无日志的表和不带日志的操作（在数据库参数配置标准中已经从底层禁止了无日志表和无日志操作，如：oracle数据库都设置了force logging模式）。

39. 【强制】禁止应用系统中直接使用删表语句。

说明：直接删除数据及表结构。

反例：drop table xx;

40. 【强制】新开发的应用系统或新模块禁止使用中文和特殊符号来命名表、索引、视图等对象。

说明：Oracle标准命名规范里禁止使用中文、空格、特殊字符等，避免后续使用中因为忽略双引号导致程序错误，如非必要，禁止使用。

41. 【强制】新开发的应用系统或新模块禁止使用物化视图(mview) 和 trigger 。

说明：资源消耗大；每个触发器都是一个隐藏的存储过程，当做批量修改，多次触发trigger触发器时，效率很低且容易死锁。

42. 【建议】建议应用系统中不要出现大表与其他表关联，以及三表以上关联。

说明：用分解关联查询的方式重构查询让缓存的效率更高。许多应用程序可以方便地缓存单表查询对应的结果对象。另外对于MySQL的查询缓存来说，如果关联中的某个表发生了变化，那么就无法使用查询缓存了，而拆分后，如果某个表很少改变，那么基于该表的查询就可以重复利用查询缓存结果了。将查询分解后，执行单个查询可以减少锁的竞争。在应用层做关联，可以更容易对数据库进行拆分，更容易做到高性能和可扩展。查询本身效率也可能会有所提升，可以减少冗余记录的查询。

三、生产环境禁止项

43. 【强制】禁止生产环境上不允许通过root系统账号、DBA权限的数据库账号进行应用部署，必须进行应用分级权限进行管理。

说明：安全原因。

规避方案：分级权限管理。

44. 【强制】禁止将应用所需文件安装在操作系统的/home、/usr、/var等目录下。

说明：避免造成系统问题。

规避方案：应当安装在app下。

45. 【强制】禁止未经测试的硬件设备。

说明：安装和使用安全问题。

规避方案：使用公司集中采购的服务器来实现功能。

46. 【强制】禁止单电源设备使用。

说明：使用安全问题。

规避方案：使用双电源。

开发者 软件安全 软件开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。