Out-of-bounds read - TypeScript

Out-of-bounds read - TypeScript

Need

Prevention of out-of-bounds read vulnerabilities

Context

  • Usage of TypeScript for statically typed JavaScript development
  • Usage of Express for building web applications and APIs

Description

Non compliant code

        import express from 'express';

const app = express();

app.get('/vulnerable', (req, res) => {
  const data = ['item1', 'item2', 'item3'];
  const index = parseInt(req.query.index as string);

  const item = data[index]; // Out-of-bounds read vulnerability

  res.send(item);
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});
        
        

The vulnerability in the given code is an out-of-bounds read. This occurs when the code attempts to read data from an array using an index that is outside the valid range of indices for that array.

In the vulnerable code, the /vulnerable route is defined, which expects a query parameter named index. This parameter is then parsed as an integer using parseInt().

The code then attempts to access an item from the data array using the parsed index. However, there is no validation or check performed to ensure that the index is within the valid range of indices for the data array. This means that if an attacker provides an out-of-bounds value for the index parameter, the code will attempt to read data from a memory location outside the bounds of the data array.

This vulnerability can be exploited by an attacker to read sensitive data from the server's memory or potentially crash the server. It may also lead to information disclosure or enable further attacks on the system.

To mitigate this vulnerability, proper input validation and bounds checking should be implemented. The code should check that the index parameter is within the valid range of indices for the data array before attempting to access the item. Additionally, implementing good security practices in the software development life cycle and disabling unsafe functions can help prevent such vulnerabilities.

Steps

  • Validate the input to ensure that the index is within the bounds of the data array.
  • Check if the index is a valid number before using it to access the data array.
  • Handle the case when the index is out of bounds by sending an appropriate response to the client.
  • Consider using a safer alternative to parseInt, such as Number.parseInt or a library like validator.js to validate and parse the index parameter.

Compliant code

        import express from 'express';

const app = express();

app.get('/vulnerable', (req, res) => {
  const data = ['item1', 'item2', 'item3'];
  const index = Number.parseInt(req.query.index as string);

  if (Number.isNaN(index) || index < 0 || index >= data.length) {
    res.status(400).send('Invalid index');
    return;
  }

  const item = data[index];

  res.send(item);
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});
        
        

The fixed code addresses the vulnerability by implementing proper input validation and bounds checking. Here's an explanation of the changes made:

1. The code imports the 'express' module and creates an instance of the express application. 2. The application sets up a GET route at '/vulnerable'. 3. Inside the route handler, an array called 'data' is created with some sample items. 4. The query parameter 'index' is retrieved from the request and parsed as a string. 5. The code uses Number.parseInt() to convert the parsed value to a number. 6. The code checks if the parsed value is NaN (Not a Number) or if it is less than 0 or greater than or equal to the length of the 'data' array. 7. If any of these conditions are true, a 400 Bad Request response is sent with the message 'Invalid index', and the function returns. 8. If the index is valid, the code retrieves the item at the specified index from the 'data' array. 9. Finally, the item is sent as the response to the client.

By performing input validation and bounds checking, the fixed code ensures that only valid and safe indices are used to access the 'data' array. This prevents any out-of-bounds read vulnerabilities.

References