freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

等保测评2.0:应用身份鉴别(上)
2020-07-19 16:08:08

 1. 说明

本篇文章主要说一说应用测评中身份鉴别控制点的中a测评项相关内容和理解,以及一些其他的内容。
应用测评比较广泛,不类似于服务器、数据库等有个相关的参数可以去查阅,更多的需要靠访谈和自己的判断,以及需要学习的技术面非常杂。

 2. 测评项

a)应对登录的用户进行身份标识和鉴别,身份标识具有唯一性,身份鉴别信息具有复杂度要求并定期更换; 

3. 测评项要求1

应对登录的用户进行身份标识和鉴别 

等保测评2.0:Oracle的身份鉴别(下)4.5节中对具体什么是标识、鉴别等进行了介绍,有兴趣可以先去看看。

那么这里,就是要看应用是否具有标识和鉴别的功能,一般来说使用用户名进行标识,而鉴别则是使用口令。
具体表现出来就是你进入某个应用系统的管理后台,需要输入用户名以及口令,一般来说应用都是符合这个要求的。

 4. 测评项要求2

身份标识具有唯一性 

也就是用户名不能有重复的,一般来说也是符合的,保险起见你可以测试一下,创建一个重名的用户,看是否能成功。
注意:在应用系统中做的任何可能改动数据的行为,一定要征求好被测评单位配合人员的意见。

 5. 测评项要求3

身份鉴别信息具有复杂度要求 

也就是口令是否存在复杂度的限制功能以及实际的口令复杂度。

实际的口令复杂度可以让配合人员告之,而且往往要么会直接告诉你明文或者当着你的面输入口令,访谈的结果会比较可靠。
可是应用系统是否存在口令复杂度策略,访谈的结果就不那么可靠了。
要么配合人员自己也不清楚,要么就往好的方面说,误导你。

5.1. 查看配置界面

以下主要针对B/S架构的系统。

如果他清楚,就问清楚相关功能是写在代码中,还是有一个相关的配置界面,可以直接进行配置。
如果是后者,先去截图进行取证,然后尽量还是要进行一下实际的测试(有配置不一定代码功能生效,有些软件功能不全)。

5.2. 进行实际测试

如果是写在代码中,并无相关配置界面,或者他自己也不清楚,那么就需要自己动动脑筋。
登录进入系统后,找到修改个人口令的页面。
如果配合人员允许,直接修改口令进行测试,系统存在复杂度校验功能的话,如果是B/S架构的系统,大概率会直接在前端使用Js会直接阻止你提交数据),并弹出提示文字(也有少部分前端没有校验,而是后端有)。
比如:

5.3. 查看Js代码

如果配合人员不同意修改口令,或者他不在,你无法获得其同意,又不能干耗着,可以自己尝试下。
比如先看一看在你输入新口令但还未提交的时候,前端页面是否直接对口令强度做出校验,比如提示口令不得少于X位等等。
如果没有,假如是B/S系统(其实大部分遇到的都是B/S系统),那么可以用浏览器自带的元素审查功能,查看一下是否存在相关的Js代码。

火狐、谷歌等浏览器都有元素审查的功能,可以看到直接写在页面中的Js,比如这种:

如果Js代码功能没有封装在Js文件里,那是比较容易发现的,把整个页面的HTML拷贝出来,找到密码文本框的html代码,搜索其Class或者Id,一般就可以找到相关的Js代码。
如果封装在Js文件里,那你就要去浏览器的网络选项卡那把加载过的Js文件都看一看:

比如最后我发现实现“新密码长度应在6-16位字符之间,请重新输入”相关功能的代码在某个Js文件中(拷贝出来然后截的图):

从代码里可以看到,对口令的长度做出了限制:
r.newPwd.value.length<6||r.newPwd.value.length>16

对口令的组成做出了限制:
Object(f.c)(r.newPwd.value)

不过这个Object(f.c)方法是啥,从代码里没找到,这时候可以在浏览器的控制台里试一试,一般来说,如果代码规范不足够良好,为了方便互相调用,很可能这些对象是暴露在全局环境下的(不过这个实际上没有暴露在全局环境下,那是因为我打了断点,进行调试,控制台才能打出来):

暂时没看明白这代码干了啥,不过也不需要看明白,反正就是举个例子,大家明白就好。
其实一般实现口令的验证都是通过正则表达式,不会写得这么麻烦,会比较容易看懂:

还有一种Js代码也比较容易弄清楚,它是直接使用某种Js组件,这样它的口令的要求是以html的形式写在文本框的html中,然后配合相应的Js代码,结合着实现。

相对应的Js代码:

5.4. 更深入的排查

其实这一步就有点点类似于渗透了,前面说过,对于B/S架构的应用系统,基本都会在前端使用Js阻止你提交不符合标准的口令。
但是我们通过查看Js文件也好、实际测试也好,如果确实在前端被阻止了,得到的结论其实只有:前端确实做了口令复杂度校验。
后端有没有做,你是不知道的。

从逻辑上判断,如果存在口令复杂度功能配置页面,那么基本上可以判定除了前端做了校验,后端极大概率也做了。
如果不存在配置页面,那么大概率后端也做了。

如果比较闲,想要寻根究底的话,可以进一步看看后端有没有做。
基本思想就是绕过前端Js的验证,直接将数据发给后端,看看后端是否进行了阻止。

有大概两种方法:
一种是通过5.3节的思路找到对应的Js代码,用一些办法替换掉具体实现验证的那一段函数。比如有些对象直接可能直接暴露在全局环境之下了,可以尝试在控制台中将其进行替换,对其重新进行赋值,换成你自己定义的一个函数,然后直接在页面上输入用于测试的口令,提交上去。
另外一种就是不通过页面上的元素提交数据,通过观察应用系统提交数据的方式,直接构造一个数据,使用post方法向后端进行提交,这也可以直接在控制台实现,比如直接使用Jquerypost方法,如果对方页面没有应用Jquery,你也可以直接在控制台里现场引用一个。当然,你也可以自己写一个工具,不过这样你又需要模拟登录,就要麻烦一点。

5.5. 查看后台源代码

有时候对方开发人员会直接把后台源代码给你,通过查看源代码也可以基本上判断功能是否实现了,这我就不截图了,容易泄密……

5.6. 存在的高风险项

这里要特别注意下,存在弱口令以及不存在口令复杂度策略都是高风险项,而且对于直接可通过互联网系统的应用软件,还不好进行修正。

缺少口令复杂度策略:

大家注意看,基本上只有内网系统、工控设备、双因素认证这三种办法可以修,所以对于互联网系统,如果不能达到口令校验的最低要求,那就是妥妥的高风险,结论绝对就是

存在弱口令或者空口令:

这次连内网系统、双因素都不好修正了,不过我觉得双因素应该也能修才对。

这里说一说个人看法,测评项的得分和这个测评项是否属于高风险项其实没有必然关系。
有不少测评项的其实由多个要求组成,根据每个测评项具体情况的不同,可能只要满足其中任何一个要求就能够判定为部分符合
关于这个,中级教材里有很详细的论述,里面也提高了身份鉴别的a测评项:

也就是说,对于测评项a而言,只有有任何一个要求通过,就可以判定成部分符合。

但是这并不代表这测评项a就不属于高风险项了,因为这不必然代表它满足了不出现高风险的要求:是否存在弱口令、是否存在口令复杂度校验功能。
也就是说可以出现这种情况:由于应用系统的身份标识唯一(基本都可以做到),但是存在弱口令,所以测评项判定为部分符合,但是其风险判定为高风险。

 6. 测评项要求4

并定期更换

这个大概率就真的只能看访谈,或者你自己能不能找到口令有效期的配置界面了。
对口令有效期的判断,基本是在后台进行的,你也没法去查看别人的后台源代码,也没有办法进行测试。

从经验上来说,如果被测评单位购买了一些名气比较大的软件公司的产品,那可能会存在这样的功能。
如果使用的是一些流传度比较高的系统,比如XX网站管理系统什么的,一般这类系统的功能会比较全,所以应该也存在口令有效期设置功能。

至于是否实际进行了更换,一般存在这样的功能,且进行了配置,那么到了有效期不想换也得换,大概率实际也进行了口令更换(这个和windows服务器不一样,windows服务器只要你不注销用户的登录,你配置了策略也可以不换)。
另外,也可以跑去数据查看相关的数据,如果存在口令修改时间这个列的话。

 7. 总结

应用的测评涉及的东西比较多,而且实际上有不少测评项认真测的话,是需要你花不少的时间的,如果你还想彻底搞清楚,还需要对其进行渗透才有可能。
所以大家还是根据实际情况,决定测评的深度吧。

# 等级保护2.0 # 等级保护测评 # 等级保护实施
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者