Process control vulnerabilities take two forms:

- An attacker can change the name of the program or the code of the transaction being invoked: the attacker explicitly controls what the program name or transaction code is.

- An attacker can change the environment in which the program or the transaction is invoked: the attacker implicitly controls a communication area made available to the invoked program or the transaction.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the program or the code of the transaction that is invoked. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as or as part of a string representing a program name or a transaction code that is invoked.



3. By executing code from the invoked program or the transaction, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code excerpt from a privileged system utility reads a value from an HTTP request to determine the code of the transaction to call.

...
tid = request->get_form_field( 'tid' ).

CALL TRANSACTION tid USING bdcdata  MODE 'N'
                         MESSAGES INTO messtab.
...

This code excerpt allows an attacker to call any transaction and potentially execute arbitrary code with the elevated privilege of the application. Because the program does not validate the value read from the HTTP request, if an attacker can control this value, then they can fool the application into running malicious code and take control of the system.

Process control vulnerabilities take two forms:

- An attacker can change the name of the library or executable that the program loads: the attacker explicitly controls what the name of the library or executable is.

- An attacker can change the environment in which the library or executable loads: the attacker implicitly controls what the library or executable name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as or as part of a string representing a library or an executable that is loaded by the application.



3. By executing code from the library or executable, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged system utility uses the application configuration property APPHOME and then loads a native library based on a relative path from the specified directory.

  ...
  string lib = ConfigurationManager.AppSettings["APPHOME"];
  Environment.ExitCode = AppDomain.CurrentDomain.ExecuteAssembly(lib);
  ...

This code allows an attacker to load a library or an executable and potentially execute arbitrary code with the elevated privilege of the application by modifying the application configuration property APPHOME to point to a different path containing a malicious version of LIBNAME. Because the program does not validate the value read from the environment, if attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Process control vulnerabilities take two forms:

- An attacker can change the library that the program executes: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as part of a string representing a library name that is loaded by the application.

3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged application uses a registry entry to determine the directory in which it is installed and loads a library file based on a relative path from the specified directory.

	...
	RegQueryValueEx(hkey, "APPHOME",
                      0, 0, (BYTE*)home, &size);
	char* lib=(char*)malloc(strlen(home)+strlen(INITLIB));
	if (lib) {
		strcpy(lib,home);
		strcat(lib,INITCMD);
		LoadLibrary(lib);
	}
	...

The code in this example allows an attacker to load an arbitrary library, from which code will be executed with the elevated privilege of the application, by modifying a registry key to specify a different path containing a malicious version of INITLIB. Because the program does not validate the value read from the environment, if an attacker can control the value of APPHOME, they can fool the application into running malicious code.

Example 2: The following code is from a web-based administration utility that allows users access to an interface through which they can update their profile on the system. The utility uses a library named liberty.dll, which is intended to be found in a standard system directory.

LoadLibrary("liberty.dll");

However, the program does not specify an absolute path for liberty.dll. If an attacker places a malicious library named liberty.dll higher in the search order than the intended file and has a way to execute the program in their environment rather than the web server's environment, then the application will load the malicious library instead of the trusted one. Because this type of application runs with elevated privileges, the contents of the attacker's liberty.dll is now be run with elevated privileges, potentially giving them complete control of the system.

This type of attack is possible due to the search order used by LoadLibrary() when an absolute path is not specified. If the current directory is searched before system directories, as was the case up until the most recent versions of Windows, then this type of attack becomes trivial if the attacker may execute the program locally. The search order is operating system version dependent, and is controlled on newer operating systems by the value of this registry key:

HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode

This key is not defined on Windows 2000/NT and Windows Me/98/95 systems.

On systems where the key does exist, LoadLibrary() behaves as follows:
If SafeDllSearchMode is 1, the search order is as follows:
(Default setting for Windows XP-SP1 and later, as well as Windows Server 2003.)
1. The directory from which the application was loaded.
2. The system directory.
3. The 16-bit system directory, if it exists.
4. The Windows directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable.
If SafeDllSearchMode is 0, the search order is as follows:
1. The directory from which the application was loaded.
2. The current directory.
3. The system directory.
4. The 16-bit system directory, if it exists.
5. The Windows directory.
6. The directories that are listed in the PATH environment variable.

Process control vulnerabilities take two forms:

- An attacker can change the name of the program being invoked: the attacker explicitly controls what the name of the application program is.

- An attacker can change the environment in which the program is invoked: the attacker implicitly controls a communication area made available to the invoked program.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker might control the name of the program that is invoked. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as part of, or the entire string representing a program that is invoked or determines some control over the environment in which the program is invoked.



3. By executing code from the invoked program, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged system utility reads a value from the terminal to determine the name of the program to transfer control to.

...
ACCEPT PROGNAME.
EXEC CICS
  LINK PROGRAM(PROGNAME)
  COMMAREA(COMA)
  LENGTH(LENA)
  DATALENGTH(LENI)
  SYSID('CONX')
END-EXEC.
...

This code allows an attacker to transfer control to a program and potentially execute arbitrary code with the elevated privilege of the application. Because the program does not validate the value read from the terminal, if an attacker can control this value, then they can fool the application into running malicious code and take control of the system.

Process control vulnerabilities take two forms:

- An attacker can change the name of the library that the program loads: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as or as part of a string representing a library that is loaded by the application.



3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code uses a currently undocumented "feature" of Express to dynamically load a library file. Node.js will then continue to search through its regular library load path for a file or directory containing this library[1].

var express = require('express');
var app = express();

app.get('/', function(req, res, next) {
  res.render('tutorial/' + req.params.page);
});

In Express, the page passed to Response.render() will load a library of the extension when previously unknown. This is usually fine for input such as "foo.pug", as this will mean loading the pug library, a well known templating engine. However, if an attacker can control the page and thus the extension, then they can choose to load any library within the Node.js module loading paths. Since the program does not validate the information received from the URL parameter, the attacker may fool the application into running malicious code and take control of the system.

Process control vulnerabilities take two forms:

- An attacker can change the name of the library that the program loads: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as or as part of a string representing a library that is loaded by the application.



3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged system utility uses the system property APPHOME to determine the directory in which it is installed and then loads a native library based on a relative path from the specified directory.

	...
	$home = getenv("APPHOME");
	$lib = $home + $LIBNAME;
	dl($lib);
	...

This code allows an attacker to load a library and potentially execute arbitrary code with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of LIBNAME. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code uses dl() to load code from a library named sockets.dll, which can be loaded from various places depending on your installation and configuration.

	...
	dl("sockets");
	...

The problem here is that dl() accepts a library name, not a path, for the library to be loaded.

If an attacker is able to place a malicious copy of sockets.dll higher in the search order than file the application intends to load, then the application will load the malicious copy instead of the intended file. Because of the nature of the application, it runs with elevated privileges, which means the contents of the attacker's sockets.dll will now be run with elevated privileges, possibly giving them complete control of the system.

Within Ruby, Process Control can commonly occur when a command is being executed, which enables two different attacks:

1. Process Control
Process Control vulnerabilities take two forms:

- An attacker can change the name of the library that the program loads: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the second scenario, the possibility that an attacker may be able to control the environment in such a way that the program loads a malicious version of the named library.

1. An attacker provides a malicious library to an application.

2. The application loads the malicious library because it fails to specify an absolute path or verify the file being loaded.

3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Note that Process Control can occur on Windows platforms when running an external program as the shell used to run the commands is chosen via the environment variables RUBYSHELL or COMSPEC. If an attacker is able to modify either of these environment variables within the current environment, it means that the program pointed by these environment variables will be run with the permission or the running Ruby program.

2. Command Injection
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the second scenario, the possibility that an attacker may be able to change the meaning of the command by changing an environment variable or by putting a malicious executable early in the search path. Command injection vulnerabilities of this type occur when:

1. An attacker modifies an application's environment.

2. The application executes a command without specifying an absolute path or verifying the binary being executed.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code runs Kernel.system() to run an executable called program.exe, which is normally found within a standard system directory.

...
system("program.exe")
...

The problem here is twofold:
1. On Windows platforms, Kernel.system() executes something via a shell. If an attacker can manipulate environment variables RUBYSHELL or COMSPEC, they may be able to point to a malicious executable which will be called with the command given to Kernel.system(). Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's program.exe will now be run with these privileges, possibly giving them complete control of the system.
2. On all platforms in this scenario, the problem is that the program does not specify an absolute path and fails to clean its environment prior to executing the call to Kernel.system(). If an attacker can modify the $PATH variable to point to a malicious binary called program.exe and then execute the application in their environment, the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's program.exe will now be run with these privileges, possibly giving them complete control of the system.

In AI applications, system prompts provide pre-processing instructions or context that guide the AI responses. Attackers can craft inputs that, when embedded as system prompts, alter the behavior of the AI model to execute unauthorized operations or disclose sensitive information.

Example 1: The following code illustrates a system prompt injection to the Anthropic AI model:

client = new Anthropic();

# Simulated attacker's input attempting to inject a malicious system prompt
attacker_input = ...

response = client.messages.create(
    model = "claude-3-5-sonnet-20240620",
    max_tokens=2048,
    system = attacker_input,
    messages = [
        {"role": "user", "content": "Analyze this dataset for anomalies: ..."}
    ]
);
...

In this example, the attacker manipulates unvalidated input to a system prompt, which can lead to a security breach.

In AI applications, system prompts provide pre-processing instructions or context that guide the AI responses. Attackers can craft inputs that, when embedded as system prompts, alter the behavior of the AI model to execute unauthorized operations or disclose sensitive information.

Example 1: The following Python code illustrates a system prompt injection to the OpenAI AI model:

  client = OpenAI()

  # Simulated attacker's input attempting to inject a malicious system prompt
  attacker_input = ...

  completion = client.chat.completions.create(
      model="gpt-3.5-turbo",
      messages=[
          {"role": "system", "content": attacker_input},
          {"role": "user", "content": "Compose a poem that explains the concept of recursion in programming."}
      ]
  )

In this example, the attacker manipulates unvalidated input to a system prompt, which can lead to a security breach.

In AI applications, system prompts provide pre-processing instructions or context that guide the AI responses. Attackers can craft inputs that, when embedded as system prompts, alter the behavior of the AI model to execute unauthorized operations or disclose sensitive information. In the case of persistent prompt injection this untrusted input typically comes from database or a back-end data store as opposed to a web request.

Example 1: The following code illustrates a system prompt injection to the Anthropic AI model:

client = new Anthropic();

# Simulated attacker's input attempting to inject a malicious system prompt
attacker_query = ...;
attacker_name = db.qyery('SELECT name FROM user_profiles WHERE ...');

response = client.messages.create(
    model = "claude-3-5-sonnet-20240620",
    max_tokens=2048,
    system = "Provide assistance to the user " + attacker_name,
    messages = [
        {"role": "user", "content": attacker_query}
    ]
);
...

In this example, the attacker manipulates unvalidated input to a system prompt, which can lead to a security breach.

In AI applications, system prompts provide pre-processing instructions or context that guide the AI responses. Attackers can craft inputs that, when embedded as system prompts, alter the behavior of the AI model to execute unauthorized operations or disclose sensitive information. In the case of persistent prompt injection this untrusted input typically comes from database or a back-end data store as opposed to a web request.

Example 1: The following Python code illustrates a system prompt injection to the OpenAI AI model:

  client = OpenAI()

  # Simulated attacker's input attempting to inject a malicious system prompt
  attacker_name = cursor.fetchone()['name']
  attacker_query = ...

  completion = client.chat.completions.create(
      model="gpt-3.5-turbo",
      messages=[
          {"role": "system", "content": "Provide assistance to the user " + attacker_name},
          {"role": "user", "content": attacker_query}
      ]
  )

In this example, the attacker manipulates unvalidated input to a system prompt, which can lead to a security breach.

Null-pointer exceptions usually occur when one or more of the programmer's assumptions is violated. There are at least three flavors of this problem: check-after-dereference, dereference-after-check, and dereference-after-store. A check-after-dereference error occurs when a program dereferences a pointer that can be null before checking if the pointer is null. Dereference-after-check errors occur when a program makes an explicit check for null, but proceeds to dereference the pointer when it is known to be null. Errors of this type are often the result of a typo or programmer oversight. A dereference-after-store error occurs when a program explicitly sets a pointer to null and dereferences it later. This error is often the result of a programmer initializing a variable to null when it is declared.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker might be able to use the resulting exception to bypass security logic in order to mount a denial of service attack, or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example 1: In the following code, the programmer confirms that the object foo is null and subsequently dereferences it erroneously. If foo is null when it is checked in the if statement, then a null dereference occurs, which causes a null-pointer exception.

if (foo is null) {
	foo.SetBar(val);
	...
}

Example 2: In the following code, the programmer assumes that the variable foo is not null and confirms this assumption by dereferencing the object. However, the programmer later contradicts the assumption by checking foo against null. If foo can be null when it is checked in the if statement then it can also be null when it is dereferenced and might cause a null-pointer exception. Either the dereference is unsafe or the subsequent check is unnecessary.

foo.SetBar(val);
...
if (foo is not null) {
	...
}

Example 3: In the following code, the programmer explicitly sets the variable foo to null. Later, the programmer dereferences foo before checking the object for a null value.

Foo foo = null;
...
foo.SetBar(val);
...
}

Null-pointer exceptions usually occur when one or more of the programmer's assumptions is violated. There are at least three flavors of this problem: check-after-dereference, dereference-after-check, and dereference-after-store. A check-after-dereference error occurs when a program dereferences a pointer that can be null before checking if the pointer is null. Dereference-after-check errors occur when a program makes an explicit check for null, but proceeds to dereference the pointer when it is known to be null. Errors of this type are often the result of a typo or programmer oversight. A dereference-after-store error occurs when a program explicitly sets a pointer to null and dereferences it later. This error is often the result of a programmer initializing a variable to null when it is declared.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker may be able to use the resulting exception to bypass security logic in order to mount a denial of service attack, or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example 1: In the following code, the programmer assumes that the variable ptr is not NULL. That assumption is made explicit when the programmer dereferences the pointer. This assumption is later contradicted when the programmer checks ptr against NULL. If ptr can be NULL when it is checked in the if statement then it can also be NULL when it dereferenced and may cause a segmentation fault.

ptr->field = val;
...
if (ptr != NULL) {
        ...
}

Example 2: In the following code, the programmer confirms that the variable ptr is NULL and subsequently dereferences it erroneously. If ptr is NULL when it is checked in the if statement, then a null dereference will occur, thereby causing a segmentation fault.

if (ptr == null) {
        ptr->field = val;
        ...
}

Example 3: In the following code, the programmer forgets that the string '\0' is actually 0 or NULL, thereby dereferencing a null-pointer and causing a segmentation fault.

if (ptr == '\0') {
        *ptr = val;
        ...
}

Example 4: In the following code, the programmer explicitly sets the variable ptr to NULL. Later, the programmer dereferences ptr before checking the object for a null value.

*ptr = NULL;
...
ptr->field = val;
...
}

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a host name read from an HTTP request to create an FTP connection.

...
host_name = request->get_form_field( 'host' ).
CALL FUNCTION 'FTP_CONNECT'
     EXPORTING
       USER            = user
       PASSWORD        = password
       HOST            = host_name
       RFC_DESTINATION = 'SAPFTP'
     IMPORTING
       HANDLE          = mi_handle
     EXCEPTIONS
       NOT_CONNECTED   = 1
       OTHERS          = 2.
...

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.

Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a port number read from an HTTP request to create a socket.

int rPort = Int32.Parse(Request.Item("rPort"));
...
IPEndPoint endpoint = new IPEndPoint(address,rPort);
socket = new Socket(endpoint.AddressFamily,
                    SocketType.Stream, ProtocolType.Tcp);
socket.Connect(endpoint);
...

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.

Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a port number read from a CGI request to create a socket.

...
char* rPort = getenv("rPort");
...
serv_addr.sin_port = htons(atoi(rPort));
if (connect(sockfd,&serv_addr,sizeof(serv_addr)) < 0)
error("ERROR connecting");
...

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker might specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses the value read from the terminal to access a record from the CICS queue of that name.

...
ACCEPT QNAME.
EXEC CICS
  READQ TD
  QUEUE(QNAME)
  INTO(DATA)
  LENGTH(LDATA)
END-EXEC. 
...

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify part of the name of a file to be opened or a port number to be used.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program might give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker.

Example 1: The following ColdFusion code creates a Java ServerSocket object and uses a port number read from an HTTP request to create a socket.

<cfobject action="create" type="java" class="java.net.ServerSocket" name="myObj">
<cfset srvr = myObj.init(#url.port#)>
<cfset socket = srvr.accept()>

Passing user input to objects imported from other languages can be very dangerous.

A resource injection issue occurs when the following two conditions are met:

1. An attacker can specify the identifier used to access a system resource.

For example, an attacker might be able to specify a port number and use it to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program might give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for additional details of this vulnerability.

Example 1: The following code uses a port number read from an HTTP request to create a socket.

  final server = await HttpServer.bind('localhost', 18081);
  server.listen((request) async {
    final remotePort = headers.value('port');
    final serverSocket = await ServerSocket.bind(host, remotePort as int);
    final httpServer = HttpServer.listenOn(serverSocket);
  });
...

Some think that in the mobile world, classic web application vulnerabilities, such as resource injection, do not make sense -- why would users attack themselves? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a device name read from a HTTP request to connect to bind the socket associated with fd to the device.

    func someHandler(w http.ResponseWriter, r *http.Request){
        r.parseForm()
        deviceName := r.FormValue("device")
        ...
        syscall.BindToDevice(fd, deviceName)
    }

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a URL read from an HTTP request to create a socket.

  var socket = new WebSocket(document.URL.indexOf("url=")+20);

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource or source location for input files.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third party server.

Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a host read from a request:

...
char* rHost = getenv("host");
...
CFReadStreamRef readStream;
CFWriteStreamRef writeStream;
CFStreamCreatePairWithSocketToHost(NULL, (CFStringRef)rHost, 80, &readStream, &writeStream);
...

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a hostname read from an HTTP request to connect to a database, which determines the price for a ticket.

<?php
    $host=$_GET['host'];
    $dbconn = pg_connect("host=$host port=1234 dbname=ticketdb");
...
    $result = pg_prepare($dbconn, "my_query", 'SELECT * FROM pricelist WHERE name = $1');
    $result = pg_execute($dbconn, "my_query", array("ticket"));
?>

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker may specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.

Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses a CGI environment variable as a URL of a document to be downloaded.

...
filename := SUBSTR(OWA_UTIL.get_cgi_env('PATH_INFO'), 2);
WPG_DOCLOAD.download_file(filename);
...

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in functions that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a hostname read from an HTTP request to connect to a database, which determines the price for a ticket.

host=request.GET['host']
dbconn = db.connect(host=host, port=1234, dbname=ticketdb)
c = dbconn.cursor()
...
result = c.execute('SELECT * FROM pricelist')
...

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a string read from an HTTP request as the key to cache the logged-in user data.

def controllerMethod = Action { request =>
    val result = request.getQueryString("key").map { key =>
        val user = db.getUser() 
        cache.set(key, user)
        Ok("Cached Request") 
    }
    Ok("Done") 
}

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource or source location for input files.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third party server.

Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a host read from a request:

...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    var inputStream : NSInputStream?
    var outputStream : NSOutputStream?
    ...
    var readStream : Unmanaged<CFReadStream>?
    var writeStream : Unmanaged<CFWriteStream>?
    let rHost = getQueryStringParameter(url.absoluteString, "host")
    CFStreamCreatePairWithSocketToHost(kCFAllocatorDefault, rHost, 80, &readStream, &writeStream);
    ...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
    if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
        return queryItems.filter({ (item) in item.name == param }).first?.value!
    }
    return nil
}
...

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a port number read from an HTTP request to create a socket.

...
	Begin MSWinsockLib.Winsock tcpServer
...
Dim Response As Response
Dim Request As Request
Dim Session As Session
Dim Application As Application
Dim Server As Server
Dim Port As Variant
Set Response = objContext("Response")
Set Request = objContext("Request")
Set Session = objContext("Session")
Set Application = objContext("Application")
Set Server = objContext("Server")
Set Port = Request.Form("port")
...
tcpServer.LocalPort = Port
tcpServer.Accept
...

The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.

The application uses a parameter under the attacker's control as the name of a JavaScript function that the browser will execute. An attacker may create a malicious site which first frames a target page on the same application's domain and then references the vulnerable page in order to execute an arbitrary JavaScript function on the target page. The impact of this attack is similar to the impact of Cross-Site Scripting, though there are some important exploitation restrictions. If alphanumeric and dot characters are allowed to be used as the callback name, the attacker will be able to reference and interact with the elements of the page.

Example 1: The following code constructs a JSONP response where the callback function name can be controlled by the user.

  def myJSONPService(callback: String) = Action {
    val json = getJSONToBeReturned()
    Ok(Jsonp(callback, json))
  }

For a request such as GET /api/latest.json?callback=myCallbackFunction, the controller method described in Example 1 will generate a response such as:

HTTP/1.1 200 Ok 
Content-Type: application/json; charset=utf-8
Date: Tue, 12 Dec 2017 16:16:04 GMT
Server: nginx/1.12.1
Content-Length: 225
Connection: Close

myCallbackFunction({<json>})

The attacker can use a JavaScript Script tag to load the response from the JSONP endpoint, which will turn into the execution of the myCallbackFunction function. An attacker could use a different callback name to navigate and interact with the DOM. For example opener.document.body.someElemnt.firstChild.nextElementSibling.submit could be used to locate a form in the target page and submit it.

A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection originates from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example 1: In the following example, an attacker can control the URL to which the server is connecting.

...
lv_uri = request->get_form_field( 'uri' ).
CALL METHOD cl_http_utility=>set_request_uri
  EXPORTING
    request     = lo_request
    uri        = lv_uri.
...

The attacker's ability to hijack the network connection depends on the specific part of the URI they can control, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https such as:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example 1: In the following example, an attacker can control the URL to which the server is connecting.

...
PageReference ref = ApexPages.currentPage();
Map<String,String> params = ref.getParameters();
HttpRequest req = new HttpRequest();
req.setEndpoint(params.get('url'));
HTTPResponse res = new Http().send(req);

The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https such as:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following types of attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Perform a DNS cache poisoning attack.

A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example 1: In the following example, an attacker can control the URL to which the server is connecting.

string url = Request.Form["url"];
HttpClient client = new HttpClient();
HttpResponseMessage response = await client.GetAsync(url);

The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example 1: In the following example, an attacker can control the URL to which the server is connecting.

char *url = maliciousInput(); 
CURL *curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL, url);
CURLcode res = curl_easy_perform(curl);

An attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https such as:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using the file:// scheme.
- On Windows systems, using the file:// scheme and UNC paths can enable an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection originates from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example 1: In the following example, an attacker can control the URL to which the server is connecting.

  ...
  final server = await HttpServer.bind('localhost', 18081);
  server.listen((request) async {
      final headers = request.headers;
      final url = headers.value('url');
      final client = IOClient();
      final response = await client.get(Uri.parse(url!));
      ...
  }

The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https such as:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

A Server-Side Request Forgery occurs when an attacker might influence a network connection made by the application server. The network connection originates from the application server's internal IP address and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example 1: In the following example, an attacker can control the URL the server is connecting to.

url := request.Form.Get("url")
res, err =: http.Get(url)
...

The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and the libraries used to establish the connection. For example, controlling the URI scheme enables the attacker to use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- Scan and access internal shares on Windows systems with file:// scheme and UNC paths.
- Perform a DNS cache poisoning attack.

A Server-Side Request Forgery occurs when an attacker may influence a network connection made by the application server. The network connection will originate from the application server's internal IP address and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example 1: In the following example, an attacker can control the URL to which the server is connecting.

var http = require('http');
var url = require('url');

function listener(request, response){
  var request_url = url.parse(request.url, true)['query']['url'];
  http.request(request_url)
  ...
}
...
http.createServer(listener).listen(8080);
...

The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example 1: In the following example, an attacker can control the URL to which the server is connecting.

val url: String = request.getParameter("url")
val httpclient: CloseableHttpClient = HttpClients.createDefault()
val httpGet = HttpGet(url)
val response1: CloseableHttpResponse = httpclient.execute(httpGet)

The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.