一、背景
团队最近频繁遭受网络攻击，引起了技术负责人的重视，笔者在团队中相对来说更懂安全，因此花了点时间编辑了一份安全开发自检清单，觉得应该也有不少读者有需要，所以将其分享出来。
二、编码安全
2.1 输入验证
| 说明 |
检查项 |
| 概述 |
任何来自客户端的数据,如URL和参数、HTTP头部、 Javascript戓其他嵌入代码提交的信息,都属于不可信数据。在应用外部边界或内部每个组件或功能边界,都将其当做潜在的恶意输入来校验 |
| 白名单 |
不可信数据可以设定白名单校验的,应接受所有和白名单匹配的数据,并阻止其他数据 |
| 黑名单 |
不可信数据中包含不良输入字符时,如空字节(%00)、换行符(%0d,%0a,r, n)、路径字符(../ 或 ..)等,建议直接阻止该数据,若需要接受该数据,则应做不同方式的净化处理 |
| 规范化 |
不可信数据的净化和校验前翯进行规范化,如将目录遍历(./或)等相对路径转化成绝对路径URL解码等。 |
| 净化 |
不可信数据需实施各种净化处理时,应彻底删除恶意字符,只留下已知安全的字符,或者在处理前对它们进行适当编码或"转义",如数据输出到应用页面时对其进行HTML编码可防止脚本攻击 |
| 合法性校验 |
不可信数据的合法性校验包括:数据类型如字符.数字、日期等特征;数据范國;数据长度等 |
| 防范SQL注入 |
不可信数据进入后端数据库操作前,建议使用正角的参数化查询来处理,避免出现SQL注入 |
| 文件校验 |
不可信数据为解压缩的文件时,如果文件位于服务目录外或文件大小超过限制,应拒绝处理 |
| 访问控制 |
不可信数据通过上述校验后,还应确认所提交的内容是否与用户的身份匹配,避免越权访问 |
2.2 输出验证
| 说明 |
检查项 |
| 概述 |
考虑目标编译器的安全性，对所有输出字符进行正确编码 |
|
| 编码场景 |
不可信数据输出到前后端页面时,根据输出场景对其进行相关编码,如HTML实体编码、UR编码 |
| 净化场景 |
针对操作系统命令、SQL和LDAP查询,净化所有输出的敏感信息,如银行卡、手机号、系统信息等 |
2.3 SQL注入
| 说明 |
检查项 |
| 概述 |
用户的输入进入应用程序的SQL操作前,对输入进行合法性校验。 |
| 参数化处理 |
用参数化查询(PHP用PDO,Java用 PreparedStatement,C#用 Sqlparameter)方法对敏感字符如"进行转义,然后再进行SQL操作。 |
| 最小化授权 |
为每个应用配置最小化数据库操作权限,禁止用管理员权限进行数据库操作,限制操作连接数。 |
| 敏感数据加密 |
敏感信息都采用了加密、哈希或混淆等方式进行保密存储,降低可能漏洞带来的数据泄露风险. |
| 禁止错误回显 |
禁止系统开启 Debug模式或异常时返回包含敏感信息的提示,建议使用自定义的错误信息模板异常信息应存放在日志中用于安全审计 |
2.4 XSS跨站
| 说明 |
检查项 |
| 输入校验 |
对输入的数据进行过滤和转义,包含但不限于<>"9%0&+V"等危险特殊字符 |
| 输出编码 |
输入数据输出到不同场景中进行不同形式的编码,如输出到HTML标签中则进行HTML编码输出到URL中则进行URL编码,输出到JS中则行 Script编码,输出到 Stylet中则进行CSs编码 |
2.5 XML注入
| 说明 |
检查项 |
| 输入校验 |
在XML文档内部或外部引用数据时,过滤用户提交的参数,如<、>&等特殊字符。禁止加载外部实体,禁止报错 |
| 输出编码 |
建议对XML元素属性或者内容进行输出转义 |
2.6 CSRF跨站请求伪造
| 说明 |
检查项 |
| Token使用 |
在重要操作的表单中增加会话生成的 Token字段次一用,提交后在服务端校验该字段 |
| 二次验证 |
在关键表单提交时,要求用户进行二次身份验证如密码、图片验证码、短信验证码等 |
| Referer验证 |
检验用户请求中 Referer:字段是否存在跨域提交的情况 |
三、逻辑安全
3.1 身份验证
| 说明 |
检查项 |
| 概述 |
所有对非公开的网页和资源的访问,必须在后端服务上执行标准的、通用的身份验证过程 |
| 提交凭证 |
用户凭据必须经过加密且以POST方式提交,建议用HTPS协议来加密通道、认证服务端 |
| 错误提示 |
安全地处理失败的身份校验,如使用"用户名或密码错误"来提示失败,防止泄露过多信息 |
| 异常处理 |
登录入口应具有防止暴力或撞库猜解(利用已泄露的密码字典进行批量登录尝试)的措施,超过1次验证失败自动启用图灵测试,超过多次验证失败自动启用账户锁定机制限制其访问 |
| 二次验证 |
在执行关键操作(如账户密码修改、资料更新、交易支付等)时,先启动图灵测试,再对用户身份进行二次验证。交易支付过程还应该形成完整的证据链,待交易数据应经过发起方数字签名 |
| 多因子验证 |
高度敏感或核心的业务系统,建议使用多因子身份验证机制,如短信验证码、软硬件 Token等。 |
3.2 短信验证
| 说明 |
检查项 |
| 验证码生成 |
复杂度至少6位数字或字母,一次一用,建议有效期不超过180秒。 |
| 验证码限制 |
前后端设置用户获取频率为60秒一次,建议每个用户每天获取的短信最多10条 |
| 安全提示 |
增加安全提示:至少含本次操作的功能、验证码发送编号、是否是个人自己操作的风险等信息。 |
| 凭证校验 |
禁止在响应中返回验证码,服务器端同时校验密码、短信验证码等凭证信息,防止出现多阶段认证绕过的漏洞。 |
3.3 图灵测试
| 说明 |
检查项 |
| 验证码生成 |
复杂度至少4位数字或字母,或者采用拼图等验证方式,一次一用,建议有效期不超过180秒 |
| 验证码使用 |
建议从用户体验和安全角度出发,可设计为当用户输错1次密码后自动弹出验证码输入框验证 |
| 验证码校验 |
禁止在响应中返回验证码,验证码校验应在服务端进行 |
3.4 密码管理
| 说明 |
检查项 |
| 密码设置 |
密码设置时,应该满足8位及以上长度,含大小写字母、数字及特殊字符等的要求。用户密码设置必须经过后端验,不允许设置不满定复杂度要求的感密码。 |
| 密码存储 |
用户密码存储时,应采用哈希算法(如SHA1)计算用户密码和唯一随机盐值(Salt)的摘要值保存其摘要和Sat值,建议分开存储这两个值 |
| 密码修改 |
用户修改密码时,修改操作需要通过手机号或者邮箱地均进行一次身份验证。密码变更时,应短信或者邮件通知如用户是否是本人操作,告知其安全风险 |
| 密码找回 |
用户密码找回时,后端需要对注册手机号或邮箱进行二次验证,验证码和验证链接应发送至预先注册的地址,并设置有效期以防止暴力破解。密保问题,应当支持尽可能随机的问题提问。在多个验证操作中,要对各验证机制进行排序,以防出现跳过前面验证机制直接到最后步认证的安全风险 |
| 密码使用 |
应用开发中禁止设置万能密码、硬编码明文的密 码、使用数据库管理员账户操作、不同用户公用账 户操作或者将密码输出到日志文件或者控制台. |
3.5 会话安全
| 说明 |
检查项 |
| 防止会话劫持 |
在应用程序进行身份验证时,建议持续使用HTTPS连接,认证站点使用HTTPS协议。如果连接是从防止会话劫持HTTP跳转到HTTPS,需要重新生成会话标识符。禁止在HTTP和HTTPS之间来回转换,这可能会导致会话被劫持 |
| 会话标识符安全 |
设置会话 Cookie时,正确设置" Httponly'属性(禁止程序加5脚本等读取 Cookie信息)" Secure'属性(禁Cookie安全设置止Cookie通过HTTP连接传递到服务器端进行验证);" Domain"属性(跨域访问时可指定的授权访问域名),"Path"属性(授权可访问的目录路径)。 |
| Cookie安全设置 |
会话标识符应放置在HTP或HTPS协议的头信息安全中,禁止以GET参数进行传递、在错误信息和日志中记录会话标识符 |
| 防止CSRF攻击 |
服务器端执行了完整的会话管理机制,保证每个会防止CSRF话请求都执行了合法的身份验证和权限控制,防止攻击发生跨站点请求伪造(CSRF)漏洞。 |
| 会话有效期 |
会话应在平衡风险和功能需求的基础上设置有效期。定期生成一个新的会话标识符并使上一个会话会话有效期标识符失效,这可以缓解那些因原会活标识符被盗而产生的会话劫持风险。 |
| 会话注销 |
注销功能应用于所有受身份验证保护的网页,用户会话注销登出后应立即清理会话相关信息,终止相关的会话连接 |
3.6 访问控制
| 说明 |
检查项 |
| 控制方法 |
将访问控制的逻辑代码与应用程序其他代码分开服务端根据会话标识来进行访问控制管理。 |
| 控制管理 |
限制只有授权的用户才能访问受保护的URL、文件、服务、应用数据、配置、直接对象引用等 |
| 接口管理 |
限制只有授权的外部应用程序或接口才能访问受保护的本地程序或资源等 |
| 权限变更 |
当权限发生变更时,应记录日志,并通知用户是否是本人操作,告知存在的安全风险 |
3.7 文件上传安全
| 说明 |
检查项 |
| 身份校验 |
进行文件上传时,在服务端对用户的身份进行合法性校验 |
| 合法性校验 |
进行文件上传时,在服务端对文件属性进行合法性校验,白名单形式检查文档类型(如文件的后缓名、文件头信息校验等)和大小(图片校验长、宽和像素等)。 |
| 存储环境设置 |
进行文件保存时,保存在与应用环境独立的文档服务器中(配置独立域名),保存的目录权限应设置为不可执行 |
| 隐藏文件路径 |
进行文件保存时,成功上传的文件需要进行随机化重命名,禁止给客户端返回保存的路径信息。 |
| 文件访问设置 |
进行文件下载时,应以二进制形式下载,建议不提供直接访问(防止木马文件直接执行) |
3.8 接口安全
| 说明 |
检查项 |
| 网络限制 |
调用方网络限制,比如通过防火墙、主机host和Nginx deny等技术措施进行校验。 |
| 身份认证 |
调用方身份认证,比如key、 secret、证书等技术措施进行校验,禁止共享凭证 |
| 完整性校验 |
调用的数据安全,对全部参数使用SHA1等摘要运算进行数字签名,识别数据被篡改 |
| 合法性校验 |
调用的参数检查,如参数是否完整,时间戳和Token是否有效,调用权限是否合法等 |
| 可用性要求 |
调用的服务要求,调用满足等幂性即保持数据一致性,对调用频率和有效期进行限制 |
| 异常处理 |
调用的异常处理,调用行为实时检测,发现异常及时阻拦 |
四、数据安全
4.1 敏感信息
| 说明 |
检查项 |
| 敏感信息传输 |
敏感信息传输时,禁止在GET请求参数中包含敏感信息,如用户名、密码、卡号等。建议为所有敏感信息采用TSL加密传输。 |
| 客户端保存 |
客户端保存敏感信息时,禁止其表单中的自动填充功能、以明文形式保存敏感信息 |
| 服务端保存 |
服务端保存敏感信息时,禁止在程序中硬编码敏感信息,明文存储用户密码、身份证号、银行卡号、持卡人姓名等敏感信息,临时写入内存或文件中的敏感数据,应及时清除和释放 |
| 敏感信息维护 |
敏感信息维护时,禁止将源码或SQL库上传到开源平台或社区,如 Github、开源中国等。 |
| 敏感信息展示 |
敏感信息展示时,如果是展示在web页面上,应在后端服务器上进行敏感字段的脱敏处理。 |
4.2 日志规范
| 说明 |
检查项 |
| 记录原则 |
确保日志记录包含了重要的应用事件,但禁止保存敏感信息,如会话标识,账户密码、证件等 |
| 事件类型 |
记录所有的身份验证、访问操作、数据变更、关键操作、管理功能、登出记录等事件。 |
| 事件要求 |
日志一般会记录每个事件的发生时间、发出请求的IP地址和用户账户(如果已通过验证)。 |
| 日志保护 |
日志受到严格保护,避免未授权的读取或写入访问。 |
4.3 异常处理
| 说明 |
检查项 |
| 容错机制 |
在应用实现时应包含完整的功能异常捕获机制如try-catch块,典型位置:文件、网络、数据库、命令操作等。一旦出现异常,应该在日志中完整记录异常的发生时间、代码位置、报错详情、触发错误的可能用户等,重要系统的严重异常应该有报警的机制,及时通知系统运营者及时排查并修复题 |
| 自定义错误信息 |
在生产环境下,应用程序不应在其响应中返回任何系统生成的消息或其他调试信息,配置应用服务器使其以自定义的方式处理无法处理的应用程序错误,返回自定义错误信息 |
| 隐藏用户信息 |
禁止在系统异常时泄露用户的隐私信息,典型的有:身份信息、个人住址、电话号码、银行账号、通讯记录、定位信息等 |
| 隐藏系统信息 |
禁止在系统异常时泄露系统的敏感信息(用户账户和密码、系统开发密钥、系统源代码、应用架构、系统账户和密码、网络拓扑等)。 |
| 异常状态恢复 |
方法发生异常时要恢复到之前的对象状态,如业务操作失败时的回滚操作等,对象修改失败时要恢复对象原来的状态,维持对象状态的一致性 |
五、主机安全
5.1 I/O操作
| 说明 |
检查项 |
| 共享环境文件安全 |
在多用户系统中创建文件时应指定合适的访问许可,以防止未授权的文件访问,共享目录中文件的读/写/可执行权限应该使用白名单机制,实现最小化授权。 |
| 数据访问检查 |
防止封装好的数据对象被未授权使用,设置合理的据缓存区大小以防止耗尽系统资源, |
| 应用文件处理 |
应用程序运行过程中创建的文件,需设置问权限(读、写、可执行),临时文件使及时删除 |
5.2 运行环境
| 说明 |
检查项 |
| 最小化开放端口 |
关闭操作系统不需要的端口和服务 |
| 后台服务管理 |
后台(如数据缓存和存储、监控、业务管理等)务限内部网络访问,开放在公网的必须设置身份验证和访问控制。 |
| 环境配置 |
使用安全稳定的操作系统版本、Web股务器软件各种应用框架、数据库组件等 |
| 敏感代码处理 |
将客户端敏感代码(如软件包签名、用户名密码校验等)都放在o等软件包中防止篡改。 |
| 关闭调试通道 |
生产代码不包含任何调试代码或接口 |
| 通信安全 |
配置网站的HTTPS证书或其它加密传输措施。 |
六、图书推荐
如果对笔者的文章较为感兴趣，可以关注笔者新书《PHP Web安全开发实战》，现已在各大平台上架销售，封面如下图所示
作者：汤青松
日期：2018-11-13
微信：songboy8888
