Detecting eval() Usage

TL;DR

Attackers look for signs of eval() usage by observing application behaviour (slow responses, unusual error messages), analysing network traffic for dynamic code patterns, and scanning source code or decompiled binaries. They also use fuzzing techniques to trigger potential eval() calls.

How Attackers Suspect eval() Usage

1. Observe Application Behaviour:

• Slow Responses: eval() can introduce performance bottlenecks. If an application suddenly slows down when processing specific inputs, it could indicate dynamic code execution.
• Unusual Error Messages: Errors related to parsing or executing strings (e.g., syntax errors within dynamically generated code) might reveal the presence of eval(). Pay attention to stack traces that point to string manipulation functions before an error.
• Inconsistent Responses: If the same input produces different outputs at different times, it suggests dynamic code generation is happening.

Network Traffic Analysis:

• Dynamic Code Patterns: Look for network requests that return strings containing JavaScript or other scripting languages. Attackers will examine these responses to see if they contain potentially executable code.
• Encoded Data: eval() often receives encoded data (e.g., Base64). Observing the transfer of encoded strings can be a clue.

Source Code Review/Decompilation:

• Direct Calls to eval(): The most obvious sign is finding eval() directly used in the source code.

  if (user_input) {
    eval(user_input);
  }

• Indirect Usage via Functions: Attackers will search for functions that take strings as input and then execute them using eval() or similar methods (e.g., Function constructor).
• String Concatenation: Look for code where strings are dynamically built up, especially if user-supplied data is included in the concatenation process. This can be a precursor to eval().

  let command = "echo '" + userInput + "';";
  eval(command);

Fuzzing:

• Inputting Special Characters: Attackers will provide inputs containing characters that are likely to cause errors if not properly handled by eval() (e.g., single quotes, double quotes, backslashes).
• Injecting Code Snippets: They’ll try injecting simple JavaScript code snippets into input fields and observe the application’s response. For example:

  alert(1);

  or

  console.log('XSS');

• Testing for Error Handling: Fuzzing can reveal how the application handles errors when eval() encounters invalid code, providing clues about its presence and usage.

Web Application Firewalls (WAF) Bypass Attempts:

• Testing Common Payloads: Attackers will use payloads known to trigger eval()-based vulnerabilities in other applications, even if the current application has a WAF.
• Encoding and Obfuscation: They’ll attempt to encode or obfuscate their payloads to bypass WAF rules that detect simple eval() calls.