/ Web安全

从攻击的角度看登录、注册流程安全设计方案

0x01 为什么关注登录、注册安全

用户登录功能是业务系统具备的最基本的功能,登录作为系统的入口,成功登录意味着拥有系统的使用权利,普通用户登录接口出现安全问题,可能导致用户数据泄露,对业务发展造成影响,而非普通用户登录入口出现安全问题,意味着攻击者拥有更大的攻击面去对系统进行攻击。

首先看几个登录、注册相关的业务安全问题

  1. 某短视频业务注册接口漏洞,可大量注册僵尸账号用于刷粉,引流,广告等
  2. 某站点登录接口可爆破、可爆破用户名,攻击成功可窃取用户账号信息,将账号用于其他目的
  3. 某站点注入被脱裤,用户密码明文存储。传统安全漏洞~

登录面临的最大问题是逻辑问题导致任意用户登录和爆破用户密码
注册面临的最大问题是恶意注册,影响用户生态

纵观国内各大互联网公司,其中腾讯是对用户账号体系运营最好的,一个QQ号,早些年针对QQ账号的安全,腾讯推出了各种安全手段,有密保、密保卡等多因子手段,到现在手机普及了,账号都和手机号进行关联,手机号成为一层更加有效和便捷的账号安全验证手段。网络安全法要求网络实名,而手机号绑定是进行实名化最有效的手段,虽然可能会增加用户的第一次使用体验,但是一定程度上造就了使用手机号作为安全验证的良好环境。而更安全的动态密码、USB是不适合互联网业务。

一个健壮的登录、注册系统应该具备哪些因素:

  • 无逻辑问题导致的任意用户登录问题(这里主要指用户认证逻辑不当,如前端验证、验证码回显等)
  • 无爆破风险或爆破的自动化成本高
  • 无任意注册漏洞或注册流程自动化进行的复杂度高
  • 完整的登出功能
  • 进行口令复杂度策略校验
  • 避免浏览器记住密码策略
  • 安全的口令存储方案
  • 以及实现上述因素采取的手段不具备绕过的可能

0x02 安全注册设计

注册的基本流程
用户注册流程图
首先用户注册需要采集哪些信息,几种方式:

  1. 先采集尽量少的数据(username/password),后续部分或全部功能使用需要绑定手机、邮箱等
  2. 直接采集其他关联数据——手机号、邮箱

目前第二种是大多数站点的方式,下面主要以第二种方式说明
数据验证是在注册时立即完成还是采用激活的方式?如果采用先注册存储数据后激活的方式,需要做访问验证账号是否激活,激活大多数是邮箱链接的方式,不适合手机。

数据验证安全设计:

  1. 后端数据验证,类型、格式,如手机号、邮箱格式,校验密码复杂度策略,邮箱可选择拒绝部分匿名邮箱后缀注册,不建议对空格等不可打印字符正则去除处理,避免用于绕过,直接拒绝。
  2. session中暂存用户标识数据、验证数据,响应客户端输入验证数据,邮箱可采取链接跳转方式。此处不可将验证码、链接响应在返回包内容、header中。
  3. 用户传输验证数据,与session中数据进行验证。如果使用数据库存储验证数据如验证码,在进行从数据库查询进行校验时,不使用客户端传输的数据查询数据库,通过session中能够标识该用户的数据去从数据库中查询。
  4. 如果注册涉及多个步骤,在最后插入注册成功数据前验证每一步是否完成。
  5. 针对验证码,记录手机号、邮箱、IP发送次数,对次数进行限制

存储、传输安全设计:

  1. 如果前端不进行数据加密,则后端需要加密再存储用户密码,md5(md5(salt,passwd))
  2. 数据传输加密,使用ssl或者对数据前端加密,避免中间人攻击

错误处理:
考虑一个问题,如果一个已经注册了的手机号,第二次注册时,是在发验证码时提示已注册,还是在所有数据提交时返回已注册呢?考虑使用短信验证码,可以避免使用图形验证码,因此这里我们需要在所有数据提交后返回已注册,以避免通过发手机验证码爆破已注册用户。

表关系:
一张用户账户密码表
零或一张验证码次数记录表,需要有手机号、IP、次数等字段
多张用户信息表

总结: 通过需要与用户进行交互来避免自动化注册机,而对于如果攻击者使用打码平台、接码平台,可采取使用搞交互式验证码来防止批量注册

0x03 安全登录设计

不关注会话保持、传统漏洞问题。画一个简单的流程图:
用户登录流程图

登录的几种方式:

  1. 账号(普通用户名、邮箱、手机号等)密码————常见
  2. 账号验证码

登录需要面临的问题是爆破和一些逻辑漏洞造成的任意用户登录等问题,其中任意用户登录又要分使用第三方账号和自己的账号体系,归根结底还是验证流程出现安全问题。

传输安全设计:

  1. 密码密文传输或ssl加密连接

数据处理安全设计:

  1. 数据格式化处理
  2. 校验密码,响应
  3. 登录错误,记录当前错误登录次数、IP,普通业务系统可使用验证码、错误锁定等策略,为了优化用户体验,可以使用错误次数达到阈值后再需要验证码登录。
  4. 处理验证码、Cookie为空等情况
  5. 对使用Token防止跨站的情况,是不能避免爆破的。
  6. 对使用验证码进行登录的情况,验证码长度应不少于六位,应限制时效性,以及验证次数限制
  7. 应避免使用自动登录功能

错误处理:
密码错误、账号不存在不直接提示,避免用于爆破账户名,返回账户或密码错误。

针对第三方账号体系,大多数为OAuth方式,应遵循OAuth安全设计原则。