一、背景
团队最近频繁遭受网络攻击,引起了技术负责人的重视,笔者在团队中相对来说更懂安全,因此花了点时间编辑了一份安全开发自检清单,觉得应该也有不少读者有需要,所以将其分享出来。
二、编码安全
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:字段是否存在跨域提交的情况 |