安全技术规范

安全设计规范(参考)

? 前端不能直接访问数据库，应采取三层架构（表现层、业务逻辑层、数据访问层） 通用 ? 应不信任、不依赖客户端的安全控制措施，无论客户端采取何种措施，服务器侧都必须对用户提交的数据进行合法性检测 通用 ? 登录入口应具有防止暴力猜解及撞库猜解（利用已泄漏的密码字典进行尝试）的措施，超过设定失败次数需要启用锁定或CAPTCHA图片随机码 通用 ? 用户口令的主保护措施使用SHA256/SHA512/SHA-3或更高强度的散列算法，不使用MD5或SHA-1 通用 ? 交易/支付过程应形成完整的证据链，待交易数据应经过发起方数字签名 通用 ? 软件升级/规则下发等数据分发过程，接收方应验证数据源的完整性(数字签名/HASH等) 通用

? 设计上支持SOD( Seperation of Duty权限分离)，操作系统管理员、应用管理员、数据库管理员可以由不同的人员担任 通用 ? 软件发布前应经过数字签名 客户端 ? 启动时应对软件包所含的全部可执行文件、库、配置文件进行完整性校验，防止篡改或替换 客户端 ? 客户端与服务器建立会话前应首先验证服务器证书的合法性，防止用户流量被劫持 客户端 安全开发规范(参考)

? 前端不能直接访问数据库，应采取三层架构（表现层、业务逻辑层、数据访问层） 通用 ? 登录入口应具有防止暴力猜解及撞库猜解（利用已泄漏的密码字典进行尝试）的措施，超过设定失败次数需要启用锁定或CAPTCHA图片随机码 通用

? 应不信任、不依赖客户端的安全控制措施，无论客户端采取何种措施，服务器侧都必须对用户提交的数据进行合法性检测 通用 ? SQL语句应使用预编译和绑定变量的机制以实现SQL指令和参数的分离，不要拼接SQL语句，如有必须拼接的场景，应对每个参数进行合法性验证，包括整型验证、单引号的数据库转义(将单引号转换为两个单引号)等 通用 ? 对需要输出到用户浏览器的任何由用户创造的内容，应在输出到浏览器之前或持久化存储之前进行转义(至少对<>转义为< >)以防止跨站攻击脚本(XSS) 通用 ? 针对交易或特权操作，应防止跨站请求伪造，应在框架层面为每个Form启用隐藏属性的CSRF Token，或者使用图片CAPTCHA由用户手工输入，或者使用支付口令等措施，修改密码须输入原密码，以防止跨站请求伪造(CSRF) 通用 ? 应限定用户上传的附件类型，并对用户提交的图片/资源进行二次渲染(或添加水印/格式转换等)以破坏其原有结构，防止引入有害文件(网页木马等) 通用 ? 不使用路径或文件名作参数以防止目录遍历，不接受/不信任/不展示未经验证的外部图片或资源链接 通用

? 用户口令的主保护措施使用SHA256/SHA512/SHA-3或更高强度的散列算法，不使用MD5或SHA-1 通用 ? 对敏感信息纪录做适当隐藏（如以星号代替部分信息），不发送/不展示完整的敏感信息，数据库应对敏感信息的部分字段进行加密，确保泄露之后不能构成完整的信息纪录 通用 ? 交易/支付过程应形成完整的证据链，待交易数据应经过发起方数字签名 通用 ? 软件升级/规则下发等数据分发过程，接收方应验证数据源的完整性(数字签名/HASH等) 通用 ? 如条件满足，建议使用代码审计工具对代码进行扫描，无高危缺陷视为通过 通用 ? 软件开发工具均为直接从官方站点下载的正版软件，而不是从第三方站点所获取的 客户端 ? 客户端软件所包含的开源组件均为安全稳定版本，并直接从官方站点下载，而不是从第三方站点获取

客户端 ? 软件发布前应经过数字签名 客户端 ? 启动时应对软件包所含的全部可执行文件、库、配置文件进行完整性校验，防止篡改或替换 客户端 ? 客户端与服务器建立会话前应首先验证服务器证书的合法性，防止用户流量被劫持 客户端 ? 所有接受外部输入的参数，应执行边界检查，以防止缓冲区溢出 客户端 安全测试规范(参考)

? 测试用例应包含每个HTTP参数的SQL注入测试 通用 ? 测试用例应包含每个HTTP参数的XSS测试 通用