Improper neutralization of HTTP headers for scripting syntax

[monicavis]

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/next-js-forked-slktwp

To Reproduce

When start my application, my header is visible in the browser. This is causing the below vulnerability issue

1. Untrusted user input in response header will result in HTTP Header Injection or Response Splitting Attacks.\n
2. This application allows user-controlled URLs to be passed directly to HTTP client libraries. This can result in Server-Side Request Forgery (SSRF). SSRF refers to an attack where the attacker can abuse functionality on the server to force it to make requests to other internal systems within your infrastructure that are not directly exposed to the internet. This allows the attacker to access internal resources they do not have direct access to.\nSome risks of SSRF are:\n- Access and manipulation of internal databases, APIs, or administrative panels - Ability to scan internal network architecture and services - Can be used to pivot attacks into the internal network - Circumvent network segregation and firewall rules\nTo avoid this, try using hardcoded HTTP request calls or a whitelisting object to check whether the user input is trying to access allowed resources or not.\nHere is an example: var whitelist = [\n "https://example.com", \n "https://example.com/sample"\n]\napp.get('/ssrf/node-ssrf/axios/safe/3', function (req, res) {\n if(whitelist.includes(req.query.url)){\n axios.get(url, {})\n .then(function (response) {\n console.log(response);\n })\n .catch(function (response) {\n console.log(response); \n })\n }\n}); For more information on SSRF see OWASP: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html\n

Current vs. Expected behavior

Current behavior: vulnerability scan failed because of injection of headers in the URL

Expected behavior: Vulnerability scan should pass

Provide environment information

Operating system :Windows 11
Binaries :
Node : 20.11.1
npm : 10.2.4
Yarn : 1.22.19

Relevant packages
next : 14.2.4
eslint-config-next : 14.1.0
react :18
react-dom:18
typescript : 5

Which area(s) are affected? (Select all that apply)

Instrumentation, Output (export/standalone)

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), Other (Deployed)

Additional context

No response

[paulocf92]

I'm having this exact same behavior on semgrep-sast step of my pipeline. It warns about a fetch that I use in my next-auth's Credentials provider log-in. I use a simple email+password login to perform this fetch on an external API.

Versions are:

"next": "^14.2.5"
"next-auth": "^5.0.0-beta.15"

Relevant code:

import NextAuth from 'next-auth';
import Credentials from 'next-auth/providers/credentials';
import { authConfig } from './auth.config';
import { z } from 'zod';

import type { User } from '@/app/lib/definitions';

async function getUser(email: string, password: string): Promise<User | null> {
  const token = btoa(`${email}:${password}`);

  const response = await fetch(`${process.env.API_URL}/login`, {
    method: 'POST',
    headers: {
      Authorization: 'Basic ' + token,
      'Content-type': 'application/json',
    },
  });

  if (response.status !== 200) {
    return null;
  }

  const user = await response.json();
  const tokenizedUser: User = {
    ...user,
    authToken: response.headers.get('x-auth-token'),
  };

  return tokenizedUser;
}

export const {
  auth,
  signIn,
  signOut,
  handlers: { GET, POST },
} = NextAuth({
  ...authConfig,
  providers: [
    Credentials({
      name: 'credentials',
      credentials: {
        email: { label: 'email', type: 'text' },
        password: { label: 'password', type: 'password' },
      },
      async authorize(credentials) {
        const parsedCredentials = z
          .object({ email: z.string().email(), password: z.string().min(6) })
          .safeParse(credentials);

        if (parsedCredentials.success) {
          const { email, password } = parsedCredentials.data;

          const user = await getUser(email, password);
          if (!user) return null;

          return user;
        }

        console.log('Invalid credentials');
        return null;
      },
    }),
  ],
});

[monicavis]

I'm encountering a critical problem that continues to arise, even though a related security issue is marked as resolved. Ref link