Okta 的 NextJS OAuth 问题
Okta's NextJS-0auth troubles

原始链接: https://joshua.hu/ai-slop-okta-nextjs-0auth-security-vulnerability

一位安全研究人员向Okta的`nextjs-auth0`项目报告了两个漏洞,包括一个关键的OAuth参数注入漏洞,可能导致账户被劫持。一个简单的补丁作为拉取请求(PR)提交,但却被Auth0的一名员工意外关闭,理由是存在一个更高优先级的PR (#2413),旨在确保提交签名。 然而,研究人员发现新的提交错误地将他们的工作归功于一个不存在的人(“Simen Olsen”),这是维护者使用AI重新整理提交造成的。此外,为此错误的道歉*也由AI生成*。尽管有要求,维护者拒绝更正提交历史,引发了对版权侵权的担忧。 研究人员还强调了报告初始漏洞的令人沮丧的经历,因为Okta要求提供漏洞利用的视频证据,才能将其确认为安全问题。截至目前,署名错误仍未更正。

## Okta 持续存在的问题与社区不满 一则 Hacker News 讨论强调了人们对 Okta 安全实践和工程质量的持续担忧。最初的帖子详细描述了一个 NextJS-OAuth 问题,与几年前 Okta 的 Go SDK 中发现的类似问题相呼应,引发了一系列批评性评论。 许多用户表达了对 Okta 一贯的负面看法,认为其工程水平业余,注重销售而非质量,并且优先考虑功能清单而非强大的安全性。 几位评论者分享了与难以联系的支持、缓慢的响应时间以及被认为使用“僵尸机器人”策略来回避问题的经历。 FusionAuth、Auth0(尽管已被 Okta 收购)、Keycloak 和 Authentik 等替代方案被提出,但实施自托管解决方案并不总是那么简单。一个反复出现的主题是对 Okta 处理贡献的不满,包括不当署名和使用人工智能生成的回应。 讨论还涉及企业不愿接受外部贡献以及外包关键身份验证服务的风险这一更广泛的问题。
相关文章

原文

In October, I reported two security issues to Okta’s auth0/nextjs-auth0 project, here and here. The latter bug, an oauth parameter injection, allows for a range of types of abuse, like scoping tokens for unintended services, setting redirect_uri and scope to arbitrary values to leak tokens, and so on.

The patch was simple enough, so I opened a PR:

diff --git a/src/server/helpers/with-page-auth-required.ts b/src/server/helpers/with-page-auth-required.ts
index 41af2dfe..f07046b8 100644
--- a/src/server/helpers/with-page-auth-required.ts
+++ b/src/server/helpers/with-page-auth-required.ts
@@ -196,7 +196,7 @@ export const appRouteHandlerFactory =
           : opts.returnTo;
       const { redirect } = await import("next/navigation.js");
       redirect(
-        `${config.loginUrl}${opts.returnTo ? `?returnTo=${returnTo}` : ""}`
+        `${config.loginUrl}${opts.returnTo ? `?returnTo=${encodeURIComponent(returnTo)}` : ""}`
       );
     }
     return handler(params);

All’s well that ends well, right? Obviously, no.


The PR, 3 weeks later, was closed by the maintainer, an auth0 (an Okta company) employee, with the following comment:

This change is superseded by #2413. This was done to ensure that commits are signed. Orignal contribution history has been preserved. Hence closing this PR now.

Hmm, let’s take a look at that PR:

Hmm. That patch looks familiar. And who is Simen Olsen?

Pushing back on the attribution error, I replied:

history has been preserved

no it hasn’t. I don’t know who “Simen A. W. Olsen [email protected]” is but it isn’t me and my commit here doesn’t reference that name or email address at all. Was it ai generated or something?

Of course, the answer was: yes. It was AI slop.

Hi @MegaManSec I sincerely apologize for this attribution error.

Can confirm that an AI workflow was used to created the rebased commit, which got confused with OP details. I’ve added a correction to #2413, and will ensure the changelog is updated.

Thank you for calling this out, we’ll make sure this doesn’t happen again.

Not only did the maintainer state the above, they also used AI to generate the response! In a now-deleted comment, they clearly used some AI to respond to my complaint:

With the classic ChatGPT “you are absolutely correct”, it’s pretty frustrating that this developer used AI to:

  1. Take my report/PR and commit it themselves.
  2. Used AI to commit it, removing my attribution.
  3. Used AI to “apologise” for using AI, then stated that “it won’t happen again” – (yeah right; please provide a detailed explanation how you’re going to ensure that, when clearly a 1-line code change is too much for your AI to handle without breaking).
  4. Refused to fix the commit to remove the invalid / AI-generated-slop details, and add back mine.

Indeed, asking:

I would appreciate force-pushing a fix for the commit to properly include my information in the commit.

I was told that they cannot change it. That seems like a copyright infringement to me: taking somebody else’s code, then changing the author’s name?

What I really find the most interesting is really how this AI slop even came to be. I cannot find any reference to the email address “[email protected]” anywhere online. On GitHub, the only reference to this email address is from the nextjs-auth0 PR. Simen Olsen has never contributed to any of the nextjs-auth0 repositories as far as I can tell (searching org:auth0 author:simenandre on GitHub), and that doesn’t even seem to be their real email address. so was this some type of ai hallucination? And why? The code change was tiny. I just totally don’t get it: I have literally never had any AI tooling fail like this and come up with some other person’s (fake) contact details. It’s simply absurd; are auth0’s engineers using some extremely (extremely) low quality local model or something? If ChatGPT failed like this for me even once every thousand times, I would simply never use it again.

In the end, at the time of writing this, the auth0/nextjs-auth0 maintainer, Tushar Pandey, who made all of these mistakes, has not fixed attribution mistake in the commit history. In addition to this, that first bug, which allows for arbitrary account hijacking in this software, has been fixed after 3 weeks, with new versions of the nextjs-auth0 software released, but Okta’s security people stating that “unless you create a video abusing this vulnerability, we aren’t going to accept this as a security issue” – LMAO; “yeah, it’s a vulnerability, we fixed in the code, it can be used to takeover accounts, but you need to create a video”. Hilarious. That’s just another case to add to my list of hilarious problems related to reporting security issue, that my next post will document.

联系我们 contact @ memedata.com