渗透测试-身份认证与会话

2019-10-09 14:08:42 admin

这篇文章主要是总结了一些自己在金融行业渗透测试过程中关于身份认证与会话相关测试点,金融行业对安全的基线要求和其他行业出入还是有一些的,所以笔者也是在测试中尽可能的兼容了一些用例,不足之处,请在公众号回复补充,感谢!


一、身份认证
1.1  登录认证绕过测试
  • 登录重放测试:是否对登录数据包做了完整性校验、防重放保护

  • 登录注入测试:测试是否存在注入,抓包拼接Sql语句,这种登录注入在金融行业基本看不见,不过在一些长久没有维护的旧网站还是有的

  • 微信绑定绕过测试:是否对绑定数据包做了防重放保护或者是否校验了微信OpenID

1.2 是否具有账户锁定策略
  • 在缺少锁定策略或验证码设计有问题的情况下,攻击者可以通过枚举的方式来进行暴力猜解,本测试用于发现目标系统是否缺少锁定策略。

  • 锁客户端IP风险:当用户使用proxy或者内网上网时,那么锁定客户端IP会导致使用该proxy、和共用同一IP出口上网的所有用户在IP锁定期间都不能使用该Web应用;

  • 锁定用户帐户风险:锁定用户帐户的策略也存在缺陷,当攻击者不断尝试某帐户的口令,就给该帐户带来拒绝服务攻击,使该帐户不可用。

1.3  内存读取测试

查看内存中是否保存明文身份认证敏感信息。

1.4 口令测试

  • 控件加密是否有密钥种子

每次加密是否是固定密文,亦或是增加了密钥种子;

引申问题:在修改密码时,一般有复杂度校验,可在原密码中输入弱口令,抓包从而获取弱口令的密文,再次修改密码,再用弱口令密文替换新密码密码,由于控件每次加密结果固定,加上服务端无复杂度校验,从而设置弱口令,不过这个测试项意义不大,只是图自己方便,可以设置一个简单的密码。

  • 密码错误次数测试

是否对密码错误次数做出控制

  • 密码返回在response数据包

即使是返回包中的是加密密文,也是不允许的。

  • 弱口令测试

检测系统是否允许设置类似于“111111”,“123456”,“123qwe”等弱口令。

  • 密码复杂度测试

检测是否在设置密码时至少具有两种字符组成,现在很多地方密码复杂度要求都是三种字符了,包括特殊字符。

弱口令与密码复杂度区别:

a、单一字符组成的口令不一定是弱口令,例如在柜台开户时,只有纯数字键盘,无法满足复杂度要求,柜台密码硬加密键盘会自动检测纯数字的口令是否为弱口令,且使用场景有限,所以设置成功的口令不算弱口令;

b、 满足密码复杂度也不能说明不是弱口令,比如“123qwe",由两种字符组成,满足密码复杂度,但是依然视为弱口令。

1.5 用户枚举测试

  • 能否对用户进行暴力破解

在登录接口或者其他接口中,一般输入用户身份唯一标识符时,开发者可能会校验此用户是否注册或存在,利用此漏洞,遍历已存在用户。

1.6 认证错误模糊提示

提示语信息泄漏,测试当用户名或密码错误时,提示用语是否安全。

1.7 图形验证码测试

  • 字符空间小

如果选取的字符空间较小,则让验证码识别字模总量变得很小。字母数字组合的字符集比单纯为数字的字符集效果要好,有些地方使用了中文字符作为验证码,这样字符空间就增大了很多。如果字符空间足够大,试图通过制作字符模板库方式来实现识别的难度就变得很大了。

单纯的图片验证码使用情况逐渐有减少的趋势,现在很多网站已经已经使用行为验证码、图标选择与行为辅助等验证码。

  • 可识别

验证码复杂度不够,有很多图片验证码识别API,比如阿里的,可通过增加字体扭曲、背景色干扰、字体粘连、背景字母干扰、字体镂空、公式验证码、字体混用、加减法验证码、主题干扰线、逻辑验证码等等方式来加强

  • 生成规律测试

观察验证码是否随机生成,是否存在一定的规律,验证码内容不能与客户端提交的任何信息相关联。

  • 生命周期测试

验证码在认证一次后是否立即失效,验证码的生命周期未控制好,如验证码可以重复使用、不设超时,验证一次,永久使用。

  • 回显测试

验证码返回用户直观可见,验证码不在一张图片中,如将验证码输出到页面中、写在cookie里,验证码不能使用文本格式,不允许多图片组合(如用四个图片拼成的验证码)。

  • 生成逻辑问题

生成验证码的模块是否根据提交的参数生成验证码。

  • 绕过测试

业务逻辑与验证码结合点存在问题,如修改业务参数可导致不用校验验证码也可通过、甚至验证码就是摆设。

1.8 密码找回/重置接口

  • 用户凭证时效性

一段时间后,用户凭证是否依然有效。

  • 凭证接收端篡改

查看是否能够篡改接收用户凭证的手机号、邮箱等。

  • 用户凭证暴力破解

短信验证码太短,纯数字情况是否存在可暴力破解

  • 凭证序列号绑定测试

有些短信验证码下发会附带一个序列号,测试序列号和凭证是否一一对应,呈绑定关系。

  • 越权重置

越权重置他人密码。

  • cookie混淆

  • response中返回凭证

直接返回短信验证码,返回验证码MD5值等

  • 重新绑定

  • 跳过验证步骤,直接访问修改密码页面

  • 客户端本地验证

密码修改逻辑放在前台js脚本,根据逻辑绕过修改密码。

  • Token问题

弱token,生成的密码找回token在数据包中返回,通过将帐号和token拼接进入重置密码页面,或者未校验Token与密码找回用户的对应的关系。



二、二维码相关

2.1、二维码生成

检测二维码的生成是在本地还是服务器,若为本地生成,检测是否可以破解生成算法,伪造二维码;若是服务器生成,使用工具捕获传输数据,检测传输的二维码数据是否加密、是否可以被篡改。

2.2、扫码功能

  • 扫码数据校验

在扫描二维码时会直接使用浏览器打开二维码中的url地址,客户端未对url的域名进行指定和限制,当浏览器存在命令执行漏洞时扫描恶意url可能导致系统感染木马,攻击者也可能通过恶意的二维码在线下对用户进行钓鱼攻击。

  • 扫码修改数据包任意登录


三、会话管理测试

3.1、 cookie属性测试:HttpOnly、Secure

是否设置HttpOnly、Secure:设置secure属性是针对可以同时使用https和http访问的站点,设置secure属性后cookie只能用https协议发送给服务器,用http协议是不发送的,将有助于防止Cookie通过未加密的请求发送;

HttpOnly属性的目的是防止js获取cookie,测试是否可以通过给网站植入超大的Cookie绕过httponly保护;

3.2、正常退出/注销时会话信息是否清除

由于网站程序在编写上考虑不周,用户正常退出/注销后服务端会话信息没有清除,导致用户在点击注销按钮之后还能继续访问注销之前(也就是登陆之后)才能访问的页面,或者可在退出之后通过重放登录之后的数据包查询数据。

3.3、会话超时测试

3.4、会话固定攻击

3.5、会话标识随机性测试

会话标识是用户身份的唯一标识,如果该标识被盗用、窃取、猜测则导致非授权者盗用用户身份登录系统,因此会话标识必须具备强随机性,防止非授权者猜测。

3.6、会话并发测试



四、人脸识别

4.1、 活体检测

是否可以通过分析绕过活体检测,直接通过静态方式认证。

4.2、 人脸识别数据重放

人脸识别数据中是否存在随机因子,是否可以被重放。

4.3、任意人脸数据登录

结合人脸识别数据重放问题,利用他人人脸数据是否可以登录他人账户。

 

不足之处,欢迎留言补充,谢谢!

服务热线

17884544032

公司地址

安徽省合肥市蜀山区鑫鹏大厦

作息时间

周一至周五 9:00-18:00