安全代码编写法律规范一、编写目的为加强我司在软件开发中的安全法律规范要求,减少应用上线后带来潜在的安全风险,特拟定安全代码编写法律规范。二、使用范围本法律规范适用于百度有限公司的开发类软件项目。三、应用安全设计在总体架构设计阶段,需明确与客户方沟通确认甲方对于软件安全的相关要求，对于有明确安全要求的（例如授权管理要求、用户认证要求、日志审计要求等）,须在设计文档中予以详细说明.对于互联网应用,务必明确网络安全、应用安全、数据安全相关的安全防护手段。在技术架构上，应采纳表现层、服务层、持久层分类的架构，实现对底层业务逻辑进行有效隔离，避开将底层实现细节暴露给最终用户.在部署架构上,应采纳应用服务器、数据库服务器的分离部署模式，在应用服务器被攻击时，不会导致核心应用数据的丢失.如软件产品具备有条件时，应优先采纳加密数据传输方式（例如 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 属性，除非在应用程序中明确要求了...
