List of security issues

1. Authentication and Authorization Issues

Hard-coded and Weak JWT Secret

The JWT secret is hard-coded and uses a weak, predictable value.

Vulnerable Code:

const JWT_SECRET = 'secret';

Impact: Attackers can easily guess or brute-force the JWT secret Possibility of token forgery, leading to unauthorized access and privilege escalation

OWASP API Security Top 10 2023 Relevance: This issue falls under API2:2023 Broken Authentication. Using a weak, hard-coded secret for JWT signing compromises the entire authentication mechanism.

How to reproduce:

• Open your web browser and navigate to http://vulnapi.testinvicti.com/api/token.
• A JWT token will be generated and displayed in the response, for example:

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoiZ3Vlc3QiLCJpYXQiOjE3MjgyODU0NjMsImV4cCI6MTcyODI4OTA2M30.Eg_BK9CJcfln5XhCemnMnyKCuuEpfADfstLrT0XBITY"}

• Go to JWT.io.
• In the "VERIFY SIGNATURE" section, enter secret as the secret key.
• Paste the JWT token you obtained into the token field.
• Confirm that the signature is verified by checking that it says Signature Verified.

Detailed Explanation: Hard-coding a weak JWT secret is a critical security flaw. JWTs are used to authenticate and authorize users, and the secret is crucial for verifying the token's integrity. A weak secret like 'secret' is easily guessable, allowing attackers to forge valid tokens and impersonate any user, including administrators. This vulnerability essentially breaks the entire authentication and authorization system.

Fixed Code:

import crypto from 'crypto';

const JWT_SECRET = crypto.randomBytes(64).toString('hex');
console.log('Use this generated secret in your secure environment:', JWT_SECRET);

Why this fixes the issue: This code generates a strong, random 64-byte (512-bit) secret key. It's then converted to a hexadecimal string, resulting in a 128-character secret. This approach:

• Ensures a unique, unpredictable secret for each deployment.
• Makes it computationally infeasible to guess or brute-force the secret.
• Follows the principle of using strong, randomly generated secrets for cryptographic operations.

The generated secret should be stored securely (e.g., in environment variables) and not in the source code.

Plaintext Password Storage

User passwords are stored in plaintext within the users array.

Vulnerable Code:

let users = [
  { id: 1, username: 'user1', email: 'user1@gmail.com', password: 'password1', isAdmin: false },
  // ...
];

Impact:

• Easy credential theft if server memory or backups are compromised
• Increased risk of account compromises across multiple platforms due to password reuse

OWASP Top 10 2021 Relevance: This issue falls under A03:2021 - Sensitive Data Exposure. Exposing sensitive information like passwords and tokens on a public page leads to data breaches and unauthorized access.

How to reproduce:

• Open the project's source code and locate the file named app.js.
• Use the search functionality (usually Ctrl+F or Cmd+F) to find the line containing "let users = [".
• Observe that user passwords are stored in plaintext within the users array, as shown:

let users = [
  { id: 1, username: 'user1', email: 'user1@gmail.com', password: 'password1', isAdmin: false },
  // ...
];

Detailed Explanation: Storing passwords in plaintext is a severe security risk. If an attacker gains access to the server's memory or database, they immediately have access to all user passwords. This not only compromises the current system but also puts users at risk on other platforms where they might reuse the same password. It violates fundamental security principles and data protection regulations.

Fixed Code:

import bcrypt from 'bcrypt';

const saltRounds = 12;

async function createUser(username, email, password, isAdmin = false) {
  const hashedPassword = await bcrypt.hash(password, saltRounds);
  const newUser = {
    id: users.length + 1,
    username,
    email,
    password: hashedPassword,
    isAdmin
  };
  users.push(newUser);
  return newUser;
}

// Usage
await createUser('user1', 'user1@gmail.com', 'password1');

// For password verification
async function verifyPassword(plainTextPassword, hashedPassword) {
  return await bcrypt.compare(plainTextPassword, hashedPassword);
}

Why this fixes the issue: This solution uses the bcrypt hashing algorithm, which is designed for password hashing and includes:

• Salt generation and hashing in one step, protecting against rainbow table attacks.
• An adjustable work factor (saltRounds) to make the hashing process computationally expensive, deterring brute-force attacks.
• A method to verify passwords without storing or exposing the original plaintext password.

This approach ensures that even if the database is compromised, the actual passwords remain protected.

Disclosure of Credentials on Home Page

The home page displays usernames, passwords, and bearer tokens in a table.

Vulnerable Code:

<table>
  <tr>
    <th>Username</th>
    <th>Password</th>
    <th>Bearer Token</th>
  </tr>
  <tr>
    <td>user1</td>
    <td>password1</td>
    <td>one</td>
  </tr>
  <!-- ... -->
</table>

Impact:

• Anyone can access valid credentials from the home page
• Potential for unauthorized access and privilege escalation

OWASP API Security Top 10 2023 Relevance: This issue falls under `API3:2023 Excessive Data Exposure. Exposing sensitive user data, including passwords, without proper authentication leads to mass data breaches.

How to reproduce:

• Open your web browser and navigate to http://vulnapi.testinvicti.com/.
• On the homepage, locate the table that displays user information.
• Verify that the table includes columns for Username, Password, and Bearer Token, showing this sensitive information for all users.

Detailed Explanation: Displaying sensitive information like passwords and bearer tokens on a publicly accessible page is a critical security breach. It allows any visitor to the site to obtain valid credentials, bypassing all authentication mechanisms. This can lead to unauthorized access, account takeovers, and potential escalation of privileges if admin credentials are exposed.

Fixed Code:

<table>
  <tr>
    <th>Username</th>
    <th>Last Login</th>
    <th>Account Status</th>
  </tr>
  <tr>
    <td>user1</td>
    <td>2023-10-01 14:30:00</td>
    <td>Active</td>
  </tr>
  <!-- ... -->
</table>

Why this fixes the issue:

• Removes all sensitive information (passwords, tokens) from the display.
• Only shows non-sensitive user information that's appropriate for a dashboard or user list.
• Includes useful but safe information like last login time and account status.

Additionally, implement proper authentication and authorization checks to ensure only authorized users can access this page:

app.get('/dashboard', authenticateToken, (req, res) => {
  // Render dashboard with non-sensitive user information
  const safeUserInfo = users.map(user => ({
    username: user.username,
    lastLogin: user.lastLogin,
    accountStatus: user.accountStatus
  }));
  res.render('dashboard', { users: safeUserInfo });
});

This ensures that sensitive data is never exposed, and only authenticated users can access the dashboard.

2. Information Leakage

Information Leakage via Detailed Error Messages

Detailed error messages, including stack traces, are sent to the client.

Vulnerable Code:

res.status(400).json({
  valid: false,
  error: 'Invalid token',
  message: error.message,
  stack: error.stack
});

Impact:

• Reconnaissance: Attackers gain insights into the application's internal workings.
• Exploitation: Detailed error messages and stack traces can help attackers identify vulnerabilities and craft specific attacks.

OWASP API Security Top 10 2023 Relevance: This issue falls under API5:2023 Security Misconfiguration. Providing overly detailed error messages constitutes a security misconfiguration, as it reveals internal system information that should remain confidential. Proper error handling should ensure that only generic error messages are exposed to end-users, while detailed logs are maintained securely for debugging purposes.

How to reproduce:

• Send the following HTTP request:

POST /api/validateToken HTTP/1.1
Host: vulnapi.testinvicti.com
Content-Type: application/json

{"token":"invalid"}

• Observe the response, which includes a detailed error message and stack trace:

{"valid":false,"error":"Invalid token","message":"jwt malformed","stack":"JsonWebTokenError: jwt malformed\n    at module.exports [as verify] (C:\\acunetix\\work\\inv-vuln-api\\node_modules\\jsonwebtoken\\verify.js:70:17)\n    at C:\\acunetix\\work\\inv-vuln-api\\app.js:411:25\n    at Layer.handle [as handle_request]
... 

Detailed Explanation: Sending detailed error messages, especially stack traces, to the client is a significant security risk. These messages can reveal sensitive information about the application's structure, libraries used, and potential vulnerabilities. Attackers can use this information to:

• Identify the technology stack and target known vulnerabilities.
• Understand the application's logic and find potential weak points.
• Craft more sophisticated attacks based on the revealed information.

Fixed Code:

// Error handling middleware
app.use((error, req, res, next) => {
  console.error('Error:', error);  // Log the full error server-side

  // Send a generic error message to the client
  res.status(error.status || 500).json({
    error: {
      message: 'An error occurred while processing your request.'
    }
  });
});

// Usage in route handlers
app.get('/api/resource', (req, res, next) => {
  try {
    // Resource handling logic
  } catch (error) {
    next(error);  // Pass the error to the error handling middleware
  }
});

Why this fixes the issue: This solution addresses the problem by:

• Logging the full error details server-side for debugging purposes.
• Sending only a generic error message to the client, preventing information leakage.
• Using a centralized error handling middleware to ensure consistent error responses.
• Allowing for different error status codes while maintaining a uniform response structure.

This approach balances the need for detailed logging for developers with the security requirement of not exposing sensitive information to potential attackers.

3. Access Control Vulnerabilities

Insecure Direct Object Reference (IDOR)

The user API endpoint allows access to any user's data without proper authorization checks.

Vulnerable Code:

app.get('/api/users/:id', authenticateToken, (req, res, next) => {
  // ...
  res.json(user);
});

Impact:

• Data Exposure: Authenticated users can access the details of any user, including sensitive information like passwords.
• Privacy Violations: Unauthorized access to personal data can lead to legal and compliance issues.

OWASP API Security Top 10 2023 Relevance: This issue falls under API1:2023 Broken Object Level Authorization. It allows authenticated users to access or modify objects that they should not have access to.

How to reproduce:

• Send the following HTTP request (we are trying to access user 1 information using a Bearer token that belongs to user 2):

GET /api/users/1 HTTP/1.1
Host: vulnapi.testinvicti.com
Authorization: Bearer two

• The response contains the information for user 1 that normally should not be accessible to user 2

{"id":1,"username":"user1","email":"user1@gmail.com","password":"password1","isAdmin":false}

• This demonstrates that user 2 can access user 1's data without proper authorization checks.

Detailed Explanation: The vulnerability here is that the endpoint only checks if the requester is authenticated, not if they have the right to access the specific user data. This means any authenticated user can access any other user's data by simply changing the :id parameter in the URL. This is a classic example of Insecure Direct Object Reference (IDOR), where the application uses user-supplied input to directly access objects without sufficient access control checks.

Fixed Code:

app.get('/api/users/:id', authenticateToken, (req, res, next) => {
  const requestedUserId = parseInt(req.params.id);
  const requestingUserId = req.user.id; // Assuming authenticateToken middleware sets req.user

  // Check if the requesting user is an admin or requesting their own data
  if (req.user.isAdmin || requestingUserId === requestedUserId) {
    const user = users.find(u => u.id === requestedUserId);
    if (user) {
      // Remove sensitive information before sending
      const { password, ...safeUserData } = user;
      res.json(safeUserData);
    } else {
      res.status(404).json({ error: 'User not found' });
    }
  } else {
    res.status(403).json({ error: 'Unauthorized access' });
  }
});

Why this fixes the issue: This solution addresses the IDOR vulnerability by:

• Verifying that the requesting user has the right to access the requested user data (either it's their own data or they're an admin).
• Implementing proper authorization checks based on the user's role and the requested resource.
• Removing sensitive information (like passwords) from the response even for authorized requests.
• Providing appropriate error messages without disclosing whether a user exists or not to unauthorized requesters.

This ensures that users can only access their own data or, in the case of admins, provides a controlled way to access other users' data, significantly reducing the risk of unauthorized data exposure.

Broken Access Control in User Update Endpoint

The user update endpoint allows modification of any user's data without proper authorization checks.

Vulnerable Code:

app.put('/api/users/:id', authenticateToken, (req, res) => {
  // ...
  Object.assign(user, req.body);
  res.json(user);
});

Impact:

• Unauthorized Modifications: Users can modify other users' data, including changing passwords or granting admin rights.
• Account Takeover: Attackers can hijack other users' accounts by changing their passwords.

OWASP API Security Top 10 2023 Relevance: This issue falls under API1:2023 Broken Object Level Authorization. It allows authenticated users to modify objects that they should not have access to, potentially escalating their privileges.

How to reproduce:

• Send the following HTTP request (we are trying to modify user 1 information using a Bearer token that belongs to user 2):

PUT /api/users/1 HTTP/1.1
Host: vulnapi.testinvicti.com
Authorization: Bearer two
Content-Type: application/json
Content-Length: 91

{"id":1,"username":"user1","email":"user1@gmail.com","password":"password1","isAdmin":true}

• The response shows that User 2 was able to modify the information of User 1. The isAdmin property was set to true.

{"id":1,"username":"user1","email":"user1@gmail.com","password":"password1","isAdmin":true}

Detailed Explanation: The vulnerability in this endpoint is twofold:

• Lack of proper authorization: It only checks if the user is authenticated, not if they have the right to modify the specific user's data.
• Mass assignment vulnerability: Using Object.assign(user, req.body) allows an attacker to modify any field of the user object, including sensitive fields like isAdmin that should not be directly modifiable.

This combination allows any authenticated user to modify any other user's data, including escalating their own privileges by setting isAdmin to true.

Fixed Code:

app.put('/api/users/:id', authenticateToken, (req, res) => {
  const requestedUserId = parseInt(req.params.id);
  const requestingUserId = req.user.id;

  // Check if the requesting user is an admin or updating their own data
  if (req.user.isAdmin || requestingUserId === requestedUserId) {
    const user = users.find(u => u.id === requestedUserId);
    if (user) {
      // Whitelist allowed fields to update
      const allowedUpdates = ['username', 'email', 'password'];
      const updates = {};
      allowedUpdates.forEach(field => {
        if (req.body[field]) {
          updates[field] = req.body[field];
        }
      });

      // Special handling for password updates
      if (updates.password) {
        updates.password = bcrypt.hashSync(updates.password, 10);
      }

      // Apply updates
      Object.assign(user, updates);

      // Remove sensitive information before sending response
      const { password, ...safeUserData } = user;
      res.json(safeUserData);
    } else {
      res.status(404).json({ error: 'User not found' });
    }
  } else {
    res.status(403).json({ error: 'Unauthorized access' });
  }
});

Why this fixes the issue: This solution addresses both vulnerabilities by:

• Implementing proper authorization checks to ensure users can only modify their own data (or any data if they're an admin).
• Using a whitelist approach to only allow updates to specific, non-sensitive fields.
• Specially handling password updates to ensure they're hashed before storage.
• Preventing mass assignment vulnerabilities by explicitly selecting which fields to update.
• Removing sensitive information from the response.

These changes ensure that users can only modify their own data (unless they're an admin) and can't escalate their privileges or modify sensitive fields, significantly improving the security of the user update process.

Missing Authorization in Order Deletion

The order deletion endpoint lacks proper authorization checks.

Vulnerable Code:

// Authorization check is commented out
// if (orders[orderIndex].userId !== req.user.userId) {
//   return res.status(403).json({ error: 'Unauthorized to delete this order' });
// }

Impact:

• Order Manipulation: Any user can delete any order, affecting business operations and data integrity.
• Denial of Service: Attackers can delete all orders, disrupting services.

OWASP API Security Top 10 2023 Relevance: This issue falls under API5:2023 Broken Function Level Authorization. Without proper authorization checks on the order deletion endpoint, unauthorized users can perform deletion operations, potentially leading to data loss or unauthorized data manipulation.

How to reproduce:

• We first identify an order that belongs to user 1:

GET /api/orders/1 HTTP/1.1
Host: vulnapi.testinvicti.com
Authorization: Bearer two

• The response confirms that order 1 belongs to the user 1

{"id":1,"userId":1,"product":"Widget","quantity":5}

• Send the following HTTP request (we are trying to delete an order that belongs to user 1 using a Bearer token that belongs to user 2):

DELETE /api/orders/1 HTTP/1.1
Host: vulnapi.testinvicti.com
Authorization: Bearer two
Content-Type: application/json

• The response shows that user 2 was able to delete an order that belongs to user 1.

{"message":"Order deleted successfully"}

Detailed Explanation: The vulnerability here is the complete lack of authorization checks for order deletion. Even if authentication is in place (assumed from the req.user reference), any authenticated user can delete any order in the system. This is a severe violation of the principle of least privilege and can lead to significant business disruption and data loss.

Fixed Code:

app.delete('/api/orders/:id', authenticateToken, (req, res) => {
  const orderId = parseInt(req.params.id);
  const orderIndex = orders.findIndex(order => order.id === orderId);

  if (orderIndex === -1) {
    return res.status(404).json({ error: 'Order not found' });
  }

  // Check if the user is authorized to delete this order
  if (orders[orderIndex].userId !== req.user.id && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Unauthorized to delete this order' });
  }

  // Perform the deletion
  const deletedOrder = orders.splice(orderIndex, 1)[0];
  
  // Log the deletion for audit purposes
  console.log(`Order ${orderId} deleted by user ${req.user.id} at ${new Date().toISOString()}`);

  res.json({ message: 'Order deleted successfully', order: deletedOrder });
});

Why this fixes the issue: This solution addresses the authorization vulnerability by:

• Implementing a proper authorization check to ensure users can only delete their own orders.
• Adding an admin check to allow administrators to delete any order if necessary.
• Providing appropriate error messages for non-existent orders and unauthorized deletion attempts.
• Logging the deletion action for audit purposes, which is crucial for tracking any potential misuse.

These changes ensure that only authorized users (order owners or admins) can delete orders, maintaining data integrity and preventing unauthorized manipulations.

4. Data Exposure

• Exposure of All Users' Data Including Passwords
• An API endpoint exposes all user data, including passwords, without authentication.

Vulnerable Code:

app.get('/api/v1/users', (req, res) => {
  res.json(users);
});

Impact:

• Mass Data Breach: All user data, including plaintext passwords, is exposed to unauthenticated users.
• Legal Consequences: Violates data protection regulations like GDPR.

OWASP API Security Top 10 2023 Relevance: This issue falls under API2:2023 Broken User Authentication. The absence of authentication on the API endpoint allows unauthorized access to sensitive user data, including passwords, thereby compromising the entire authentication mechanism.

How to reproduce:

• Send the following request (/api/v1 is an older version of the API).
• Do not include any authentication headers or tokens in the request.

GET /api/v1/users HTTP/1.1
Host: vulnapi.testinvicti.com

• Observe the response, which returns an array of all user objects, including sensitive information like passwords:

[
  {"id":1,"username":"user1","email":"user1@gmail.com","password":"password1","isAdmin":false},
...
]

• This demonstrates that the /api/v1/users endpoint exposes all user data, including plaintext passwords, without providing any authentication.

Detailed Explanation: This endpoint is critically vulnerable as it exposes all user data, including sensitive information like passwords, without any form of authentication or authorization. This is a severe violation of user privacy and data protection principles. It allows anyone with access to the API to retrieve all user information, potentially leading to account takeovers, identity theft, and other malicious activities.

Fixed Code:

app.get('/api/v1/users', authenticateToken, (req, res) => {
  if (!req.user.isAdmin) {
    return res.status(403).json({ error: 'Unauthorized access' });
  }

  // Only return necessary user information, excluding sensitive data
  const safeUserData = users.map(user => ({
    id: user.id,
    username: user.username,
    email: user.email,
    isAdmin: user.isAdmin
    // Add other non-sensitive fields as needed
  }));

  res.json(safeUserData);
});

Why this fixes the issue: This solution addresses the data exposure vulnerability by:

• Adding authentication to ensure only logged-in users can access the endpoint.
• Implementing an authorization check to restrict access to administrators only.
• Filtering the user data to exclude sensitive information like passwords.
• Returning only necessary, non-sensitive user information.

These changes ensure that sensitive user data is protected, access is restricted to authorized personnel, and the principle of least privilege is upheld. It also helps in complying with data protection regulations by limiting unnecessary data exposure.

5. Server-Side Request Forgery (SSRF)

Server-Side Request Forgery (SSRF)

An API endpoint allows arbitrary URL fetching without proper validation.

Vulnerable Code:

app.get('/api/fetch', authenticateToken, async (req, res) => {
  const response = await axios.get(req.query.url);
  res.json(response.data);
});

Impact:

• Internal Network Access: Attackers can make requests to internal services, bypassing firewalls.
• Data Exfiltration: Sensitive data from internal endpoints can be extracted.

OWASP API Security Top 10 2023 Relevance: This issue directly corresponds to API7:2023 Server Side Request Forgery. It allows an attacker to induce the server to make requests to an arbitrary destination.

How to reproduce:

• Send an HTTP GET request to the /api/fetch endpoint with the url parameter set to http://bxss.me/.

GET /api/fetch?url=http://bxss.me/ HTTP/1.1
Authorization: Bearer one
Host: vulnapi.testinvicti.com

• Examine the response to confirm that the server has fetched content from bxss.me.

"<!DOCTYPE html>\r\n<html lang=\"en\">\r\n<head>\r\n    <meta charset=\"UTF-8\">\r\n    <title>AcuMonitor</title>\r\n</head>\r\n<body>\r\n<script>window.location.replace(\"https://www.acunetix.com/vulnerability-scanner/acumonitor-technology/\");</script>\r\n</body>\r\n</html>"

Detailed Explanation: This endpoint is vulnerable to SSRF attacks because it allows a client to specify any URL to be fetched by the server. An attacker can exploit this to:

• Access internal resources that are not meant to be publicly accessible.
• Bypass firewall restrictions since the requests originate from the internal server.
• Potentially access sensitive data or trigger actions on internal systems.
• Perform port scanning or service enumeration on the internal network.

Fixed Code:

const url = require('url');
const net = require('net');

app.get('/api/fetch', authenticateToken, async (req, res) => {
  try {
    const targetUrl = new URL(req.query.url);

    // Whitelist of allowed domains
    const allowedDomains = ['api.example.com', 'public-api.trusted-domain.com'];
    
    if (!allowedDomains.includes(targetUrl.hostname)) {
      return res.status(403).json({ error: 'Access to this domain is not allowed' });
    }

    // Check if the hostname resolves to a private IP
    const ipAddress = await new Promise((resolve) => {
      net.lookup(targetUrl.hostname, (err, address) => {
        if (err) {
          resolve(null);
        } else {
          resolve(address);
        }
      });
    });

    if (ipAddress) {
      const octets = ipAddress.split('.');
      if (octets[0] === '10' || 
          (octets[0] === '172' && octets[1] >= 16 && octets[1] <= 31) || 
          (octets[0] === '192' && octets[1] === '168')) {
        return res.status(403).json({ error: 'Access to private IP addresses is not allowed' });
      }
    }

    const response = await axios.get(targetUrl.toString(), { 
      timeout: 5000,
      maxRedirects: 5
    });
    
    res.json(response.data);
  } catch (error) {
    console.error('Error fetching URL:', error);
    res.status(500).json({ error: 'An error occurred while fetching the URL' });
  }
});

Why this fixes the issue: This solution addresses the SSRF vulnerability by:

• Implementing a whitelist of allowed domains, restricting which external resources can be accessed.
• Checking if the hostname resolves to a private IP address and blocking such requests.
• Using the url module to properly parse and validate the URL.
• Setting a timeout and maximum number of redirects to prevent long-running or recursive requests.
• Implementing proper error handling to avoid leaking sensitive information in case of failures.

These measures significantly reduce the risk of SSRF attacks by limiting the scope of allowed requests and preventing access to internal resources.

6. Privilege Escalation

Unauthenticated User Creation with Privilege Escalation

The user creation endpoint allows setting admin privileges without proper checks.

Vulnerable Code:

app.post('/api/users', (req, res) => {
  const { username, password, isAdmin } = req.body;
  // ...
  const newUser = { id: users.length + 1, username, password, isAdmin: isAdmin || false };
  // ...
});

Impact:

• Admin Account Creation: Attackers can create new admin accounts by setting isAdmin to true.
• Full System Compromise: Newly created admin users can access and modify all data and settings.

OWASP API Security Top 10 2023 Relevance: This issue relates to API5:2023 Broken Function Level Authorization. It allows unauthorized elevation of privileges during user creation.

How to reproduce:

• Send an HTTP POST request to the /api/users endpoint with the isAdmin field set to true.

POST /api/users HTTP/1.1
Host: vulnapi.testinvicti.com
Content-Type: application/json
Content-Length: 93

{"username":"usertest","email":"usertest@gmail.com","password":"passwordtest","isAdmin":true}

• Check the response to verify that an admin user has been created without authentication.

{
  "id": 2,
  "username": "usertest",
  "email": "usertest@gmail.com",
  "isAdmin": true
}

• Note: The response confirms that the user usertest has admin privileges.

Detailed Explanation: This endpoint is critically vulnerable because:

• It lacks authentication, allowing anyone to create new users.
• It allows the client to specify whether the new user should have admin privileges.
• There's no validation or authorization check for setting admin status.
• This combination allows an attacker to create an admin account without any existing credentials or authorization, leading to a complete system compromise.

Fixed Code:

app.post('/api/users', authenticateToken, (req, res) => {
  // Only allow admin users to access this endpoint
  if (!req.user.isAdmin) {
    return res.status(403).json({ error: 'Unauthorized: Admin access required' });
  }

  const { username, password, email } = req.body;

  // Validate input
  if (!username || !password || !email) {
    return res.status(400).json({ error: 'Username, password, and email are required' });
  }

  // Check if username or email already exists
  if (users.some(u => u.username === username || u.email === email)) {
    return res.status(409).json({ error: 'Username or email already exists' });
  }

  // Create new user (always non-admin)
  const newUser = {
    id: users.length + 1,
    username,
    email,
    password: bcrypt.hashSync(password, 10), // Hash the password
    isAdmin: false // New users are always non-admin
  };

  users.push(newUser);

  // Log user creation
  console.log(`New user created: ${username} (ID: ${newUser.id}) by admin ${req.user.username} at ${new Date().toISOString()}`);

  // Return user data without password
  const { password: _, ...userWithoutPassword } = newUser;
  res.status(201).json(userWithoutPassword);
});

Why this fixes the issue: This solution addresses the privilege escalation vulnerability by:

• Adding authentication and authorization checks to ensure only existing admin users can create new users.
• Removing the ability to set admin status during user creation. New users are always created as non-admin.
• Implementing input validation to ensure all required fields are provided.
• Checking for existing users with the same username or email to prevent duplicates.
• Hashing the password before storing it.
• Logging user creation for audit purposes.
• Returning user data without the password for security.

These changes ensure that the user creation process is secure, traceable, and doesn't allow unauthorized privilege escalation.

7. Environment-Specific Vulnerabilities

Missing Authentication in Admin Routes on Dev Environment

Admin routes bypass authentication checks in the development environment.

Vulnerable Code:

app.get('/api/admin/users', (req, res, next) => {
  if (req.hostname === 'dev') {
    next();
  } else {
    authenticateToken(req, res, () => {
      isAdmin(req, res, next);
    });
  }
}, (req, res) => {
  res.json(users);
});

Impact:

• Unauthorized Access: Admin endpoints are accessible without authentication on the dev environment.
• Data Exposure: Sensitive admin data can be accessed by anyone.

OWASP API Security Top 10 2023 Relevance: This issue relates to API2:2023 Broken Authentication and API5:2023 Broken Function Level Authorization. It bypasses authentication and authorization checks in a specific environment.

How to reproduce:

• Send an HTTP GET request to the /api/admin/users endpoint with the Host header set to dev.

GET /api/admin/users HTTP/1.1
Host: dev

• Observe the response to confirm that admin user data is accessible without authentication.

[{"id":1,"username":"user1","email":"user1@gmail.com","password":"password1","isAdmin":false},
...
]

• Note: The response includes sensitive user information without requiring authentication.

Detailed Explanation: This code introduces a severe security vulnerability by bypassing authentication and authorization checks in the development environment. The intention might have been to facilitate easier testing, but it creates a significant security risk:

• If the development environment is accidentally exposed or if an attacker can manipulate the hostname, they gain unrestricted access to admin functionalities.
• It creates inconsistency between environments, potentially leading to security oversights when moving to production.
• Sensitive data in the development environment (which often mirrors production data) is exposed without any protection.

Fixed Code:

const isDevEnvironment = process.env.NODE_ENV === 'development';

// Middleware for development logging (if needed)
const devLogging = (req, res, next) => {
  if (isDevEnvironment) {
    console.log(`Admin route accessed: ${req.method} ${req.path}`);
  }
  next();
};

app.get('/api/admin/users', devLogging, authenticateToken, isAdmin, (req, res) => {
  // Remove sensitive information before sending
  const safeUserData = users.map(({ password, ...user }) => user);
  res.json(safeUserData);
});

// If easier access is needed in development, use a dedicated dev admin account
if (isDevEnvironment) {
  console.log('Development environment detected. Creating dev admin account.');
  const devAdminPassword = crypto.randomBytes(16).toString('hex');
  users.push({
    id: 0,
    username: 'dev_admin',
    password: bcrypt.hashSync(devAdminPassword, 10),
    isAdmin: true
  });
  console.log(`Dev admin credentials: dev_admin / ${devAdminPassword}`);
}

Why this fixes the issue: This solution addresses the environment-specific vulnerability by:

• Removing the environment-based authentication bypass, ensuring consistent security across all environments.
• Implementing proper authentication and authorization checks for all environments.
• Adding optional development logging for debugging purposes without compromising security.
• Creating a dedicated development admin account with a randomly generated password if easier access is needed in the development environment.
• Removing sensitive data (passwords) from the response.

These changes maintain security integrity across all environments while still providing the necessary tools for development and testing.

8. Sensitive Data Exposure

Exposure of Application Logs Without Authentication

An endpoint exposes application logs without proper authentication.

Vulnerable Code:

app.get('/api/admin/logs', (req, res) => {
  res.json(logs);
});

Impact:

• Information Disclosure: Logs may contain sensitive information useful for attackers.
• Security Bypass: Attackers can find vulnerabilities or misconfigurations by analyzing logs.

OWASP API Security Top 10 2023 Relevance: This issue falls under API7:2023 Security Misconfiguration. Exposing application logs without proper authentication indicates a misconfiguration that allows unauthorized access to sensitive internal information, potentially leading to information disclosure and aiding attackers in exploiting other vulnerabilities.

How to reproduce:

• Send an HTTP GET request to the /api/admin/logs endpoint without any authentication headers.

GET /api/admin/logs HTTP/1.1
Host: vulnapi.testinvicti.com

• Examine the response to verify that application logs are exposed without authentication.

[
  {"timestamp":"2023-08-29T10:00:00Z","level":"INFO","message":"Application started"},{"timestamp":"2023-08-29T10:05:23Z","level":"DEBUG","message":"User login attempt"},
...
]

• Note: The response includes sensitive log information accessible without authentication.

Detailed Explanation: This endpoint is highly vulnerable because it exposes application logs without any authentication or authorization checks. Application logs often contain sensitive information such as:

• User activities and behavior patterns
• System configuration details
• Error messages that reveal internal application structure
• Potentially personally identifiable information (PII)
• Exposing this information can aid attackers in understanding the system's inner workings, finding vulnerabilities, and planning more sophisticated attacks.

Fixed Code:

app.get('/api/admin/logs', authenticateToken, isAdmin, (req, res) => {
  try {
    // Pagination
    const page = parseInt(req.query.page) || 1;
    const limit = parseInt(req.query.limit) || 100;
    const startIndex = (page - 1) * limit;
    const endIndex = page * limit;

    // Filter sensitive information
    const sanitizedLogs = logs.map(log => ({
      timestamp: log.timestamp,
      level: log.level,
      message: log.message.replace(/(\b\d{4}\b(-?\d{4}){3})/g, '****-****-****-****') // Mask potential credit card numbers
                           .replace(/\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b/g, '[EMAIL REDACTED]') // Mask email addresses
    }));

    const paginatedLogs = sanitizedLogs.slice(startIndex, endIndex);

    res.json({
      totalLogs: sanitizedLogs.length,
      page: page,
      totalPages: Math.ceil(sanitizedLogs.length / limit),
      logs: paginatedLogs
    });
  } catch (error) {
    console.error('Error retrieving logs:', error);
    res.status(500).json({ error: 'An error occurred while retrieving logs' });
  }
});

// Implement log rotation and retention policy
const fs = require('fs');
const path = require('path');

function rotateLogsDaily() {
  const today = new Date().toISOString().split('T')[0];
  const logFile = path.join(__dirname, 'logs', `app-${today}.log`);
  
  // Implement log writing logic here
  // ...

  // Delete logs older than 30 days
  const logDir = path.join(__dirname, 'logs');
  fs.readdir(logDir, (err, files) => {
    if (err) throw err;
    const cutoffDate = new Date();
    cutoffDate.setDate(cutoffDate.getDate() - 30);

    files.forEach(file => {
      const filePath = path.join(logDir, file);
      fs.stat(filePath, (err, stats) => {
        if (err) throw err;
        if (stats.mtime < cutoffDate) {
          fs.unlink(filePath, err => {
            if (err) console.error(`Error deleting old log file ${file}:`, err);
            else console.log(`Deleted old log file: ${file}`);
          });
        }
      });
    });
  });
}

// Run log rotation daily
setInterval(rotateLogsDaily, 24 * 60 * 60 * 1000);

Why this fixes the issue: This solution addresses the sensitive data exposure vulnerability by:

• Implementing proper authentication and authorization checks to ensure only admin users can access logs.
• Adding pagination to prevent large data dumps and improve performance.
• Sanitizing log data to remove or mask sensitive information like credit card numbers and email addresses.
• Implementing error handling to prevent unintended information disclosure in case of failures.
• Adding a log rotation and retention policy to manage log files efficiently and comply with data retention regulations.

These measures significantly reduce the risk of sensitive data exposure while still providing necessary logging functionality for authorized administrators.

Sensitive Data Exposure via Metrics Endpoint

An endpoint exposes sensitive API keys and other metrics without proper authentication.

Vulnerable Code:

app.get('/api/metrics', (req, res) => {
  res.json({
    // ...
    apiKeys: {
      stripe_production: "pk_live_...",
      // ...
    },
  });
});

Impact:

• API Key Leakage: Attackers gain access to live API keys for third-party services.
• Financial Loss: Compromised payment systems can lead to fraudulent transactions.

OWASP API Security Top 10 2023 Relevance: This issue relates to API3:2023 Excessive Data Exposure. Exposing sensitive configuration data, such as API keys, without proper access controls leads to significant security risks.

How to reproduce:

• The /api/metrics endpoint is exposing API keys and other metrics without providing authentication.

• Send the following HTTP request

GET /api/metrics HTTP/1.1
Host: vulnapi.testinvicti.com

• Upon sending the request, the server responds with a JSON object containing sensitive information, including API keys. An example response is shown below:

{
...
"databaseVersion":"PostgreSQL 14.5",
"apiKeys":{"stripe_production":"pk_live_2xukkscb7yfearcm2zk1unnw",
"stripe_test":"pk_test_qrstuvwxiz67890abcdef",
"openai_api_key":"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",
"anthropic_api_key":"sk-ant-api03-AwaO6SeeIdWbZoV39HW6i4ZH7unuKidYFPrylA1L5B0ddz_9oKFGPFWkIph5j_pFDn0hGMFYanDx83j3i1YmIQ-5OKQQgAA"}
}

Detailed Explanation: This endpoint is critically vulnerable because it exposes sensitive API keys and potentially other confidential metrics without any authentication or authorization. Exposing API keys, especially production keys for payment services like Stripe, can lead to:

• Unauthorized transactions and financial fraud
• Abuse of paid services, leading to unexpected bills
• Potential data breaches in connected services
• Violation of terms of service for the API providers, potentially leading to account suspensions

Fixed Code:

const rateLimit = require("express-rate-limit");

// Create a rate limiter
const apiLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100 // limit each IP to 100 requests per windowMs
});

app.get('/api/metrics', authenticateToken, isAdmin, apiLimiter, (req, res) => {
  // Fetch real-time metrics
  const currentMetrics = {
    userCount: users.length,
    activeUsers: users.filter(u => u.lastActivity > Date.now() - 3600000).length, // active in last hour
    totalOrders: orders.length,
    revenueLastWeek: orders.filter(o => o.date > Date.now() - 7 * 24 * 3600000)
                           .reduce((sum, order) => sum + order.total, 0)
  };

  // Log access to metrics
  console.log(`Metrics accessed by admin ${req.user.username} at ${new Date().toISOString()}`);

  res.json(currentMetrics);
});

// Separate endpoint for system health check (no authentication required)
app.get('/api/health', (req, res) => {
  res.json({
    status: 'healthy',
    uptime: process.uptime(),
    timestamp: Date.now()
  });
});

Why this fixes the issue: This solution addresses the sensitive data exposure vulnerability by:

• Implementing proper authentication and authorization checks to ensure only admin users can access detailed metrics.
• Removing all sensitive data (like API keys) from the response.
• Providing only aggregated, non-sensitive metrics that are useful for monitoring but don't expose individual data.
• Adding rate limiting to prevent abuse of the metrics endpoint.
• Logging access to metrics for audit purposes.
• Creating a separate, public health check endpoint that provides basic system status without exposing sensitive information.

For handling API keys and other sensitive configuration:

• Use environment variables to store sensitive data:

const stripeKey = process.env.STRIPE_API_KEY;

• Use a secure secrets management system in production environments.
• Never include API keys or other secrets in the application code or expose them via APIs.

These changes ensure that sensitive data is protected while still providing necessary metrics and health check functionalities.

9. File System Vulnerabilities

Path Traversal in Avatar Endpoint

The avatar endpoint allows arbitrary file access through path traversal.

Vulnerable Code:

app.get('/api/avatars/:fname', (req, res) => {
  const filePath = `./uploads/${req.params.fname}`;
  // ...
  res.sendFile(filePath, options, (err) => {
    // ...
  });
});

Impact:

• Arbitrary File Access: Attackers can read any file on the server by manipulating the fname parameter.
• Sensitive Data Exposure: Configuration files, environment variables, and other sensitive files can be accessed.

OWASP Top 10 2021 Relevance: This issue falls under A01:2021 - Broken Access Control. Path traversal vulnerabilities enable attackers to bypass access controls and access unauthorized files or directories, compromising the application's integrity and confidentiality.

How to reproduce:

• Send the following HTTP request to read the source code of the the application (the file app.js).
• Note: %2e%2e%2f is the URL-encoded representation of ../, which is used to traverse directories.

GET /api/avatars/%2e%2e%2fapp.js HTTP/1.1
Host: vulnapi.testinvicti.com

• The contents of the file app.js will be returned in the response:

const express = require('express');
const path = require('path');
const jwt = require('jsonwebtoken');
const axios = require('axios');
const swaggerUi = require('swagger-ui-express');
...

Detailed Explanation: This endpoint is vulnerable to path traversal attacks because it directly uses user input to construct the file path without proper validation or sanitization. An attacker can exploit this by using ../ sequences in the fname parameter to navigate outside the intended directory. For example, a request to /api/avatars/../../../etc/passwd could potentially expose the system's password file on a Unix-based system.

Fixed Code:

const path = require('path');
const fs = require('fs').promises;
const mime = require('mime-types'); // For MIME type detection

app.get('/api/avatars/:fname', async (req, res) => {
  try {
    // Sanitize and validate the filename
    const sanitizedFilename = path.basename(req.params.fname);

    // Construct the full path, ensuring it's within the uploads directory
    const uploadDir = path.resolve(__dirname, 'uploads');
    const filePath = path.resolve(uploadDir, sanitizedFilename);

    // Ensure the file is within the upload directory
    if (!filePath.startsWith(uploadDir + path.sep)) {
      return res.status(403).json({ error: 'Access denied' });
    }

    // Check if file exists and is readable
    await fs.access(filePath, fs.constants.R_OK);

    // Get the MIME type
    const mimeType = mime.lookup(filePath);
    const allowedTypes = ['image/jpeg', 'image/png', 'image/gif'];
    if (!allowedTypes.includes(mimeType)) {
      return res.status(403).json({ error: 'Invalid file type' });
    }

    // Set proper content type
    res.type(mimeType);

    // Stream the file
    res.sendFile(filePath, (err) => {
      if (err) {
        console.error('Error sending file:', err);
        res.status(err.status || 500).end();
      }
    });
  } catch (error) {
    console.error('Error accessing avatar:', error);
    res.status(404).json({ error: 'Avatar not found' });
  }
});

Why this fixes the issue: This solution addresses the path traversal vulnerability by:

• Using path.basename() to extract only the base filename, effectively removing any directory traversal attempts.
• Constructing absolute paths with path.resolve() to prevent path manipulation.
• Validating the file path to ensure it resides within the intended uploads directory by checking that filePath starts with uploadDir + path.sep. This prevents attackers from accessing files outside the uploads directory.
• Checking file existence and read permissions using fs.access() before attempting to send the file.
• Validating the file type using the mime-types module to ensure only allowed image types are served.
• Setting the proper content type to inform the client about the nature of the file being sent.
• Simplifying res.sendFile() usage by providing the absolute path directly without unnecessary options.
• Implementing robust error handling to avoid information leakage and provide appropriate HTTP status codes.

10. SQL Injection

SQL Injection in Product Retrieval

The product retrieval endpoint is vulnerable to SQL injection.

Vulnerable Code:

app.get('/api/admin/products/:id', authenticateToken, (req, res) => {
  const query = `SELECT * FROM products WHERE id = ${req.params.id}`;
  db.get(query, (err, row) => {
    // ...
  });
});

Impact:

• Data Manipulation: Attackers can inject SQL commands to read, modify, or delete data.
• Database Compromise: Entire database tables can be dropped or altered.

OWASP API Security Top 10 2023 Relevance: This issue falls under API8:2023 Injection. SQL injection vulnerabilities allow attackers to manipulate database queries, potentially accessing or modifying sensitive data.

How to reproduce:

• Send the following HTTP request to exploit the SQL injection vulnerability.

GET /api/admin/products/-1%20union%20select%20sqlite_version(),1,1 HTTP/1.1
Authorization: Bearer one
Host: vulnapi.testinvicti.com

• This request modifies the original SQL query to: SELECT * FROM products WHERE id = -1 union select sqlite_version(),1,1.
• Here, the attacker injects a UNION statement to retrieve the SQLite database version.
• The server's response will include the SQLite version, for example:

{"id":"3.44.2","name":1,"price":1}

Detailed Explanation: This endpoint is highly vulnerable to SQL injection attacks because it directly interpolates user input into the SQL query string. An attacker can exploit this by injecting malicious SQL code into the id parameter. For example, an input like 1 OR 1=1 would return all products, while 1; DROP TABLE products;-- could delete the entire products table.

Fixed Code:

const sqlite3 = require('sqlite3').verbose();
const db = new sqlite3.Database('./database.sqlite');

app.get('/api/admin/products/:id', authenticateToken, isAdmin, (req, res) => {
  const productId = parseInt(req.params.id, 10);

  if (isNaN(productId)) {
    return res.status(400).json({ error: 'Invalid product ID' });
  }

  const query = 'SELECT * FROM products WHERE id = ?';
  
  db.get(query, [productId], (err, row) => {
    if (err) {
      console.error('Database error:', err);
      return res.status(500).json({ error: 'An error occurred while retrieving the product' });
    }
    
    if (!row) {
      return res.status(404).json({ error: 'Product not found' });
    }
    
    res.json(row);
  });
});

// Implement proper error handling for the database
db.on('error', (err) => {
  console.error('Database error:', err);
});

// Ensure the database is properly closed when the application shuts down
process.on('SIGINT', () => {
  db.close((err) => {
    if (err) {
      console.error('Error closing database:', err);
    } else {
      console.log('Database connection closed');
    }
    process.exit(err ? 1 : 0);
  });
});

Why this fixes the issue: This solution addresses the SQL injection vulnerability by:

• Using parameterized queries instead of string interpolation, which safely escapes user input.
• Parsing and validating the id parameter as an integer to ensure it's a valid product ID.
• Using the ? placeholder in the SQL query and passing the value as a separate parameter.
• Implementing proper error handling to avoid leaking sensitive information in case of database errors.
• Adding authentication and authorization checks to ensure only admin users can access this endpoint.
• Properly managing the database connection, including error handling and graceful shutdown.

These measures prevent SQL injection attacks by ensuring that user input is treated as data, not executable code, in the context of the SQL query.

11. Token Management

Use of Hard-Coded Tokens for Authentication

The application uses hard-coded tokens for authentication.

Vulnerable Code:

const tokens = {
  'one': { userId: 1, username: 'user1' },
  // ...
};

Impact:

• Token Predictability: Attackers can guess or discover tokens, leading to unauthorized access.
• Session Hijacking: Tokens are not securely generated or managed.

OWASP API Security Top 10 2023 Relevance: This issue relates to API2:2023 Broken Authentication. The use of hard-coded tokens severely undermines the security of the authentication system.

How to reproduce:

• The application accepts the following hard-coded tokens as valid Authorization Bearer headers:

• one

• two

• three

• Use one of the valid tokens to make a request to a protected endpoint. For example, using the token one:

GET /api/admin/products/1 HTTP/1.1
Authorization: Bearer one
Host: vulnapi.testinvicti.com

• The request will be accepted, and the server will return the requested product information, indicating that the authentication mechanism is vulnerable to token prediction and unauthorized access.

Detailed Explanation: Using hard-coded tokens for authentication is a critical security vulnerability because:

• Tokens are predictable and easily guessable.
• All instances of the application use the same tokens, making them a high-value target for attackers.
• Tokens cannot be easily revoked or rotated without changing the application code.
• It violates the principle of least privilege, as all tokens likely have the same level of access.
• There's no way to audit or track token usage effectively.

Fixed Code:

const crypto = require('crypto');
const jwt = require('jsonwebtoken');

// Use a strong, randomly generated secret for JWT signing
const JWT_SECRET = crypto.randomBytes(64).toString('hex');

// Store active refresh tokens (consider using Redis for distributed systems)
const activeRefreshTokens = new Set();

// User authentication function
async function authenticateUser(username, password) {
  // Implement proper password checking here (e.g., bcrypt comparison)
  const user = users.find(u => u.username === username);
  if (!user || !(await bcrypt.compare(password, user.password))) {
    return null;
  }
  return user;
}

// Token generation
function generateTokens(user) {
  const accessToken = jwt.sign(
    { userId: user.id, username: user.username },
    JWT_SECRET,
    { expiresIn: '15m' }
  );
  
  const refreshToken = crypto.randomBytes(40).toString('hex');
  activeRefreshTokens.add(refreshToken);

  return { accessToken, refreshToken };
}

// Login endpoint
app.post('/api/login', async (req, res) => {
  const { username, password } = req.body;
  const user = await authenticateUser(username, password);

  if (!user) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }

  const { accessToken, refreshToken } = generateTokens(user);

  // Set refresh token in HTTP-only cookie
  res.cookie('refreshToken', refreshToken, { 
    httpOnly: true, 
    secure: process.env.NODE_ENV === 'production', 
    sameSite: 'strict',
    maxAge: 7 * 24 * 60 * 60 * 1000 // 7 days
  });

  res.json({ accessToken });
});

// Token refresh endpoint
app.post('/api/refresh-token', (req, res) => {
  const refreshToken = req.cookies.refreshToken;

  if (!refreshToken || !activeRefreshTokens.has(refreshToken)) {
    return res.status(401).json({ error: 'Invalid refresh token' });
  }

  try {
    const user = jwt.verify(refreshToken, JWT_SECRET);
    const { accessToken, refreshToken: newRefreshToken } = generateTokens(user);

    // Invalidate old refresh token
    activeRefreshTokens.delete(refreshToken);

    // Set new refresh token in HTTP-only cookie
    res.cookie('refreshToken', newRefreshToken, { 
      httpOnly: true, 
      secure: process.env.NODE_ENV === 'production', 
      sameSite: 'strict',
      maxAge: 7 * 24 * 60 * 60 * 1000 // 7 days
    });

    res.json({ accessToken });
  } catch (error) {
    res.status(401).json({ error: 'Invalid refresh token' });
  }
});

// Logout endpoint
app.post('/api/logout', (req, res) => {
  const refreshToken = req.cookies.refreshToken;
  
  if (refreshToken) {
    activeRefreshTokens.delete(refreshToken);
  }

  res.clearCookie('refreshToken');
  res.json({ message: 'Logged out successfully' });
});

// Middleware to verify access token
function authenticateToken(req, res, next) {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];

  if (!token) {
    return res.status(401).json({ error: 'Access token required' });
  }

  jwt.verify(token, JWT_SECRET, (err, user) => {
    if (err) {
      return res.status(403).json({ error: 'Invalid or expired token' });
    }
    req.user = user;
    next();
  });
}

Why this fixes the issue: This solution addresses the token management vulnerability by:

• Implementing a proper JWT-based authentication system with short-lived access tokens and longer-lived refresh tokens.
• Using cryptographically secure random generation for tokens and secrets.
• Storing refresh tokens server-side to allow for invalidation and prevent token reuse.
• Implementing token refresh mechanism to maintain user sessions securely.
• Using HTTP-only, secure cookies for storing refresh tokens to protect against XSS attacks.
• Providing a logout mechanism that invalidates refresh tokens.
• Implementing proper error handling and token verification in middleware.

These changes significantly improve the security of the authentication system by making tokens unpredictable, short-lived, and revocable, while also providing a secure way for users to maintain longer sessions.

12. Inconsistent Authentication

Inconsistent Authentication Mechanisms

The application uses both JWT tokens and hard-coded tokens in different parts of the application.

Impact:

• Security Gaps: Inconsistent authentication can be exploited to bypass security checks.
• Confusion in Security Policy: Leads to vulnerabilities due to mismanaged authentication flows.

OWASP API Security Top 10 2023 Relevance: This issue relates to API2:2023 Broken Authentication and API7:2023 Security Misconfiguration. Inconsistent authentication mechanisms can lead to security gaps and potential vulnerabilities.

How to reproduce:

• Open the source code file app.js and look for a) const tokens = { - in this part of the code hard-coded tokens are used b) const token = jwt.sign( - in this part of the code JWT tokens are used
• Both authentication mechanisms are implemented within the application.

Detailed Explanation: Having inconsistent authentication mechanisms across an application is a significant security risk because:

• It creates confusion about which parts of the application are properly secured.
• Developers may mistakenly assume that all routes are protected by the same level of authentication.
• It increases the attack surface by potentially allowing attackers to exploit the weaker authentication method.
• Maintenance becomes more difficult, leading to potential security oversights during updates.

Fixed Code: Instead of showing specific code, here's a strategy to fix this issue:

• Standardize on a single, robust authentication mechanism (e.g., JWT as implemented in the previous section).
• Implement a centralized authentication middleware:

// authMiddleware.js
const jwt = require('jsonwebtoken');
const { JWT_SECRET } = require('./config');

function authenticateToken(req, res, next) {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];

  if (!token) {
    return res.status(401).json({ error: 'Access token required' });
  }

  jwt.verify(token, JWT_SECRET, (err, user) => {
    if (err) {
      return res.status(403).json({ error: 'Invalid or expired token' });
    }
    req.user = user;
    next();
  });
}

module.exports = { authenticateToken };

Use this middleware consistently across all protected routes:

const { authenticateToken } = require('./authMiddleware');

app.get('/api/protected-resource', authenticateToken, (req, res) => {
  // Protected route logic
});

app.post('/api/admin/action', authenticateToken, isAdmin, (req, res) => {
  // Admin-only route logic
});

Implement role-based access control (RBAC) for different levels of authorization:

function isAdmin(req, res, next) {
  if (req.user && req.user.role === 'admin') {
    next();
  } else {
    res.status(403).json({ error: 'Admin access required' });
  }
}

// Usage
app.post('/api/admin/action', authenticateToken, isAdmin, (req, res) => {
  // Admin-only action
});

• Remove all instances of the old, hard-coded token authentication system.
• Update all client-side code to use the new authentication mechanism consistently.
• Implement proper error handling and logging for authentication failures:

app.use((err, req, res, next) => {
  if (err.name === 'UnauthorizedError') {
    logger.warn(`Authentication failure: ${err.message}`);
    return res.status(401).json({ error: 'Invalid token' });
  }
  next(err);
});

Why this fixes the issue: This approach addresses the inconsistent authentication problem by:

• Standardizing on a single, secure authentication method across the entire application.
• Centralizing authentication logic, making it easier to maintain and update.
• Ensuring that all protected routes use the same authentication mechanism.
• Implementing proper role-based access control for fine-grained authorization.
• Removing outdated and insecure authentication methods.
• Improving error handling and logging for authentication-related issues.

By implementing these changes, the application's authentication becomes consistent, more secure, and easier to manage, significantly reducing the risk of authentication-related vulnerabilities.

13. Data Protection

Returning Passwords in API Responses

User objects returned by API endpoints include password fields.

Vulnerable Code:

res.json(user); // 'user' object includes the 'password' field

Impact:

• Credential Exposure: Passwords are sent over the network, potentially interceptable.
• Compliance Violations: Fails to comply with data protection best practices.

OWASP API Security Top 10 2023 Relevance: This issue falls under API3:2023 Excessive Data Exposure. Including password fields in API responses unnecessarily exposes sensitive information, increasing the risk of credential compromise.

How to reproduce:

• Send the following HTTP request:

GET /api/users/1 HTTP/1.1
Host: vulnapi.testinvicti.com
Authorization: Bearer one

• Observe the API response, which includes the user's password:

{"id":1,"username":"user1","email":"user1@gmail.com","password":"password1","isAdmin":false}

• Verify that the password field is present in the response, indicating that sensitive information is exposed.

Detailed Explanation: Returning password fields in API responses, even if they are hashed, is a severe security risk because:

• It unnecessarily exposes sensitive data that should never leave the server.
• Hashed passwords can potentially be cracked if intercepted, especially if weak hashing algorithms are used.
• It violates the principle of least privilege by providing more information than necessary.
• It may violate data protection regulations and best practices.

Fixed Code:

// User retrieval function
function getSafeUser(user) {
  const { password, ...safeUser } = user;
  return safeUser;
}

// API endpoint
app.get('/api/users/:id', authenticateToken, (req, res) => {
  const userId = parseInt(req.params.id);
  const user = users.find(u => u.id === userId);

  if (!user) {
    return res.status(404).json({ error: 'User not found' });
  }

  // Check if the requesting user has permission to view this user's data
  if (req.user.id !== userId && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Unauthorized access' });
  }

  res.json(getSafeUser(user));
});

// For bulk user retrieval
app.get('/api/users', authenticateToken, isAdmin, (req, res) => {
  const safeUsers = users.map(getSafeUser);
  res.json(safeUsers);
});

Why this fixes the issue: This solution addresses the data protection vulnerability by:

• Creating a getSafeUser function that removes the password field from user objects before sending them in API responses.
• Consistently using this function whenever user data is sent to the client.
• Implementing proper authorization checks to ensure users can only access their own data or, for admins, providing controlled access to all user data.
• Applying this pattern consistently across all endpoints that return user data.

Additional security measures:

• Implement data minimization by only returning necessary user fields based on the context of the request.
• Use HTTPS to encrypt all API communications.
• Implement proper input validation and sanitization for all user inputs.
• Regularly audit and update the list of fields considered sensitive.

These changes ensure that sensitive data like passwords are never exposed via API responses, significantly reducing the risk of credential exposure and improving compliance with data protection best practices.

14. Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) via Proxy Endpoint

The proxy endpoint returns unsanitized data in an HTML context.

Vulnerable Code:

res.send(`<div>${response.data}</div>`);

Impact:

• Client-Side Script Injection: Malicious scripts can execute in the user's browser.
• Session Hijacking: Attackers can steal cookies or perform actions on behalf of the user.

OWASP API Security Top 10 2023 Relevance: This issue falls under API8:2023 - Injection. Returning unsanitized data allows attackers to inject malicious scripts into the HTML context, leading to Cross-Site Scripting vulnerabilities.

How to reproduce:

• The output of the response from the proxy endpoint is not html encoded.
• Sending the following HTTP request:

GET /api/proxy?url=http://bxss.me/t/xss.html HTTP/1.1
Authorization: Bearer one
Host: vulnapi.testinvicti.com

• The response contains unencoded HTML code.

<div><script>prompt(98589956)</script></div>

Detailed Explanation: This endpoint is vulnerable to XSS attacks because it directly inserts unvalidated and unsanitized data into the HTML response. If the response.data contains malicious JavaScript, it will be executed in the user's browser context. This can lead to:

• Theft of sensitive information like session tokens or cookies.
• Performing unauthorized actions on behalf of the user.
• Defacement of the website or misleading the user.
• Redirecting the user to malicious websites.

Fixed Code:

const express = require('express');
const axios = require('axios');
const { JSDOM } = require('jsdom');
const createDOMPurify = require('dompurify');

const app = express();

// Create DOMPurify instance
const window = new JSDOM('').window;
const DOMPurify = createDOMPurify(window);

app.get('/api/proxy', async (req, res) => {
  try {
    const response = await axios.get(req.query.url);
    
    // Sanitize the response data
    const sanitizedData = DOMPurify.sanitize(response.data);
    
    // Set proper Content-Type header
    res.setHeader('Content-Type', 'text/html');
    
    // Send sanitized data
    res.send(`<div>${sanitizedData}</div>`);
  } catch (error) {
    console.error('Proxy error:', error);
    res.status(500).send('An error occurred while fetching the data');
  }
});

// Implement Content Security Policy
app.use((req, res, next) => {
  res.setHeader(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'"
  );
  next();
});

Why this fixes the issue: This solution addresses the XSS vulnerability by:

• Using DOMPurify to sanitize the response data, removing any potentially malicious scripts.
• Setting the proper Content-Type header to ensure the browser interprets the response correctly.
• Implementing a Content Security Policy to provide an additional layer of protection against XSS attacks.
• Properly handling errors to avoid leaking sensitive information.

Additional best practices:

• Validate and sanitize all user inputs, not just on the server-side but also on the client-side.
• Use context-sensitive escaping when inserting data into HTML, JavaScript, CSS, or URLs.
• Implement proper output encoding for different contexts (HTML, JavaScript, CSS, URL).
• Use secure flags for cookies (HttpOnly, Secure) to protect them from being accessed by scripts.
• Regularly update dependencies to patch known vulnerabilities.
• Educate developers about XSS risks and secure coding practices.

These measures significantly reduce the risk of XSS attacks by ensuring that any data returned from the API is properly sanitized before being inserted into the HTML context.

15. Denial of Service (DoS)

Potential Denial of Service (DoS) via Resource Exhaustion

An endpoint returns a large amount of data without pagination or limits.

Vulnerable Code:

app.get('/api/data', authenticateToken, (req, res) => {
  const hugeData = new Array(1500).fill('data');
  res.json(hugeData);
});

Impact:

• Resource Exhaustion: Repeated requests can consume server memory and CPU resources.
• Service Unavailability: Legitimate users may experience slow responses or timeouts.

OWASP API Security Top 10 2023 Relevance: This issue relates to API4:2023 Unrestricted Resource Consumption. It allows an attacker to exhaust server resources by making requests that return large amounts of data.

How to reproduce:

• The following Python code will exploit the Denial of Service (DoS) vulnerability by sending multiple requests in parallel trying to exhause server resources

import requests
import threading
import time

def send_request(thread_id):
    url = "http://vulnapi.testinvicti.com/api/data"
    try:
        response = requests.get(url)
        data_size = len(response.content)
        print(f"Thread {thread_id}: Received {data_size} bytes")
    except requests.RequestException as e:
        print(f"Thread {thread_id}: Error - {e}")

def main():
    num_threads = 10  # Number of concurrent threads
    num_requests_per_thread = 50  # Number of requests each thread will make
    threads = []

    start_time = time.time()

    for i in range(num_threads):
        thread = threading.Thread(target=lambda: [send_request(i) for _ in range(num_requests_per_thread)])
        threads.append(thread)
        thread.start()

    for thread in threads:
        thread.join()

    end_time = time.time()
    print(f"Total execution time: {end_time - start_time:.2f} seconds")
    print(f"Total requests sent: {num_threads * num_requests_per_thread}")

if __name__ == "__main__":
    main()

Detailed Explanation: This endpoint is vulnerable to DoS attacks because:

• It returns a large amount of data for each request without any limits.
• Repeated calls to this endpoint can quickly exhaust server memory and CPU resources.
• It doesn't implement any rate limiting or pagination, allowing an attacker to make rapid, resource-intensive requests.
• Large responses can also consume significant network bandwidth.

Fixed Code:

const express = require('express');
const rateLimit = require('express-rate-limit');

const app = express();

// Implement rate limiting
const apiLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100 // limit each IP to 100 requests per windowMs
});

app.use('/api/', apiLimiter);

// Paginated data endpoint
app.get('/api/data', authenticateToken, (req, res) => {
  const page = parseInt(req.query.page) || 1;
  const limit = parseInt(req.query.limit) || 50;
  const startIndex = (page - 1) * limit;
  const endIndex = page * limit;

  // Simulate fetching data from a database
  const allData = new Array(1500).fill().map((_, index) => ({ id: index + 1, data: `Item ${index + 1}` }));

  const paginatedData = allData.slice(startIndex, endIndex);

  const response = {
    data: paginatedData,
    currentPage: page,
    totalPages: Math.ceil(allData.length / limit),
    totalItems: allData.length
  };

  if (endIndex < allData.length) {
    response.nextPage = page + 1;
  }

  if (startIndex > 0) {
    response.previousPage = page - 1;
  }

  res.json(response);
});

// Implement request timeout
app.use((req, res, next) => {
  req.setTimeout(5000, () => {
    res.status(408).send('Request Timeout');
  });
  next();
});

Why this fixes the issue: This solution addresses the potential DoS vulnerability by:

• Implementing rate limiting to restrict the number of requests an IP can make in a given time window.
• Adding pagination to the data endpoint, allowing clients to request data in smaller, manageable chunks.
• Providing metadata about pagination (total pages, current page, etc.) to help clients navigate the data.
• Setting a request timeout to prevent long-running requests from consuming server resources indefinitely.

Additional best practices:

• Implement caching mechanisms to reduce the load on the server for frequently accessed data.
• Use database indexing and query optimization to improve the efficiency of data retrieval.
• Implement horizontal scaling and load balancing to distribute the load across multiple servers.
• Monitor server resources and implement automated alerts for unusual spikes in resource usage.
• Consider implementing more sophisticated rate limiting based on user roles or subscription levels.
• Regularly perform load testing to identify and address potential bottlenecks.

These measures significantly reduce the risk of DoS attacks by limiting resource consumption, improving response efficiency, and providing mechanisms to handle large datasets without overwhelming the server.