[Bugfix] Fix CORS SSRF security issue

[fred-bf]

Fix CORS SSRF security issue reported by: #4283

• Migrate Upstash API
• Migrate WebDAV API
• Remove request to CORS api

[vercel]

@fred-bf is attempting to deploy a commit to the NextChat Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

Your build has completed!

Preview deployment

[H0llyW00dzZ]

by the way, for the webdav its difficult to filter

[fred-bf]

by the way, for the webdav its difficult to filter

My current idea is to filter requests by folder and fileName

[fred-bf]

the folder name cannot be changed by user right now

[H0llyW00dzZ]

by the way, for the webdav its difficult to filter

My current idea is to filter requests by folder and fileName

There's another approach beyond using folder/fileName.

This approach involves:

Verifying methods for requests. Then, in this one, apply it exclusively only for syncing WebDAV, Upstah, or others syncing that for implementing in future.

Ref:

• https://easy-software.com/en/glossary/webdav-protocol/

[fred-bf]

by the way, for the webdav its difficult to filter

My current idea is to filter requests by folder and fileName

There's another approach beyond using folder/fileName.

This approach involves:

Verifying methods for requests. Then, in this one, apply it exclusively only for syncing WebDAV, Upstah, or others syncing that for implementing in future.

Ref:

• https://easy-software.com/en/glossary/webdav-protocol/

Yes, it is indeed easier to maintain from a development perspective. I'm worried that the loopholes here may be overlooked in the future if we put them all together. It would be more intuitive for each specific interface to maintain the forwarding capability separately.

[H0llyW00dzZ]

by the way, for the webdav its difficult to filter

My current idea is to filter requests by folder and fileName

There's another approach beyond using folder/fileName.
This approach involves:
Verifying methods for requests. Then, in this one, apply it exclusively only for syncing WebDAV, Upstah, or others syncing that for implementing in future.
Ref:

• https://easy-software.com/en/glossary/webdav-protocol/

Yes, it is indeed easier to maintain from a development perspective. I'm worried that the loopholes here may be overlooked in the future if we put them all together. It would be more intuitive for each specific interface to maintain the forwarding capability separately.

No need to worry, it's possible to modularize it separately, like this example:

That method switch golang

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nextchat	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 13, 2024 6:22pm

[jokester]

lgtm!!!

This should make it much harder to do bad things with upstash / webdav APIs.

for app/api/cors/[...path]/route.ts I suppose some fix is still needed.

[Yidadaa]

Let's turn it into a RPC, here is a proposal:

type WebDavConfig = {
  type: 'webdav',
  endpoint: string,
  username: string,
  password: string
}

type UpstashConfig = {
  type: 'upstash',
  endpoint: string,
  username: STORAGE_KEY,
  apiKey: string
}

type SyncAction = {
  type: 'check'
} | {
  type: 'get',
  key: string,
} | {
  type: 'set',
  key: string,
  value: string
}

type SyncPayload = {
  config: WebDavConfig | UpstashConfig,
  action: SyncAction
}

// client side
function createUpstashClient() {
  return async check() {
    return await call('/api/sync', { /* webdav config */ })
  },
  // get(key), set(key, value)
}

// server side, /api/sync/route.ts
async function handle(req) {
  const payload = JSON.parse(await req.json()) as SyncPayload;

  // dispatch payload to server side check/get/set actions
}

The main idea is to move all the sync actions that were previously done on the client side to the server side. The downside is that the desktop app can no longer use the sync feature unless we keep the official sync endpoint built in.

[jokester]

move all the sync actions that were previously done on the client side to the server side

Does that mean /cors API can be removed ? Because I don't see its other uses if browser can do sync without CORS-capable storage backends.

[fred-bf]

fix: remove corsFetch

cors api already removed in commit eebc334

[fred-bf]

@Yidadaa for native client we can use tauri's http client to perform request without CORS issue. but it may take a while to refactor the code. My idea is that we release a patch version first, and then migrate the whole thing to the new interface.

[H0llyW00dzZ]

Let's turn it into a RPC, here is a proposal:

type WebDavConfig = {
  type: 'webdav',
  endpoint: string,
  username: string,
  password: string
}

type UpstashConfig = {
  type: 'upstash',
  endpoint: string,
  username: STORAGE_KEY,
  apiKey: string
}

type SyncAction = {
  type: 'check'
} | {
  type: 'get',
  key: string,
} | {
  type: 'set',
  key: string,
  value: string
}

type SyncPayload = {
  config: WebDavConfig | UpstashConfig,
  action: SyncAction
}

// client side
function createUpstashClient() {
  return async check() {
    return await call('/api/sync', { /* webdav config */ })
  },
  // get(key), set(key, value)
}

// server side, /api/sync/route.ts
async function handle(req) {
  const payload = JSON.parse(await req.json()) as SyncPayload;

  // dispatch payload to server side check/get/set actions
}

The main idea is to move all the sync actions that were previously done on the client side to the server side. The downside is that the desktop app can no longer use the sync feature unless we keep the official sync endpoint built in.

It would be better to keep the official sync that can be used in the desktop app because it is more secure and safe (essentially built-in and isolated) in the desktop environment.

[fred-bf]

Merge the current PR first, and if there is any other questions, you could comment here or file a new issue