网管系统WEB代码开发安全指南V1.docx
《网管系统WEB代码开发安全指南V1.docx》由会员分享，可在线阅读，更多相关《网管系统WEB代码开发安全指南V1.docx（9页珍藏版）》请在冰豆网上搜索。
网管系统WEB代码开发安全指南V1
网管系统WEB代码开发安全指南
为提高程序开发人员的安全意识，从源头上减少代码安全上的漏洞，使开发人员能够开发出更加安全的应用程序，特制定本指南。
1.目标
1）确定安全WEB应用程序的重要体系结构和设计问题；
2）设计时考虑重要部署问题；
3）制定能增强Web应用程序输入验证的策略；
4）设计安全的身份验证和会话管理机制；
5）选择适当的授权模型；
6）实现有效的账户管理方法，并保护用户会话；
7）对隐私、认可、防止篡改和身份验证信息进行加密；
8）防止参数操作；
9）设计审核和记录策略。
2.安全编码原则
1）程序只实现你指定的功能
2）永不要信任用户输入，对用户输入数据做有效性检查；
3）必须考虑意外情况并进行处理；
4）不要试图在发现错误之后继续执行；
5）尽可能使用安全函数进行编程；
6）小心、认真、细致地编程。
3.安全开发生命周期
安全思想应贯穿于软件的全生命周期，即从需求分析、编码、测试、部署、运维等各个环节都应把安全考虑其中。
微软最早提出了SDL（SecurityDevelopmentLifecycle）即安全开发生命周期，给了开发人员比较全面的安全解决方案。
3.1安全培训
开发团队的所有人员都应接受适当的安全培训，了解相关的安全知识。
通过培训能贯彻安全策略和安全知识，并在之后的执行过程中提高执行效率，降低沟通成本。
培训对象包括开发人员、测试人员、项目经理、产品经理等。
培训内容应覆盖安全设计、威胁建模、安全编码、安全测试等方面的知识。
3.2安全要求
产品设计者在需求分析阶段，就应该把安全要求考虑其中。
如果产品需要通过信息安全等级保护，需参考国标GB/T22239-2008中相应等级的安全要求；如果产品需要达到信息安全技术EAL等级，需要参考GB/T18336-2008中相关等级的安全要求。
为确定产品的安全要求，设计者应对产品进行全面的风险评估，确定产品可能面临的所有风险，然后与甲方进行充分沟通，确定哪些风险是产品必须能够抵御的，哪些风险是可以接受的，最终确定产品应具有的安全功能。
例如产品应能够抵御误操作的风险，则可以要求产品具有针对不同用户分配不同权限的功能，从而实现用户权限最小化，避免误操作；例如产品要求能够避免用户暴力破解的风险，则要求产品登录时具有限定登录失败次数、采取验证码等功能。
以下为几种常见的安全要求，可作为参考。
3.2.1安全审计
1）程序应具有完善的审计功能，可以审计每个用户的登录注销、操作行为；
2）审计记录的内容至少应包括事件的日期、时间、发起者信息、类型、描述和结果等；
3）应保证除安全审计员外其他用户无法单独中断审计进程，无法删除、修改或覆盖审计记录；
3.2.2访问控制
1）程序应提供访问控制功能，依据安全策略控制用户对文件、数据库表等客体的访问；
2）访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作；
3）应授予不同帐户为完成各自承担任务所需的最小权限，并在它们之间形成相互制约的关系。
如系统应提供为不同用户分配不同权限的功能，由管理员创建用户，并为不同用户分配不同权限。
4）禁止出现水平越权和垂直越权的问题。
如可通过以下方式：
●当用户进行增、删、改、查等操作时，应验证是否是用户本人操作。
●对于每一个需要认证访问的url，都应首先检查用户是否已登录，如果没有登录，跳转到登录页面；同时应检查登录用户是否具有相应的权限，如果没有，拒绝访问。
●SessionID应不可预测，使用一些安全的随机数生成算法，避免攻击者猜测。
●对于用户是否已经认证，不能完全依靠客户端的参数标识，应将是否登录的标识保存在服务器端的会话中。
3.2.3通信完整性
应采用密码技术保证通信过程中数据的完整性。
如数据D传输前，先通过哈希算法（如SHA）计算出哈希值H1，然后把数据D和哈希值H1传输到接收方。
接收方对数据D使用相同的哈希算法计算出哈希值H2，如果H1与H2相同，证明数据在传输的过程中未被篡改。
3.2.4通信保密性
应对通信过程中，应对所有重要数据加密处理。
如采用https的方式对重要数据进行加密后再传输。
3.2.5抗抵赖
1）对于重要应用，应采取技术手段为数据原发者或接收者提供数据原发证据的功能。
如通过数字签名技术，发送方在发送数据前，使用自己的私钥对原文进行加密。
2）对于重要应用，应采取技术手段为数据原发者或接收者提供数据接收证据的功能。
3.2.6身份鉴别
对于重要系统应提供身份鉴别功能，避免非授权用户访问。
总之，针对每一种不可接受的风险，产品至少应具有一个安全功能与之对应，进行风险规避。
设计者在确定安全要求时，可参考《GB/T18336-2008信息技术安全性评估准则》。
3.3安全设计
设计者在进行产品设计时，同时也应对安全要求进行详细设计，包括安全要求划分为几个安全子系统，每个安全子系统实现什么功能，各安全子系统之间的接口如何定义。
在设计阶段对于一些功能的实现上，也应进行安全评估，避免出现业务逻辑方面的安全问题。
3.4实施阶段
实施阶段主要涉及编码，以下为编码过程中需要注意的问题。
3.4.1输入数据合法性检验
注入漏洞、跨站漏洞、缓冲区溢出漏洞等高危漏洞均是因为程序未对用户输入数据进行合法性检验造成的。
因此永远不要相信用户输入的数据，在每一处用户可能输入数据处进行检查过滤。
注入漏洞是比较普遍的一个漏洞，也是非常危险的漏洞。
一旦攻击者发现系统存在注入漏洞，即可利用漏洞获取数据库信息、执行操作系统命令等。
注入漏洞包括命令注入、SQL注入、Xpath注入、LDAP注入等，在运营商测试中遇到的比较多的是SQL注入。
可通过以下方式避免SQL注入：
●严格限定数据类型和长度。
●使用预编译的避免防范注入。
●通过过滤特殊字符的方式避免注入。
●跨站脚本分为存储型跨站、反射性跨站、基于DOM的跨站。
其中危害性最大的是存储型跨站。
攻击者可能利用跨站脚本漏洞窃取用户的cookie，从而使攻击者绕过身份验证，直接以受害者身份登录系统，形成会话劫持攻击；攻击者也可能通过跨站脚本漏洞，执行非法删除数据、篡改页面等攻击行为。
避免跨站脚本漏洞可通过如下方式：
●对输入进行过滤，检查用户输入的数据是否包含一些特殊字符，如<、>、"