跳转至

安全开发指南

高度概况:输入验证+白名单/黑名单

通用安全开发规范

安全开发规范比较好的,可以参考 OWASP安全编码指南,该规范是一个类似checklist,方便所有人员可以理解安全开发需要注意的事项。虽然该规范是10年之前编写,但基本上涵盖了安全开发绝大多数内容,没过一段时间读起来都有不通收获,堪称经典。
本章节依据该指南,进行了必要的精简,并且补充了一些具体实现细节。
该规范,不涉及具体开发语言,基本上适用于大部分开发语言所产生的安全问题。

输入验证

一切输入都可能是有害的
开发规范的核心中的核心规范,常见的安全问题,基本上都可以通过对输入(相对于系统来说,可能是用户输入、第三方模块调用传递的信息,或者数据库中读取等等)进行限制来避免。

输入建议采用白名单的方式是安全的 比如接收到参数id,应该是一个int类型,在获得到该参数时,首先将判断参数id是否是int,或者将参数id强制转换成int,如果参数id应该传递一个1~100之间的整数,则还应该继续判断传递的参数id是否在[1,100]

有些时候白名单很难判断,最少需要进行黑名单判断 比如接收到参数name应该是字符型,如果没有办法使用简单的a-zA-Z0-9进行白名单检查,则最少要判断没有传递进来可能产生危害的单引号,&,&&等

什么是输入?
举个简单例子,你编写的函数/模块,接收到的参数都是一种输入,无论这个参数是从前端浏览器获取,还是其他同事处理后的结果,还是从数据库读取的信息。

编码输出

这点主要是针对xss类似问题,但随着业务的复杂,简单的编码可能导致系统不可用,建议根据实际业务场景进行决定。

身份验证和密码管理

身份验证: 注册,登录,忘记密码
假设是需要输入用户名username或密码password

  • 判断用户名是否存在 不提示明确的信息(如用户名已经存在,密码错误等)

  • 防止批量注册/暴力破解,添加IP限制(每天注册N个或者每分钟注册N个),添加图片验证码(连续注册N个出现验证码),限制统计信息建议使用服务端缓存如redis,不建议使用session,容易被绕过

  • 账号和密码网络传输使用HTTPS

  • 网络请求建议使用HTTP POST
  • 密码需要满足:非默认密码,与用户名不同,不包括用户名,复杂度要求(8以上,包括数字、字母、特殊字符等), 密码变更要求,禁止重置成相同密码
  • 密码存储建议使用不可逆的hash算法,并且加盐
  • 是否需要二次认证(如短信认证,Google Authenticator)
  • 密码变更需要通知用户或者在审计日志中查看
  • 用户名和密码禁止明文保存到代码中

其他建议

  • 默认的账号和密码,第一次登陆强制修改密码
    很多产品管理后台,都内置了账号和密码,如果没有强制修改密码,则很可能导致一个"弱口令"

  • 第三方登录 如使用微信登录,无需本系统管理账号和密码

  • 短信验证码 一次一密 类似于动态密码,安全性比较高

  • 短语密码 解决复杂密码难于记录的问题,比如使用成语作为密码,亡羊补牢(Wang,yang,bu,lao1) 满足密码复杂度要求,便于记忆,难于破解

会话管理

  • 会话标识随机化,保存到服务器,过期时间,设置域和路径
  • 重新登录 会话标识重新设置
  • 同一个用户不允许并发登录
  • cookie设置HttpOnly属性
  • TLS连接上传输的cookie设置"安全"属性

访问控制

  • 合理设置系统的权限,并且正确实现它

加密规范

  • 敏感数据加密存储
  • 密钥管理(禁止明文存储,与代码分离保存到配置文件)

错误处理和日志

  • 异常时,捕获错误处理记录日志
  • 日志禁止记录敏感信息(如手机号,登录密码)
  • 记录失败的输入验证、失败的身份验证、失败的访问控制
  • 禁止将错误信息返回到客户端
  • 及时远程备份日志,存储时长6个月以上

数据保护

  • 敏感数据存储时加密
  • 敏感数据前端展示时,脱敏/掩码
  • 禁止明文存储密码,数据库密码等
  • 禁止在 HTTP GET请求参数中包含敏感信息
  • 禁止服务器源代码被下载

通讯安全

  • 传输使用TLS
  • 链接到站外时,禁止HTTP referer 包含敏感信息

系统配置

  • 资产记录,确保是最新版本
  • web服务器加固:禁止目录列表,进支持http get、post, robots.txt禁止对外检索
  • 线上环境禁止测试代码、代码压缩包等
  • 系统裁剪到满足需求的最小版本
  • 第三方开源包裁剪

数据库安全

  • 参数化查询
  • 删除默认账号及不需要的功能
  • 最小权限连接数据库,连接信息加密存储
  • 数据库备份,防止被删库

文件管理

  • 上传文件:禁止修改文件路径,文件后缀白名单,存储在web路径外/去掉服务器解析,校验文件内容
  • 所有文件操作(读/下载,写/上传,编辑,删除等) 禁止从客户端获取文件路径,至少过滤..等特殊字符
    注:目前很多web框架,都采用路由映射的方式对外发布路径,对文件上传解析有一定的防护作用。

总结

owasp编码指南基本上涵盖了常见的安全问题,是一份很好的检查列表。 但到具体语言应该怎样进行编写,同时由于各种开发语言还是有所差异,可能存在其他安全风险,如php的变量覆盖等,因此针对特定开发语言,还有对应的开发规范

参考连接

OWASP安全编码项目

GO 语言安全开发指南

Checkmarx 编写
这是一本由 Checkmarx Security Research Team 基于OWASP安全编码指南进行编写,里面列举了大量的实际GO语言例子
GO语言安全编码指南

腾讯编写
Go安全指南

移动安全

随着移动时代的到来,移动安全更加的重要。移动端安全与服务端有很多相似之处,但由于移动端引入了新的技术,如安卓操作系统,ios操作系统,与原始的windows、centos存在差异,在原有安全问题基础上带来了一些新的问题,或者将原来的问题以新的形式进行展现

owasp 移动安全top 10

由于没有中文版本,所以有些翻译不一定准确,请大家对照英文自行确认

Improper Platform Usage(脆弱的服务器端安全控制)

移动移动应用程序没有以一个安全的方式向服务器发送数据,或在发送数据时暴露了一些敏感的 API
不正确的使用系统提供的API功能,或者没有使用系统提供了安全机制,而是自己开发脆弱的机制

Insecure Data Storage(不安全的数据存储)

当设备丢失或已经越狱的设备,可能导致存在设备上的敏感信息丢失
敏感信息不应该保存在
- URL caching (both request and response);
- Keyboard press caching;
- Copy/Paste buffer caching;
- Application backgrounding;
- Intermediate data
- Logging;
- HTML5 data storage;
- Browser cookie objects;
- Analytics data sent to 3rd parties.

insecure-communication(不安全传输)

数据在传输过程中被篡改,并且没有被发现

建议网络通信: HTTPS + 数据层二次加密(每个用户一个密钥)

Insecure Authentication

相关资料

owasp 移动安全top 10

owasp 移动安全测试标准

owasp 移动安全测试向导

appsec wiki

Back to top