等保测评2.0：应用身份鉴别（上） – 作者:起于凡而非于凡

 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方法向后端进行提交，这也可以直接在控制台实现，比如直接使用Jquery的post方法，如果对方页面没有应用Jquery，你也可以直接在控制台里现场引用一个。当然，你也可以自己写一个工具，不过这样你又需要模拟登录，就要麻烦一点。

5.5. 查看后台源代码

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

5.6. 存在的高风险项

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

缺少口令复杂度策略：

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

存在弱口令或者空口令：

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

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

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

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

 6. 测评项要求4

并定期更换

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

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

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

 7. 总结

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

来源：freebuf.com 2020-07-19 16:08:08 by: 起于凡而非于凡