Fix for Unchecked_Input_for_Loop_Condition reported by Checkmarx

When validating vulnerabilities reported by Checkmarx, you may run into Unchecked_Input_for_Loop_Condition. If you are unfamiliar with it, it may look mysterious. You may have an impression, that it appears in random places, but that is why I am here. I will show you what it is and how to deal with it. 

Checkmarx

Developers often remain unaware of how many times a day each website or application exposed to the internet is attacked every day. It is not getting better, but even worse. Fortunately, there are tools out there, that can help keep our software secure.

Checkmarx is a tool for detecting and managing security issues in a code. It analyzes the whole project, follows the execution flow, and detects vulnerabilities in a static code analysis (SCA) - which means - without executing it. Checmarx can report multiple types of issues. One of them is Unchecked_Input_for_Loop_Condition, which I will describe this time.

Understanding the Unchecked_Input_for_Loop_Condition vulnerability

The Unchecked_Input_for_Loop_Condition vulnerability means that input from a user or other external source is used in a loop condition somewhere in our code. Generally, it is common and natural, that a user input is somehow processed. That is why we even ask a user for input in the first place. The problem may appear, when improper or dangerous input may break or even crash our application, making it unavailable for other users.

The following Spring controller method is a good example of the vulnerability:

@RequestMapping("/process/{userInput}")
public String processInput(@PathVariable int userInput) {
  // Vulnerability: Unchecked input for loop condition
  for (int i = 0; i < userInput; i++) {
     System.out.println("Iteration " + (i + 1));
     // Perform some operations based on user input
  }
 
  return "Processing complete.";
}

userInput is passed to the method in a request URL. So the user or a bot may provide any value it wants. Actually, only integers will work, because fortunately, the method argument is declared as an integer. But it still isn't safe. You can easily imagine, that the provided value can be extremely large. In this case, userInput can be even 2 billion (a maximum value for an integer in Java). So the user may trigger 2 billion iterations just to overload our application and potentially crash it, by sending a lot of such requests. Of course, assuming that userInput is equal to 2 billion is not a normal usage of the system.

This is one of the risks. To make it clear, here are the three most important risks that may occur in the Unchecked_Input_for_Loop_Condition vulnerabilities:

1. Infinite loops. Malicious input can trigger infinite or very large loops. It may lead to abnormal consumption of system resources - Denial of Service (DoS).
2. Unexpected behavior. Unchecked input may cause unexpected behavior of the system. It gives the attackers control of the application flow.
3. Security bypass. In some cases, loop conditions may depend on the user input in such a way, that the attackers can bypass security controls and do disallowed actions in the system.

Of course, this vulnerability reported does not automatically mean that any of those risks really take place. It might be one, two, three, or none of them. It may also mean that other risks might be important. Remember that it is not a complete list of possible risks.

Mitigation strategies

SCA tools only scan code looking for potential vulnerabilities. Seeing it on a security report does not automatically mean, that our code is vulnerable. So it is important to review it and check what risks are actually there. Some possible actions that can be done to eliminate or reduce risks can be:

1. Input validation. Implement validation of all user inputs. Allow only valid values. If you expect a number within a range of 1-100, validate if it is within those boundaries before further processing.
2. Sanitization. If some characters can be dangerous for the loop conditions, remove them from the user input.
3. Type checking. Don't assume, that the value is the right type. Check it before starting the loop.

Going back to our example, the first mitigation idea is to add input validation. Probably, userInput equal to 2 billion is way too big. Checking if it is within acceptable boundaries should keep us on the safe side. See an example solution:

@RequestMapping("/process/{userInput}")
public String processInput(@PathVariable int userInput) {
  if (userInput < 0 || userInput > 100) {
     throw new IllegalArgumentException("Invalid userInput");
  }
  for (int i = 0; i < userInput; i++) {
     System.out.println("Iteration " + (i + 1));
     // Perform some operations based on user input
  }
 
  return "Processing complete.";
}

A user input outside the expected range is rejected before starting the loop.

Summary 

The Unchecked_Input_for_Loop_Condition vulnerability can come with various security risks. It is important to carefully check if our application is vulnerable and how. Knowing that we can mitigate the risks in different ways. Among others, it is important to validate user input. We cannot control everything, but at least we can check if it seems expected or not.