[Bug] NextChat cors SSRF 漏洞（CVE-2023-49785）

[006lp]

原文来自https://avd.aliyun.com/detail?id=AVD-2023-49785
漏洞描述
NextChat 是一个面向用户的GPT类应用程序，用户可以通过这个程序与GPT进行交互。2024年3月，互联网上披露CVE-2023-49785 NextChat cors SSRF 漏洞，攻击者可在无需登陆的情况下构造恶意请求造成SSRF，造成敏感信息泄漏等。

[nextchat-manager]

Please follow the issue template to update title and description of your issue.

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Title: NextChat cors SSRF vulnerability (CVE-2023-49785)

Original text from https://avd.aliyun.com/detail?id=AVD-2023-49785
Vulnerability description
NextChat is a user-oriented GPT application through which users can interact with GPT. In March 2024, the CVE-2023-49785 NextChat cors SSRF vulnerability was disclosed on the Internet. Attackers can construct malicious requests to cause SSRF without logging in, causing sensitive information to leak.

[Yidadaa]

@fred-bf @fredliang44

This bug is pretty serious. If it's a private deployment, attackers could exploit it to access server resources without permission, causing security issues.

[H0llyW00dzZ]

@fred-bf @fredliang44

This bug is pretty serious. If it's a private deployment, attackers could exploit it to access server resources without permission, causing security issues.

it easy to patch by adding validation url

[H0llyW00dzZ]

Regarding this code snippet, it has a potential Server-Side Request Forgery (SSRF) vulnerability because it doesn't have proper validation or restrictions in place.

It's crucial to implement input validation and sanitization to prevent SSRF attacks, which can lead to unauthorized access to internal systems or other security risks.

[fred-bf]

Here are few options to to alleviate this issue:

1. As @H0llyW00dzZ said to add allow list to proxy service, we can add few default built in endpoint
2. Require user to set up authentication code for accessing CORS api, this will have a greater impact on existing deployment users

[Yidadaa]

Here is a proposal to solve this issue:

1. add ENABLE_CORS to env vars, and set it to false by default;
2. add code validation just like /api/openai, if the CODE is set.

[H0llyW00dzZ]

Here are few options to to alleviate this issue:

1. As @H0llyW00dzZ said to add allow list to proxy service, we can add few default built in endpoint
2. Require user to set up authentication code for accessing CORS api, this will have a greater impact on existing deployment users

Here is a proposal to solve this issue:

1. add ENABLE_CORS to env vars, and set it to false by default;
2. add code validation just like /api/openai, if the CODE is set.

Additionally, it would be better to put the CORS host in an environment variable as well, so users can set their own host for CORS in different scenarios.

Example:

const ENABLE_CORS = process.env.ENABLE_CORS === 'true';
const CORS_HOST = process.env.CORS_HOST || 'https://yourdomain.com';

// Validate and sanitize the CODE input
const validatedCode = validateAndSanitizeCode(req.body.CODE);

// Apply CORS only if ENABLE_CORS is true
if (ENABLE_CORS) {
  res.setHeader('Access-Control-Allow-Origin', CORS_HOST);
  // Add other CORS headers if needed
}

// Use the validated code
// ...

[H0llyW00dzZ]

@Yidadaa @fred-bf u might implement it for patch cors SSRF, because I can't rn still working on this:

[fred-bf]

Here's a strategy that is likely to have the least impact:

CORS is disabled by default, and for upstash and webdav functions that rely on the CORS interface. We could implement separate interfaces and put in the /api/ path, and only endpoint parameters are accepted to avoid the problem of proxy requests

[H0llyW00dzZ]

Note

Regarding this issue,

after reading through it, it appears to lower the attack vector, and it won't significantly affect other deployments such as Vercel or Kubernetes. It seems to primarily affect cloud deployments that lack proper configuration or have misconfigured settings.

[jokester]

What is the worst thing one can do with SSRF?

Certainly this can be easily used for spamming or probing.

My worst imagination is in certain environments, attacker could grab information about the server or even issue cred as the server

[H0llyW00dzZ]

What is the worst thing one can do with SSRF?

Certainly this can be easily used for spamming or probing.

My worst imagination is in certain environments, attacker could grab information about the server or even issue cred as the server

That's why it's recommended to use containers instead of App Engine and run them in a more secure like Kubernetes (k8s). This approach can help mitigate potential risks associated with SSRF vulnerabilities.