一、背景
团队最近频繁遭受网络攻击，引起了技术负责人的重视，笔者在团队中相对来说更懂安全，因此花了点时间编辑了一份安全开发自检清单，觉得应该也有不少读者有需要，所以将其分享出来。
二、逻辑安全
2.1 身份验证
| 说明 | 检查项 |
| 概述 | 所有对非公开的网页和资源的访问,必须在后端服务上执行标准的、通用的身份验证过程 |
| 提交凭证 | 用户凭据必须经过加密且以POST方式提交,建议用HTPS协议来加密通道、认证服务端 |
| 错误提示 | 安全地处理失败的身份校验,如使用"用户名或密码错误"来提示失败,防止泄露过多信息 |
| 异常处理 | 登录入口应具有防止暴力或撞库猜解(利用已泄露的密码字典进行批量登录尝试)的措施,超过1次验证失败自动启用图灵测试,超过多次验证失败自动启用账户锁定机制限制其访问 |
| 二次验证 | 在执行关键操作(如账户密码修改、资料更新、交易支付等)时,先启动图灵测试,再对用户身份进行二次验证。交易支付过程还应该形成完整的证据链,待交易数据应经过发起方数字签名 |
| 多因子验证 | 高度敏感或核心的业务系统,建议使用多因子身份验证机制,如短信验证码、软硬件 Token等。 |
2.2 短信验证
| 说明 | 检查项 |
| 验证码生成 | 复杂度至少6位数字或字母,一次一用,建议有效期不超过180秒。 |
| 验证码限制 | 前后端设置用户获取频率为60秒一次,建议每个用户每天获取的短信最多10条 |
| 安全提示 | 增加安全提示:至少含本次操作的功能、验证码发送编号、是否是个人自己操作的风险等信息。 |
| 凭证校验 | 禁止在响应中返回验证码,服务器端同时校验密码、短信验证码等凭证信息,防止出现多阶段认证绕过的漏洞。 |
2.3 图灵测试
| 说明 | 检查项 |
| 验证码生成 | 复杂度至少4位数字或字母,或者采用拼图等验证方式,一次一用,建议有效期不超过180秒 |
| 验证码使用 | 建议从用户体验和安全角度出发,可设计为当用户输错1次密码后自动弹出验证码输入框验证 |
| 验证码校验 | 禁止在响应中返回验证码,验证码校验应在服务端进行 |
2.4 密码管理
| 说明 | 检查项 |
| 密码设置 | 密码设置时,应该满足8位及以上长度,含大小写字母、数字及特殊字符等的要求。用户密码设置必须经过后端验,不允许设置不满定复杂度要求的感密码。 |
| 密码存储 | 用户密码存储时,应采用哈希算法(如SHA1)计算用户密码和唯一随机盐值(Salt)的摘要值保存其摘要和Sat值,建议分开存储这两个值 |
| 密码修改 | 用户修改密码时,修改操作需要通过手机号或者邮箱地均进行一次身份验证。密码变更时,应短信或者邮件通知如用户是否是本人操作,告知其安全风险 |
| 密码找回 | 用户密码找回时,后端需要对注册手机号或邮箱进行二次验证,验证码和验证链接应发送至预先注册的地址,并设置有效期以防止暴力破解。密保问题,应当支持尽可能随机的问题提问。在多个验证操作中,要对各验证机制进行排序,以防出现跳过前面验证机制直接到最后步认证的安全风险 |
| 密码使用 | 应用开发中禁止设置万能密码、硬编码明文的密 码、使用数据库管理员账户操作、不同用户公用账 户操作或者将密码输出到日志文件或者控制台. |
2.5 会话安全
| 说明 | 检查项 |
| 防止会话劫持 | 在应用程序进行身份验证时,建议持续使用HTTPS连接,认证站点使用HTTPS协议。如果连接是从防止会话劫持HTTP跳转到HTTPS,需要重新生成会话标识符。禁止在HTTP和HTTPS之间来回转换,这可能会导致会话被劫持 |
| 会话标识符安全 | 设置会话 Cookie时,正确设置" Httponly'属性(禁止程序加5脚本等读取 Cookie信息)" Secure'属性(禁Cookie安全设置止Cookie通过HTTP连接传递到服务器端进行验证);" Domain"属性(跨域访问时可指定的授权访问域名),"Path"属性(授权可访问的目录路径)。 |
| Cookie安全设置 | 会话标识符应放置在HTP或HTPS协议的头信息安全中,禁止以GET参数进行传递、在错误信息和日志中记录会话标识符 |
| 防止CSRF攻击 | 服务器端执行了完整的会话管理机制,保证每个会防止CSRF话请求都执行了合法的身份验证和权限控制,防止攻击发生跨站点请求伪造(CSRF)漏洞。 |
| 会话有效期 | 会话应在平衡风险和功能需求的基础上设置有效期。定期生成一个新的会话标识符并使上一个会话会话有效期标识符失效,这可以缓解那些因原会活标识符被盗而产生的会话劫持风险。 |
| 会话注销 | 注销功能应用于所有受身份验证保护的网页,用户会话注销登出后应立即清理会话相关信息,终止相关的会话连接 |
2.6 访问控制
| 说明 | 检查项 |
| 控制方法 | 将访问控制的逻辑代码与应用程序其他代码分开服务端根据会话标识来进行访问控制管理。 |
| 控制管理 | 限制只有授权的用户才能访问受保护的URL、文件、服务、应用数据、配置、直接对象引用等 |
| 接口管理 | 限制只有授权的外部应用程序或接口才能访问受保护的本地程序或资源等 |
| 权限变更 | 当权限发生变更时,应记录日志,并通知用户是否是本人操作,告知存在的安全风险 |
2.7 文件上传安全
| 说明 | 检查项 |
| 身份校验 | 进行文件上传时,在服务端对用户的身份进行合法性校验 |
| 合法性校验 | 进行文件上传时,在服务端对文件属性进行合法性校验,白名单形式检查文档类型(如文件的后缓名、文件头信息校验等)和大小(图片校验长、宽和像素等)。 |
| 存储环境设置 | 进行文件保存时,保存在与应用环境独立的文档服务器中(配置独立域名),保存的目录权限应设置为不可执行 |
| 隐藏文件路径 | 进行文件保存时,成功上传的文件需要进行随机化重命名,禁止给客户端返回保存的路径信息。 |
| 文件访问设置 | 进行文件下载时,应以二进制形式下载,建议不提供直接访问(防止木马文件直接执行) |
2.8 接口安全
| 说明 | 检查项 |
| 网络限制 | 调用方网络限制,比如通过防火墙、主机host和Nginx deny等技术措施进行校验。 |
| 身份认证 | 调用方身份认证,比如key、 secret、证书等技术措施进行校验,禁止共享凭证 |
| 完整性校验 | 调用的数据安全,对全部参数使用SHA1等摘要运算进行数字签名,识别数据被篡改 |
| 合法性校验 | 调用的参数检查,如参数是否完整,时间戳和Token是否有效,调用权限是否合法等 |
| 可用性要求 | 调用的服务要求,调用满足等幂性即保持数据一致性,对调用频率和有效期进行限制 |
| 异常处理 | 调用的异常处理,调用行为实时检测,发现异常及时阻拦 |
