The sanitizeValue property determines whether to run the HTML sanitizer when the value is applied to the HTML markup. The input might come directly from the user and thus can be considered unsafe. The sanitizeValue property can be set to false for multiple reasons, such as allowing additional input characters. However, doing so can inadvertently allow unsafe user input to be executed in the code. It is safer to set the sanitizeValue property to true, which it is by default.

Example 1: The following sets the sanitizeValue property in the SAPUI5 RichTextEditor to false:

new RichTextEditor({
    sanitizeValue: false,
    value: input
}).placeAt("moreContent");

Always configure APIs to use custom error responses instead of relying on the underlying framework's default responses. Default responses might give detailed information about the error that occurred, and inadvertently leak sensitive information.

Attackers may leverage the additional information provided by a default error response to mount attacks targeting the framework, database, or other resources used by the API.

When enabled, the file_uploads option allows PHP users to upload arbitrary files to the server. Permitting users to upload files does not represent a security vulnerability itself. However, this capability can enable a variety attacks because it gives malicious users an avenue to introduce data into the server environment.

Regardless of the language a program is written in, 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.

When LLM APIs are not properly configured, a Denial of Wallet (DoW) attack can occur if attackers exploit the cost-per-use model of cloud-based AI services by initiating a high volume of requests. This leads to unsustainable financial burdens on the provider. This can result in financial ruin for the provider, as the cost of processing excessive requests becomes unmanageable.

Example 1: The following code shows how setting the max_completion_tokens parameter to None can increase the chances of producing excessive data. This can overwhelm the resources of the LLM server and potentially lead to a Denial of Wallet (DoW) attack.

import os
from openai import OpenAI

client = OpenAI(api_key='OPENAI_API_KEY')

def generate_safe_response(prompt):
    completion = client.chat.completions.create(
        model="gpt-3.5-turbo",
        timeout=10,
        max_completion_tokens=None,
        messages=[
            {"role": "user", "content": prompt}
        ]
    )
    return completion.choices[0].message

prompt = "Describe the latest advancements in machine learning."
response = generate_safe_response(prompt)
print(response)

In Example 1, the max_completion_tokens parameter limits the length of the output, which helps to ensure that the model does not generate excessively long responses that could cause issues downstream. By controlling the output size, you reduce the risk of generating unintended, potentially harmful content that could lead to security vulnerabilities.

The streamingConnectionIdleTimeout field of a Kubelet configuration specifies the maximum amount of time a streaming connection is idle before the connection is automatically closed. Setting idle timeouts protects against denial-of-service attacks and running out of connections. Setting the field value to 0 disables the idle timeout.

Example 1: The following Kubelet configuration disables the streaming connection timeout by setting the streamingConnectionIdleTimeout field to 0.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
streamingConnectionIdleTimeout: 0

The safe_mode option is one of the most important security features in PHP. When safe_mode is disabled, PHP operates on files with the permissions of the user that invoked it, which is often a privileged user. Although configuring PHP with safe_mode disabled does not introduce a security vulnerability itself, this added leniency can be exploited by attackers in conjunction with other vulnerabilities to make exploits more dangerous.

Kubernetes API servers accept anonymous requests by default if the requests are not rejected by other configured authentication methods. Because an API server is the central management entity of a cluster, attackers can use anonymous requests to gain access to insufficiently protected and security sensitive service APIs.

Example 1: The following configuration starts a Kubernetes API server and permits anonymous requests by setting the --anonymous-auth=true flag.

...
spec:
  containers:
    - command:
      - kube-apiserver
...
      - --anonymous-auth=true
...

There is a configuration that permits Kubelets to serve anonymous requests. Anonymous requests are not rejected by any configured authentication method. Because Kubelets are the Kubernetes principal agents to manage a worker machine workload, attackers can use anonymous requests to gain access to insufficiently protected and security sensitive service APIs.

Example 1: The following configuration file permits a Kubelet to serve anonymous requests because the anonymous field is set to enabled:true.

...
kind: KubeletConfiguration
...
authentication:
  anonymous:
    enabled: true
...

By default, Silverlight applications are subject to the Same-Origin Policy which ensures that a Silverlight application can access data on a service only if they come from the same domain. Silverlight allows developers to alter the policy via appropriate settings in the clientaccesspolicy.xml configuration file on the host. However, caution should be taken when changing the settings because an overly permissive cross-domain policy will allow a malicious applications to communicate with the victim service in an inappropriate way, leading to spoofing, data theft, relay, and other attacks.

Example 1: The following configuration shows clientaccesspolicy.xml using a wildcard to specify with which domains the service is allowed to communicate.

<allow-from http-request-headers="*">
	<domain uri="*"/>
</allow-from>

Using the * as the value of the domain element's uri attribute indicates that applications on any domain can connect to the service.

A Kubelet authorizes a request using either the AlwaysAllow mode or the Webhook mode. An unspecified authorization mode defaults to AlwaysAllow. The Kubelet does not perform any authorization check in AlwaysAllow mode because it allows all requests. Because Kubelets are the Kubernetes principal agents to manage a worker machine workload, attackers can use uncontrolled requests to gain access to insufficiently protected and security sensitive service APIs.

Example 1: The Kubelet does not perform any authorization check because the authorization mode is set to AlwaysAllow.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authorization:
  mode: AlwaysAllow

A Kubernetes API server can authorize a request using one of several authorization modes. The API server does not perform any authorization check in AlwaysAllow mode because it allows all requests.

Example 1: The following configuration starts a Kubernetes API server with AlwaysAllow as one of the authorization modes.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --authorization-mode=...,AlwaysAllow,...
    ...

By default, Kubelets automatically make the required changes to iptables based on the networking options in Pod configurations. Setting makeIPTablesUtilChains to enabled:false in a Kubelet configuration prevents the Kubelet from managing network traffic between containers and the rest of the world. This prevents the Kubelet from enforcing the necessary network security requirements and setting up the connectivity requested by containers.

Example 1: The following Kubelet configuration prevents a Kubelet from making the required changes to iptables because of the setting makeIPTablesUtilChains: false.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
makeIPTablesUtilChains: false

If the EJB deployment descriptor contains one or more method permissions that grant access to the special ANYONE role, it indicates that access control for the application has not been fully thought through or that the application is structured in such a way that reasonable access control restrictions are impossible.

Example 1: The following deployment descriptor grants ANYONE permission to invoke the Employee EJB's method named getSalary().

<ejb-jar>
	...
	<assembly-descriptor>
		<method-permission>
			<role-name>ANYONE</role-name>
			<method>
				<ejb-name>Employee</ejb-name>
				<method-name>getSalary</method-name>
		</method-permission>
	</assembly-descriptor>
	...
</ejb-jar>

Service account credentials are shared among controllers because the command to start the Kubernetes controller manager does not contain the --use-service-account-credentials=true flag. This flag instructs the controller manager to start each controller using a separate service account. When used in combination with role-based access control (RBAC), this ensures that each controller runs with the minimum permissions needed to perform its tasks.

Example 1: The following configuration starts a Kubernetes controller manager without the --use-service-account-credentials flag.

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - command:
        - /usr/local/bin/kube-controller-manager
    image: k8s.gcr.io/kube-controller-manager:v1.9.7
...

Log files should be kept long enough to facilitate post-incident analysis and threat detection, as well as to meet compliance requirements. The --audit-log-maxage flag defines the maximum number of days to retain old audit log files. Either the flag is not present in the command to start a Kubernetes API server or the retention period is set to less than 30 days.

Example 1: The following command starts a Kubernetes API server and sets --audit-log-maxage flag to 2 (2 days), which is too short.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --audit-log-maxage=2
    ...

When a client calls a particular WCF service, WCF provides various authorization schemes that verify that the caller has permission to execute the service method on the server. If authorization controls are not enabled for WCF services, an authenticated user can achieve privilege escalation.

Example 1: The following code instructs WCF to not check the authorization level of the client when executing the service:

    ServiceHost myServiceHost = new ServiceHost(typeof(Calculator), baseUri);
    ServiceAuthorizationBehavior myServiceBehavior =
    myServiceHost.Description.Behaviors.Find<ServiceAuthorizationBehavior>();
    myServiceBehavior.PrincipalPermissionMode =
        PrincipalPermissionMode.None;

Dockerfiles can specify an unbound range of versions for dependencies and base images. If an attacker is able to add malicious versions of dependencies to a repository or trick the build system into downloading dependencies from a repository under the attacker's control, if docker is configured without specific versions of dependencies, then docker will silently download and run the compromised dependency.

This type of weakness would be exploitable as a result of a supply chain attack where attackers can leverage misconfiguration by developers, typosquatting and can add malicious packages to open source repositories. An attack of this type exploits the trust in the published packages to gain access and exfiltrate data.

In docker, the latest tag automatically indicates the version level of an image that doesn't use a digest or unique tag to provide a version for it. Docker automatically assigns the latest tag as mechanism to point to the most recent image manifest file. Because tags are mutable, an attacker can replace an image or layer using a latest (or weak tags such as imagename-lst, imagename-last, myimage).

Example 1: The following configuration instructs Docker to pick the base image using the latest version of ubuntu.

    FROM ubuntu:Latest
    ...

Docker does not validate whether the repository configured to support the package manager is trustworthy.

Example 2: The following configuration instructs the package manager zypper to retrive the latest version of the given package.

...
zypper install package
...

In Example 2, if the repository is compromised, an attacker could simply upload a version that meets the dynamic criteria and cause zypper to download a malicious version of the dependency.

WCF services can be configured to expose metadata. Metadata gives detailed service description information and should not be broadcast in production environments. The HttpGetEnabled / HttpsGetEnabled properties of the ServiceMetaData class defines whether a service will expose the metadata.
Example 1: The following code instructs WCF to broadcast a service's metadata.

    ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
    smb.HttpGetEnabled = true;
    smb.HttpGetUrl = new Uri(EndPointAddress);
    Host.Description.Behaviors.Add(smb);

The <serviceMetadata> tag enables the metadata publishing feature. Service metadata could contain sensitive information that should not be publicly accessible.

A nonce is a cryptographic random value that is sent with a message to prevent replay attacks. When a nonce is combined with timestamp (or expiration), each message is unique and is only valid for a certain amount of time, thus thwarting any attempt to retransmit an old message.