security - 身份服务器 4 - 使用带有 oidc-client 的授权码流+ PKCE 防止重放攻击

Question

由于我们实现的 Identity Server 4 未能阻止重放攻击，我们最近未能通过渗透测试。我已经将我们的设置的简化版本上传到 github 以演示出了什么问题。 https://github.com/adriver-kwiboo/id4-replay-attack-demo

复制步骤如下:

• 克隆 github 仓库
• 在 VS 中启动多个项目(IdentityServer + API)
• 在 VS Code 中导航到 Bebop.WebApp
• npm 安装
• npm 开始
• 获取 BurpSuite Pro 试用版:https://portswigger.net/burp/pro
• 开始一个新的临时项目
• 代理
• 选项
• 确保拦截服务器响应被勾选

• 在“拦截”选项卡上
• 点击打开浏览器
• 导航到 http://localhost:3000
• 点击登录按钮
• 在 Burpsuite 中点击“拦截已关闭”将其打开:

• 输入“alice”作为用户名和密码
• 在 Burpsuite 中，转发第一个回复
• 第二个响应应该是 302:

• 将此回复复制到记事本
• 关闭 Intercept，它会让你回到 localhost:3000
• 点击退出按钮
• 导航回 http://localhost:3000
• 点击登录按钮
• 在 Burpsuite 中打开拦截。
• 输入无效的用户名/密码
• 转发第一个回复
• 在 200 响应中，它显示无效的用户名/密码。将回复替换为您之前复制到记事本中的文本
• 关闭拦截
• 你会得到一个错误页面
• 导航到 http://localhost:3000
• 点击登录按钮
• 您会看到系统不会提示您输入用户名/密码，而是直接登录。

我的实现过程中是否遗漏了什么？或者这是身份服务器的限制？我的期望是，如果您尝试使用之前的响应登录，它会验证该响应与请求不匹配并阻止登录。

oidc-client.js 正在检查一些东西，因为它抛出了关于没有匹配状态的错误。前端是否应该通知后端失败并从 ID 服务器中删除成功的 token ？感觉它也可以被拦截并被忽略。

Answer 1

非常感谢 Brock Allen，他帮助我诊断了这一点。

基本上，我拦截和替换的响应具有设置身份验证 cookie 的 header 。

Set-Cookie: idsrv.session=XXXX; path=/; secure; samesite=none
Set-Cookie: .AspNetCore.Identity.Application=XXXX

ID 服务器使用 ASP.NET Core 的 cookie 身份验证处理程序检查 cookie 以确保它没有过期，并从中读取用户唯一 ID 的声明。这就是 IdentityServer 知道用户是谁的方式，因此它可以为他们颁发 token 。

Brock 建议我查看 ID 服务器中的配置文件服务，了解如何使用它来确认用户在第二次尝试时是否有效。