Path Manipulation: Zip Entry Overwrite errors occur when a ZIP file is opened and expanded without checking the file path of the ZIP entry.

Example 1: The following example extracts files from a ZIP file and insecurely writes them to disk.

...

  " Add Binary File to
  CALL METHOD lr_abap_zip->add
    EXPORTING
      name    = p_ifile
      content = lv_bufferx.

    " Read Binary File to
  CALL METHOD lr_abap_zip->get
    EXPORTING
      name    = p_ifile
    IMPORTING 
      content = lv_bufferx2.

...

In Example 1, there is no validation of p_ifile prior to performing read/write functions on the data within this entry. If the ZIP file was originally placed in the directory "/tmp/" of a Unix-based machine, a ZIP entry was "../etc/hosts", and the application was run under the necessary permissions, it overwrites the system hosts file. This in turn allows traffic from the machine to go anywhere the attacker wants, such as back to the attacker's machine.

Path Manipulation: Zip Entry Overwrite errors occur when a Zip file is opened and expanded without checking the file path of the Zip entry.

Example 1: The following example extracts files from a Zip file and insecurely writes them to disk.

    public static void UnzipFile(ZipArchive archive, string destDirectory)
    {
        foreach (var entry in archive.Entries)
        {
            string file = entry.FullName;
            if (!string.IsNullOrEmpty(file))
            {
                string destFileName = Path.Combine(destDirectory, file);
                entry.ExtractToFile(destFileName, true);

            }
        }
    }

In Example 1, there is no validation of entry.FullName prior to performing read/write operations on the data within this entry. If the Zip file was originally placed in the directory "C:\TEMP", a Zip entry name contained "..\ segments", and the application was run under the necessary permissions, it could arbitrarily overwrite system files.

Path Manipulation: Zip Entry Overwrite errors occur when a Zip file is opened and expanded without checking the file path of the Zip entry.

Example 1: The following example extracts files from a Zip file and insecurely writes them to disk.

func Unzip(src string, dest string) ([]string, error) {
    var filenames []string
    r, err := zip.OpenReader(src)
    if err != nil {
        return filenames, err
    }
    defer r.Close()

    for _, f := range r.File {
        // Store filename/path for returning and using later on
        fpath := filepath.Join(dest, f.Name)

        filenames = append(filenames, fpath)

        if f.FileInfo().IsDir() {
            // Make Folder
            os.MkdirAll(fpath, os.ModePerm)
            continue
        }
        
        // Make File
        if err = os.MkdirAll(filepath.Dir(fpath), os.ModePerm); err != nil {
            return filenames, err
        }

        outFile, err := os.OpenFile(fpath, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, f.Mode())
        if err != nil {
            return filenames, err
        }
    
        rc, err := f.Open()
        if err != nil {
            return filenames, err
        }

        _, err = io.Copy(outFile, rc)

        // Close the file without defer to close before next iteration of loop
        outFile.Close()
        rc.Close()

        if err != nil {
            return filenames, err
        }
    }
    return filenames, nil
}

In Example 1, there is no validation of f.Name prior to performing read/write functions on the data within this entry. If the Zip file was originally placed in the directory "/tmp/" of a Unix-based machine, a Zip entry was "../etc/hosts", and the application was run under the necessary permissions, it would overwrite the system hosts file. This in turn would allow traffic from the machine to go anywhere the attacker wants, such as back to the attacker's machine.

Path Manipulation: Zip Entry Overwrite errors occur when a Zip file is opened and expanded without checking the file path of the Zip entry.

Example 1: The following example extracts files from a Zip file and insecurely writes them to disk.

var unzipper = require('unzipper');
var fs = require('fs');

var untrusted_zip = getZipFromRequest();
fs.createReadStream(zipPath).pipe(unzipper.Extract({ path: 'out' }));

Path Manipulation: Zip Entry Overwrite errors occur when a Zip file is opened and expanded without checking the file path of the Zip entry.

Example 1: The following example extracts files from a Zip file and insecurely writes them to disk.

    ZZArchive* archive = [ZZArchive archiveWithURL:[NSURL fileURLWithPath: zipPath] error:&error];
    for (ZZArchiveEntry* entry in archive.entries) {
        NSString *fullPath = [NSString stringWithFormat: @"%@/%@", destPath, [entry fileName]];
        [[entry newDataWithError:nil] writeToFile:newFullPath atomically:YES];
    }

In Example 1, there is no validation of entry.fileName prior to performing read/write functions on the data within this entry. If the Zip file was originally placed in the directory "Documents/hot_patches" of an iOS application, a Zip entry was "../js/page.js", it would overwrite the page.js file. This in turn would enable an attacker to inject malicious code that might result in code execution.

Path Manipulation: Zip Entry Overwrite errors occur when a Zip file is opened and the files extracted without checking the file path of the Zip entry.

Example 1: The following example extracts files from a Zip file and insecurely writes them to disk.

...
$zip = new ZipArchive();
$zip->open("userdefined.zip", ZipArchive::RDONLY);
$zpm = $zip->getNameIndex(0);
$zip->extractTo($zpm);
...

In Example 1, there is no validation of f.Name before performing read/write functions on the data within this entry. If the Zip file is in the directory "/tmp/" of a Unix-based machine, a Zip entry is "../etc/hosts", and the application is run under the necessary permissions, it will overwrite the system hosts file. This allows traffic from the machine to go anywhere the attacker wants, such as back to the attacker's machine.

Path Manipulation: Zip Entry Overwrite errors occur when a Zip file is opened and expanded without checking the file path of the Zip entry.

Example 1: The following example extracts files from a Zip file and insecurely writes them to disk.

import zipfile
import tarfile

def unzip(archive_name):
    zf = zipfile.ZipFile(archive_name)
    zf.extractall(".")
    zf.close()

def untar(archive_name):
    tf = tarfile.TarFile(archive_name)
    tf.extractall(".")
    tf.close()

Path Manipulation: Zip Entry Overwrite errors occur when a Zip file is opened and expanded without checking the file path of the Zip entry.

Example 1: The following example extracts files from a Zip file and insecurely writes them to disk.

import better.files._

...

val zipPath: File = getUntrustedZip()
val destinationPath = file"out/dest"
zipPath.unzipTo(destination = destinationPath)

Example 2: The following example extracts files from a Zip file and insecurely writes them to disk.

import better.files._

...

val zipPath: File = getUntrustedZip()
val destinationPath = file"out/dest"
zipPath.newZipInputStream.mapEntries( (entry : ZipEntry) => {
    entry.extractTo(destinationPath, new FileInputStream(entry.getName))
})

In Example 2, there is no validation of entry.getName prior to performing read/write functions on the data within this entry. If the Zip file was originally placed in the directory "/tmp/" of a Unix-based machine, a Zip entry was "../etc/hosts", and the application was run under the necessary permissions, it would overwrite the system hosts file. This in turn would allow traffic from the machine to go anywhere the attacker wants, such as back to the attacker's machine.

Path Manipulation: Zip Entry Overwrite errors occur when a Zip file is opened and expanded without checking the file path of the Zip entry.

Example 1: The following example extracts files from a Zip file and insecurely writes them to disk.

let archive = try ZZArchive.init(url: URL(fileURLWithPath: zipPath))

for entry in archive.entries {
    let fullPath = URL(fileURLWithPath: destPath + "/" + entry.fileName)
    try entry.newData().write(to: fullPath)
}

In Example 1, there is no validation of entry.fileName prior to performing read/write functions on the data within this entry. If the Zip file was originally placed in the directory "Documents/hot_patches" of an iOS application, a Zip entry was "../js/page.js", it would overwrite the page.js file. This in turn would enable an attacker to inject malicious code that might result in code execution.

NSPredicate instances specify how a collection should be fetched or filtered from sources such as CoreData persistent storage system, an array and a dictionary. Its query language provides an expressive language similar to SQL to define logical conditions on which the collection should be searched.

An attacker able to influence the predicate may be able to change its meaning in order to, for example, leak data, bypass security controls or impersonate other users.

Example 1: The following example shows how an NSPredicate is used as an authentication factor to access some data stored by the application. Since users can provide arbitrary PIN values, they will be able to use a wildcard character (*) to bypass the PIN protection.

let pin = getPinFromUser();
let predicate = NSPredicate(format: "pin LIKE '\(pin)'", argumentArray: nil)

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.

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.