安全代码编写标准规范.docVIP

安全代码编写规范 编写目标 为加强武汉楚烟信息技术在软件开发中安全规范要求，降低应用上线后带来潜在安全风险，特确定安全代码编写规范。 使用范围 本规范适适用于武汉楚烟信息技术承建各类开发类软件类项目。 应用安全设计 在总体架构设计阶段，需明确和用户方沟通确定甲方对于软件安全相关要求，对于有明确安全要求（比如授权管理要求、用户认证要求、日志审计要求等），须在设计文档中给予具体说明。对于互联网应用，务必明确网络安全、应用安全、数据安全相关安全防护手段。 在技术架构上，应采取表现层、服务层、持久层分类架构，实现对底层业务逻辑进行有效隔离，避免将底层实现细节暴露给最终用户。 在布署架构上，应采取应用服务器、数据库服务器分离布署模式，在应用服务器被攻击时，不会造成关键应用数据丢失。如软件产品含有有条件时，应优先采取加密数据传输方法（比如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. 其它通用规范 审核应用使用第三方开发框架、第三方代码或类库文件，以确定业务需要，并验证功效安全性，避免产生新漏洞。 实施安全更新。假如应用程序采取自动更新，则为您代码使用加密署名，以确保您下 载用户端验证这些署名。使用加密信道传输来自主机服务器代码。