开发安全代码编写规范制度.doc

安全代码编写规范一、 编写目的为加强我司在软件开发中的安全规范要求,减少应用上线后带来潜在的安全风险,特拟定安全代码编写规范。二、 使用范围本规范适用于百度有限公司的开发类软件项目。三、 应用安全设计在总体架构设计阶段,需明确与客户方沟通确认甲方对于软件安全的相关要求，对于有明确安全要求的（例如授权管理要求、用户认证要求、日志审计要求等）,须在设计文档中予以详细说明.对于互联网应用,务必明确网络安全、应用安全、数据安全相关的安全防护手段。在技术架构上，应采用表现层、服务层、持久层分类的架构，实现对底层业务逻辑进行有效隔离，避免将底层实现细节暴露给最终用户.在部署架构上,应采用应用服务器、数据库服务器的分离部署模式，在应用服务器被攻击时，不会导致核心应用数据的丢失.如软件产品具备有条件时，应优先采用加密数据传输方式（例如https协议）。在外部接口设计方面,应采用最小接口暴露的原则,避免开发不必要的服务方法带来相关安全隐患,同时对于第三方接口，应共同商定第三方接入的身份认证方式和手段。四、 应用安全编码4。1. 输入验证对于用户输入项进行数据验证，除常见的数据格式、数据长度外，还需要对特殊的危险字符进行处理.特殊字符包括 ” % ( ） + ”等。对于核心业务功能,除在客户端或浏览器进行数据验证外,还必须在服务器端对数据进行合法性检验,规避用户跳过客户端校验，直接将不合规的数据保存到应用中。对于浏览器重定向地址的数据,需要进行验证核实，确认重定向地址是否在可信,并且需要对换行符(r或n）进行移除或者替换.4.2. 数据输出对需要输出到用户浏览器的任何由用户创造的内容，应在输出到浏览器之前或持久化存储之前进行转义(至少对转义为lt; gt；）以防止跨站攻击脚本（XSS)。对于无法规避的HTML片段提交，需对script、iframe标签进行检查处理,避免应用被挂马的可能性。在程序中应尽量规避SQL的拼接处理，优先推荐使用iBatis/MyBaits框架，其次推荐使用SQL的参数化查询方法，在无法避免使用SQL拼接时，因对SQL参数值进行编码处理(至少对单引号进行编码）.4。3。会话管理不要在 URL、错误信息或日志中暴露会话标识符。会话标识符应当只出现在HTTP cookie头信息中。比如,不要将会话标识符以 GET参数进行传递。将cookie设置为HttpOnly属性，除非在应用程序中明确要求了客户端脚本程序读取或者设置 cookie的值.从Cookie或者Session中获取之前保存的数据进行应用时，须增加必要的数据检验。对于敏感的业务操作，通过在每个请求或每个会话中使用强随机令牌或参数,为高度敏感或关键的操作提供标准的会话管理。4。4.访问控制应用必须具备授权访问控制功能，能够限制在最小的范围内使用系统功能.同时限制只有授权的用户可以访问受保护的URL。4.5。 文件管理在文件上传处理中，应限制符合要求格式的文件，尽量避免用户直接上传可执行文件或在服务器端限制可执行文件的执行权限.在文件下载时,应规避直接列举服务器上的文件，同时规避将服务器端的路径作为参数进行传递，避免用户非法获取服务器端文件。4。6. 数据加密原则上在程序代码中不能直接写入用户和密码，对于无法规避的情况，应当对使用的用户名、密码进行加解密处理，在程序中使用加密后的内容。4。7。 错误处理不要在错误响应将服务器的信息暴露给最终用户，例如：服务器的IP地址、操作系统的类型和版本、会话标识符、账号信息等，从而避免增加服务端被黑客攻击的可能性.在错误处理时,因在后台统一进行日志记录,避免显示调试或堆栈跟踪信息，建议使用通用的错误消息并使用定制的错误页面。4。8.其它通用规范审核应用使用的第三方开发框架、第三方代码或类库文件，以确定业务的需要，并验证功能的安全性，避免产生新的漏洞.执行安全更新。如果应用程序采用自动更新,则为您的代码使用加密签名，以确保的您的下载客户端验证这些签名。使用加密的信道传输来自主机服务器的代码。