代码编写安全规范

第一章安全编码

第一条应用程序应该彻底验证所有用户输入，然后再根据用户输入执行操作。验证可能包括筛选特殊字符。针对用户意外地错误使用和某些人通过在系统中注入恶意命令蓄意进行攻击的情况，这种预防性措施对应用程序起到了保护作用。常见的例子包括 SQL 注入攻击、脚本注入和缓冲区溢出。此外，对于任何非受控的外部系统，都不要假定其安全性。

第二条尝试使用让人迷惑的变量名来隐藏机密信息或将它们存储在不常用的文件位置，这些方法都不能提供安全保障，最好使用平台功能或使用已被证实可行的技术来保护数据。

第三条如果应用程序失效（如发生严重错误等），要恰当的进行处理，一定要保护好机密数据。同时，在向最终用户返回错误消息时，不要公开任何不需要公开的信息。也就是不要提供任何有助于攻击者发现应用程序漏洞的详细信息。

第二章职责分离

第四条职责分离通常是应用在职能与责任方面的一条安全原则。职责分离包含两个方面的内容：一是限制单个用户的能力，以免其做出欺诈行为或滥用其权限；二是在划分应用程序的组件时，设计人员应该尝试根据功能和权限来划分它们，不同功能应由不同的组件来处理，如订单处理与检查账户状态的组件应该区分开。

第五条对于用户的职责分离来说，如果在一个安全模型中确定了用户或用户角色，而且他们各自具有不同级别或类型的信息资产访问权限，那么应进行用户职责分离。虽然由角色和权限构成的矩阵是由客户来定义的，但是设计人员必须确保应用软件能够提供必要的支持功能来满足客户的这种需求。

第六条对于组件的职责分离来说，可以按照各种不同的方式划分组件，如：

按照编程人员划分：各个编程人员应该编写不同的组件，尤其对大多数安全敏感型的组件来说，更应该这样；
按照管理员划分：各个系统管理员应该负责管理不同的组件；按照网络层次划分：各个组件应该被分布部署到网络的各个层次中，因为各层面临的攻击程度不同；
按照功能划分：每一个组件中只包含必要的功能；第七条具有不同权限的组件大多是完全隔离的。考虑
将展现层和应用层的功能划分开的这种情况，一般来说，展现层所包含代码的权限要比应用层代码的权限低。例如，展现层的代码通常不能直接访问数据库，而应用层的代码就可以。

第三章授权

第十条授权主要是指对于登录进入系统的用户的操作权限进行合理设置，以使其完成所需工作。

第十一条在各种基础平台中已经都内置较为完备的授权机制，可以充分利用，如下列表所示：

操作系统的文件系统权限设置；
应用基础平台中的授权框架，如.NET 中的角色与用户控制，Java 中的鉴别与授权服务（JAAS）等；
数据库管理系统中的数据库角色、数据库对象权限设置；

第十二条除了利用基础环境的访问机制外，可以在应用软件中设计实现自定义的访问控制，这种访问控制一般是采用基于角色的授权机制（ RBAC），RBAC 访问控制模型实现了用户与访权限的逻辑分离，减少了授权管理的复性，降低了管理开销，而且与日常信息统管理的架构类似，降低了管理复杂度。

第十三条要配置和设计实现授权体系时，要特别注意以下事项：

在进行授权体系的设计时，一定要完备，避免个别环境的控制措施缺失所带来的安全隐患；
严格执行最小权限原则，只给用户开放完成其功能所必须的权限；
在用户执行每个功能前，要首先对其权限进行检查；
要注意 Web 应用系统中所包含的 URL 资源进行严格权限设置，这是一个最易受攻击的区域；
要利用数据库服务器集成的权限控制措施来控制用户的操作权限，要限制一些危险操作的进行，如删除数据表、更改数据库结构、执行危险的存储过程等。

第四章最小权限

第八条对于系统中用户，应该只授予其完成必要功能的最小权限，避免其提升权限

第九条对于执行代码的进程应当尽可能用权限最少的帐户运行，从而在危及进程安全时限制可能造成的破坏。一般情况下禁止以系统管理员的身份来执行应用程序。如果恶意用户设法将代码注入某个服务器进程，那么授予该进程的权限会在很大程度上决定该用户可执行的操作类型。应当将需要更多信任（和更高权限）的代码分别隔离在不同的进程内。