登录（认证）常见安全问题与测试方法汇总

本篇主要介绍WEB系统登录功能会出现的一些安全问题，以及测试方法，在介绍具体方法之前我们先梳理一下一个正常登录逻辑，以方便我们更好的理解和发掘安全问题。

登录（认证）流程

认证的目的是为了认出当前用户是谁，认证过程无非就是验证凭证的过程
Step 1：用户输入登录凭证点击登录；
Step 2：前端将用户输入的登录凭证加密后发送给后端服务；
Step 3.0：后端服务解判断请求合法性（如爆破请求），如合法则将密登录凭证后与自己数据库进行对比；
Step 3.1：如凭证认证成功则创建一个临时系统凭证，也就是Sessionid，服务器保存Sessionid并将Sessionid发送给前端
Step 3.2：如凭证认证失败则将认证失败信息返回给前端
Step 4.0：前端根据后端返回信息处理后续操作流程
Step 4.1：如认证成功则将后端返回的Sessionid保存在前端（一般为本地Cookie），并携带sessionid继续后续业务请求
Step 4.1：如认证失败则提示用户重新输入凭证
明确了登录步骤后我们看下认证过程会出现的一些安全问题

常见问题汇总

弱密码

弱密码是指容易被猜测或破解的密码，因为攻击者可以很容易地猜测或破解它们，因此建议使用更强大和复杂的密码来保护账户安全。通常包含以下特征：

1. 密码长度较短，通常只有几个字符。
2. 密码包含常见或简单的字符组合，例如“123456”、“password”、“qwerty”等。
3. 密码包含常见的单词或短语，例如“love”、“money”等。
4. 密码包含简单的数字或字母组合，例如“111111”、“abcdef”等。
5. 密码包含连续的特殊字符或数字，例如“123456789”、“!@#$%^&*”等。
6. 密码使用公司或团队共用密码

严重程度

高

测试方法

1、检查系统口令的复杂度是否过于简单

修复建议

密码复杂度要求至少包含两种字符的组合，至少一个小写字母，具体要求如下：

• 长度不小于8位，小于等于20位。
• 至少包含一个大写字母。
• 至少包含一个小写字母。
• 至少包含一个数字。
• 至少包含一个特殊字符。
  出现阶段：Step 1：用户输入**登录凭证**点击登录

在GET参数中传递凭证

在传输过程，用户凭据以明文等形式被放在请求的URL中。大多数Web服务器将记录所有请求的参数和URL，因此当凭据属于URL的一部分时，它们将显示在Web服务器日志中，这样就可能会有一些隐私信息被第三方查看获取。另外，攻击者也可以通过中间人攻击等手段，截获到GET请求URL中到用户凭据，增加了敏感信息泄露的风险。

严重程度

中

测试方法

1、检查登录请求，确定URL中是否包含登录凭证信息。

如：
GET /verify?name=admin&pwd=123456

修复建议

用户凭证应放在post请求参数中加密传输
出现阶段：Step 2：前端将用户输入的登录凭证加密后发送给后端服务；

用户凭证明文传递

用户凭证明文传递通常指通过HTTP请求的参数传递敏感信息，如用户凭证（如用户名和密码）等。

严重程度

中

测试方法

1、检查登录请求参数中是否明文传递了明文的用户名与密码

如：
GET /verify?name=admin&pwd=123456

修复建议

凭证需要进行秘钥加密
出现阶段：Step 2：前端将用户输入的登录凭证加密后发送给后端服务；

口令爆破

口令爆破是指攻击者通过穷举尝试的方式猜测或破解用户口令。攻击者通过遍历生成口令或加载口令字典，进行多次登录尝试，直至猜出口令，成功登录。

严重程度

中

测试方法

1、检查多次输入错误密码后，系统是否给出恰当的防御手段

修复建议

1、当某个账号的密码错误次数开启验证码或其他限制
2、当某个ip发送大量登录请求时对IP的进行锁定，进制访问系统请求
出现阶段：Step 3：后端服务解判断请求合法性（如爆破请求），如合法则将密登录凭证后与自己数据库进行对比

用户名枚举

用户名枚举是指攻击者通过尝试常见的用户名组合来猜测或破解用户名的一种方法，其主要通过识别服务端的不同返回结果来判断用户是否存在。

严重程度

中

测试方法

1、检查后输入错误用户名后，响应信息是否可以明确识别出账户存在与否

如：
1、在填入用户名后是否发送请求，判断用户名是否存在；
2、在输入用户名密码后，响应中是存在用户用户是否存在的标识位或提示信息；

2、检查管理员类高权限账号的登录名是否为易猜测用户名

如：
使用admin、administrator、audit等常用账户名称

修复建议

1、登录失败后不要返回有过强指向性信息，如直接提示“用户名错误”或“密码错误”应为“用户名或密码错误”
出现阶段：
Step 3.1：如凭证认证成功则创建一个**临时系统凭证**，也就是Sessionid，服务器保存Sessionid并将Sessionid发送给前端
Step 3.2：如凭证认证失败则将认证失败信息返回给前端

会话标识未更新

会话标示未更新是指用户在登陆应用程序前后，其会话标识一样，未进行更新，攻击者如果预先知道了会话标识值，就能够假冒已登录的合法用户的身份，从而进行一系列非法操作。

测试方法

1、关注“登录”前后的Cookie，对其中的会话信息进行记录，在登录行为发生后，如果cookie中这个值没有发生变化，则判定为“会话标识未更新”漏洞

修复建议

用户登录成功后强制刷新会话标识
出现阶段：Step 3.1：如凭证认证成功则创建一个**临时系统凭证**，也就是Sessionid，服务器保存Sessionid并将Sessionid发送给前端

用户凭证的失效时间过长

如果失效时间设置过长，凭证可能在此期间被其他人获取或复制，从而使用户的安全性受到威胁。

严重程度

低

测试方法

1、记录登录凭证
2、不操作系统，并等待预期失效时间（12小时或其他）
3、使用步骤1的登录凭证尝试访问需要登录凭证的请求，关注是否可以正常访问
4、如果可以正常访问则存在问题

修复建议

登录凭证需要在用户体验与安全性之间进行权衡，即不要因为用户体验设置过长的失效时间，也不要因为安全性设置过短的失效时间影响用户体验
出现阶段：Step 3.1：如凭证认证成功则创建一个**临时系统凭证**，也就是Sessionid，服务器保存Sessionid并将Sessionid发送给前端

凭证中存储着敏感信息

凭证中存储着敏感信息是指将用户敏感信息存储在登录凭证中，从而导致用户敏感信息泄漏的风险。

严重程度

中

测试方法

1、检查用户凭证中是否包含诸如用户名与密码的信息

如：
Cookie:master-user=admin，master-password=admin

修复建议

登录凭证应为临时凭证，不要存储用户敏感数据，特别是用户名名密码信息
出现阶段：Step 3.1：如凭证认证成功则创建一个**临时系统凭证**，也就是Sessionid，服务器保存Sessionid并将Sessionid发送给前端

Cookie仿冒

Cookie仿冒可以使攻击者通过仿冒Cookie来冒充他人，从而进行一系列非法操作。

严重程度

高

测试方法

1、检查凭证中是否存储了身份，修改字段尝试访问需要对应用户登录才能访问的请求，如果能访问则存在问题

如
通过修改master-user的值，伪造admin用户
Cookie:master-user=admin

2、检查凭证中是否存储了权限字段，修改字段尝试访问需要对应用户登录才能访问的请求，如果能访问则存在问题

如
通过修改role的值，伪造admin用户
Cookie:role=1

修复建议

Cookie中不要明文存储易于被攻击者猜解和篡改的内容
出现阶段：Step 3.1：如凭证认证成功则创建一个**临时系统凭证**，也就是Sessionid，服务器保存Sessionid并将Sessionid发送给前端

会话 Cookie 未设置 HttpOnly 属性

HTTPONLY是HTTP协议的一个标记，用于指示浏览器或其他客户端不接受JavaScript代码访问或修改该Cookie。当在HTTP响应头中设置了HTTPONLY标志时，客户端的JavaScript无法读取或修改该Cookie，这有助于防止跨站脚本攻击（XSS）。

严重程度

低

测试方法

浏览器 F12 打开控制台，查看存储会话 Cookie，查看对应Cookie值是否设置 HttpOnly 属性。

修复建议

对于用户凭证需要开启 HttpOnly 属性
出现阶段：Step 3.1：如凭证认证成功则创建一个**临时系统凭证**，也就是Sessionid，服务器保存Sessionid并将Sessionid发送给前端

Response状态值欺骗

Response状态值欺骗是指通过篡改后端返回的特定响应值，如1，ok，success，来绕过前端限制逻辑，进入后续操作

严重程度

中

测试方法

分析服务端校验后的结果，正确和错误分别是什么样的返回结果，通过修改返回结果为正确来欺骗客前端

如
1、假设前端通过判断特定响应值ok，来判断是否可以跳转到登录后页面，而恰巧登录后页面有没有对权限信息进行校验
2、我们通过篡改登录请求对应Response中的特性响应值来欺骗前端

修复建议

所有校验逻辑需要在后端进行校验
出现阶段：Step 4.0：前端根据后端返回信息处理后续操作流程

用户登出后身份凭证未进行废弃

用户登出后，原的身份凭证（例如会话标识符或登录令牌）通常应该失效，不再继续使用，攻击者可能会尝试利用这些无效的凭证来执行未授权操作，从而威胁到用户的安全和隐私。

严重程度

中

测试方法

1、记录登出前的登录凭证；
2、用户登出
3、使用步骤1的登录凭证尝试访问需要登录凭证的请求，关注是否可以正常访问
4、如果可以正常访问则存在问题

修复建议

1、用户登出后，立即终止会话并清除相关的身份凭证
2、用户在登出后再次访问系统时，需要重新进行身份验证并生成新的身份凭证。

其他

检查核心系统或集权系统是否启用双因子认证
检查系统是否使用/console、/admin 、/system等易猜测连接作为后台管理地址。