攻防演练中登录凭据可复用漏洞及原理分析

前段时间在攻防演练中遇到了一个登录凭据可复用漏洞。但是不清楚具体业务代码的实现逻辑，这篇文章主要对该漏洞代码层面进行分析。

1、漏洞演示（本次演示非目标网站，以本地网站演示）：

大致讲一下漏洞发现思路。

从靶标js中翻到供应链信息，再从供应链找到对应靶标的demo演示站点，通过弱口令直接登录成功，再将demo演示站点登录后的jwt，替换到靶标站点，可正常使用进入到网站后台，实现登录凭据可复用。

例：js中泄露了供应链站点信息。

找到供应链的在线demo站点，通过弱口令成功登录。

将demo站点登录后的jwt复制到靶标站点进行替换，可正常使用，成功进入到网站后台。

2、漏洞原理

首先讲讲jwt在代码层面是怎么生成的。

生成jwt需要：

1、签名算法

2、jwt过期时间

3、jwt自定义变量信息

4、jwt加密密钥

其中jwt的自定义变量信息和加密密钥是比较重要的，.setClaims()作用就是相当于设置jwt的校验参数信息。

例如：其中的empid就是代码中自定义的校验参数信息，服务器根据每个jwt的empid来判断用户的权限与信息，如果知道jwt密钥，就可以通过修改empid伪造jwt实现越权。

回到攻防演练中，登录凭据可复用漏洞，因为demo站点与靶标站点是同一套代码，.setClaims()生成jwt的自定义变量信息肯定是相同的，jwt密钥，jwt过期时间，加密算法肯定也是相同的。

那么就通过服务器的jwt解析代码的时候就可以正常解析。

ps:代码中每次生成的jwt不同是因为生成jwt的时间导致过期时间不同，只要在jwt过期时间范围内，服务器都可以正常解析使用。

如果开发者未对代码中的jwt生成逻辑进行修改，存在jwt登录凭据可复用的漏洞可能性也是相对比较大的。

这就解释了为什么可以通过demo站点jwt替换靶标站点成功进入到后台。

3、漏洞拓展

但如果是通过session，cookie进行校验登录，那么还可以实现登录凭据可绕过漏洞吗。

以生成session的代码来举例：

这段代码是当访问接口时，将属性名为"loginUser"，属性值为"tom"的属性存储到session中，再通过Java自带的安全随机数生成器来生成会话ID

每次访问这个接口生成的session都是不同的

每个用户的session只有一个且是随机不可控的。当访问后台的时候，服务器会读取session，判断和用户登录的session是否是同一个session。

Java自带的安全随机数生成器不可控，即使生成session的代码逻辑是一样的，生成出来的session也是不一样的。所以目标网站是session方式验证，就无法通过demo站点替换到靶标站点实现登录后台的操作。

原文始发于微信公众号（有恒安全）：攻防演练中登录凭据可复用漏洞及原理分析