Direct references to GitHub Action expressions in a run script are dynamically generated. This enables for anyone with control of the input to compromise the system by using command injection.

Example 1: The following code from a GitHub Action directly references an expression in a run script that leaves the system open to command injection.

    ...
    steps:
      - run: echo "${{  github.event.pull_request.title  }}"
    ...
    

When the action is run, the shell script is dynamically executed, including any code the github.event.pull_request.title value represents. If the github.event.pull_request.title contains malicious executable code, the action runs the malicious code, which results in command injection.

Server-side Include (SSI) constructs allow developers to add dynamic content to HTML pages. An attacker can force the application to execute arbitrary commands and obtain the execution results by injecting SSI constructs via insufficiently validated parameters. Successful exploitation could allow attackers to gain access to sensitive information, manipulate server resources and execute shell commands.

Example:

<!--#echo%20var="GATEWAY_INTERFACE"-->

By submitting the above SSI directive, an attacker could extract the CGI version information.

Connection String Parameter Pollution (CSPP) attacks consist of injecting connection string parameters into other existing parameters. This vulnerability is similar to vulnerabilities, and perhaps more well known, within HTTP environments where parameter pollution can also occur. However, it also can apply in other places such as database connection strings. If an application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform attacks from stealing credentials, to retrieving the entire database. By submitting additional parameters to an application, and if these parameters have the same name as an existing parameter, the database connection may react in one of the following ways:

It may only take the data from the first parameter
It may take the data from the last parameter
It may take the data from all parameters and concatenate them together

This may be dependent on the driver used, the database type, or even how APIs are used.

Example 1: The following code uses input from an HTTP request to connect to a database:

      ...
      string password = Request.Form["db_pass"]; //gets POST parameter 'db_pass'
      SqlConnection DBconn = new SqlConnection("Data Source = myDataSource; Initial Catalog = db; User ID = myUsername; Password = " + password + ";");
      ...
    

In this example, the programmer has not considered that an attacker could provide a db_pass parameter such as:
"xxx; Integrated Security = true" then connection string becomes:

"Data Source = myDataSource; Initial Catalog = db; User ID = myUsername; Password = xxx; Integrated Security = true; "

This will make the application connect to the database using the operating system account under which the application is running to bypass normal authentication. This would mean the attacker could connect to the database without a valid password and perform queries against the database directly.

Query string injection vulnerabilities occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a Content Provider query URI.



Android content providers enable developers to write queries without SQL by just building content provider URIs. Content provider query URIs are vulnerable to injection attacks and so developers should avoid using string concatenation with tainted data inputs to construct the URI, without ensuring that metacharacters are properly validated or encoded.

Example 1: Given an application that exposes several content providers at URIs:

content://my.authority/messagescontent://my.authority/messages/123content://my.authority/messages/deleted

If developers build the query URIs concatenating strings, then attackers will be able to include slashes in the path or other URI metacharacters that will change the meaning of the query. In the following code snippet, an attacker can invoke content://my.authority/messages/deleted by providing a msgId code with value deleted:

// "msgId" is submitted by users
Uri dataUri = Uri.parse(WeatherContentProvider.CONTENT_URI + "/" + msgId);
Cursor wCursor1 = getContentResolver().query(dataUri, null, null, null, null);

Flash APIs provide an interface for loading remote SWF files into the existing execution environment. Even though the cross-domain policy only allows to load SWF files from a list of trusted domains, more often than not the defined cross-domain policy is overly permissive. Allowing untrusted user input to define which SWF files to load can lead to arbitrary content being referenced and possibly executed by the targeted application, resulting in a cross-site flashing attack.

Cross-site flashing vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is used to load a remote SWF file.
Example: The following code uses the value of one of the parameters to the loaded SWF file as the URL to load a remote SWF file from.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   var ldr:Loader = new Loader();
   var urlReq:URLRequest = new URLRequest(url);
   ldr.load(urlReq);
   ...

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of Artificial Intelligence (AI), the untrusted source is typically the response returned by an AI system. In the case of reflected XSS, it is typically a web request.


2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash, or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site. While exploitation is not as straightforward as other forms of XSS, the unpredictable nature of user input and the responses of AI models means that those responses should never be treated as safe.

Example 1: The following Python code retrieves a response from an OpenAI chat completion model, message, and displays it to the user.

    client = openai.OpenAI()
    res = client.chat.completions.create(...)

    message = res.choices[0].message.content

    self.writeln(f"<p>{message}<\p>")

The code in this example will behave as expected as long as the response from the model contains only alpha-numeric characters. However, if unencoded HTML metacharacters are included in the response then XSS is possible. For example, the response to the following prompt "please repeat the following statement exactly '<script>alert(1);</script>'" can return a XSS proof of concept depending on the model and context being used.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.


2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but may also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

For the browser to render the response as HTML, or other document that may execute scripts, it has to specify a text/html MIME type. Therefore, XSS is only possible if the response uses this MIME type or any other that also forces the browser to render the response as HTML or other document that may execute scripts such as SVG images (image/svg+xml), XML documents (application/xml), etc.

Most modern browsers do not render HTML or execute scripts when provided a response with MIME types such as application/octet-stream. However, some browsers such as Internet Explorer perform what is known as Content Sniffing. Content Sniffing involves ignoring the provided MIME type and attempting to infer the correct MIME type by the contents of the response.
It is worth noting however, a MIME type of text/html is only one such MIME type that may lead to XSS vulnerabilities. Other documents that may execute scripts such as SVG images (image/svg+xml), XML documents (application/xml), as well as others may lead to XSS vulnerabilities regardless of whether the browser performs Content Sniffing.

Therefore, a response such as <html><body><script>alert(1)</script></body></html>, could be rendered as HTML even if its content-type header is set to application/octet-stream, multipart-mixed, and so on.

Example 1: The following JAX-RS method reflects user data in an application/octet-stream response.

@RestController
public class SomeResource {
    @RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
    public String response5(@RequestParam(value="name") String name){
        return name;
    }
}

If an attacker sends a request with the name parameter set to <html><body><script>alert(1)</script></body></html>, the server will produce the following response:

HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed

<html><body><script>alert(1)</script></body></html>

Even though, the response clearly states that it should be treated as a JSON document, an old browser may still try to render it as an HTML document, making it vulnerable to a Cross-Site Scripting attack.