When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks. If the application shows the attacker a stack trace, it relinquishes information that makes the attacker's job significantly easier. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.

A Kubernetes API server can authorize a request using one of several authorization modes. The role-based access control (RBAC) controls access to computer or network resources based on the roles of individual users within an organization. RBAC is the most secure authorization mode.

Example 1: The following configuration starts a Kubernetes API server without the RBAC authorization mode.

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

The MessageProtectionOrder attribute allows you to specify the order in which signatures and encryption are applied (and whether or not the signatures should be encrypted). Setting the MessageProtectionOrder attribute to anything other than SignBeforeEncryptAndEncryptSignature constitutes a potential security problem.

The following is a list of possible alternatives to SignBeforeEncryptAndEncryptSignature and their associated problems.
SignBeforeEncrypt - The signature is applied to the unencrypted message, but the signature itself is not encrypted.
EncryptBeforeSign - Message contents are encrypted then signed.

Messages signed with a low entropy keys, such as passwords, are more vulnerable to brute-force attacks.

Certain frameworks such as AngularJS limit the protocols that may be set for links to other sites and images. This is primarily to prevent inline JavaScript from running, which may lead to additional cross-site scripting vulnerabilities within the application.

Example 1: The following changes the default allow list of protocols in AngularJS to also allow image HTML elements to allow inline JavaScript.

myModule.config(function($compileProvider){
    $compileProvider.imgSrcSanitizationWhitelist(/^(http(s)?|javascript):.*/);
});

Strict Contextual Escaping (SCE) is a mechanism in AngularJS applications that helps protect the application from attackers. This can prevent many attack vectors across different types of vulnerabilites. The most prominent protection is against certain types of cross-site scripting attacks. In this application, this protection mechanism is specifically disabled.

Example 1: In this example we disable SCE on a module.

myModule.config(function($sceProvider){
  $sceProvider.enabled(false);
});

If you are using Blaze DS to perform logging of any unexpected events, the services-config.xml descriptor file specifies a "Logging" XML element to describe various aspects of logging. It looks like the following:

Example 1:

<logging>
    <target class="flex.messaging.log.ConsoleTarget" level="Debug">
        <properties>
            <prefix>[BlazeDS]</prefix>
            <includeDate>false</includeDate>
            <includeTime>false</includeTime>
            <includeLevel>false</includeLevel>
            <includeCategory>false</includeCategory>
        </properties>
        <filters>
            <pattern>Endpoint.*</pattern>
            <pattern>Service.*</pattern>
            <pattern>Configuration</pattern>
        </filters>
    </target>
</logging>

This target tag takes an optional attribute called level, which indicates the log level. If the debug level is set to too detailed a level, your application may write sensitive data to the log file.

If the ProtectKernelDefaults setting is left unset or is set to false, a Kubelet can modify kernel parameters at runtime. Kernel parameters should be optimized and hardened before the Kubernetes deployment. Granting a Kubelet the ability to alter kernel parameters expands the attack surface of the host operating system.

Example 1: The following Kubelet configuration permits a Kubelet to configure kernel parameters because of the ProtectKernelDefaults: false setting.

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

A Kubernetes API server can authorize a request using one of several authorization modes. The Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by Kubelets. This ensures that Kubelets have the minimal set of permissions required to operate correctly.

Example 1: The following configuration starts a Kubernetes API server without the Node authorization mode.

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

X-XSS-Protection is an HTTP header introduced by Microsoft, since adopted by other browsers. This is intended to help stop Cross-Site Scripting attacks from being successful, but inadvertently led to a weakness making safe websites vulnerable[1]. Due to this, this shouldn't be used in older versions of Internet Explorer and should be disabled by setting the header to 0.

Example 1: The following misconfigures the Helmet middleware in an Express application to enable this for all versions of Internet Explorer:

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

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

You can reconstruct a Dockerfile from a publicly available docker image using docker inspect and the history command, or by automating this process through a third-party tool. If sensitive information is added using the ADD/COPY command, an attacker can recreate each docker layer to obtain the information.

Using Volumes also can expose sensitive directories. If you need to use Volumes to persist data, avoid mounting sensitive directories.

The following directories are considered sensitive:

- /
- /boot
- /dev
- /etc
- /lib
- /proc
- /sys
- /usr

A Kubernetes API server writes audit events to standard output by default. The audit events should be logged to persistent storage. The audit events contain valuable data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

Example 1: The following configuration starts a Kubernetes API server without the --audit-log-path flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=RBAC
  image: example.domain/kube-apiserver-amd64:v1.6.0
...

A Kubernetes API server does not log events if there is no audit policy file specified. The event logs contain valuable data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

Example 1: The following configuration starts a Kubernetes API server without the --audit-policy-file flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-path=<the log file path>
  image: example.domain/kube-apiserver-amd64:v1.6.0
  ...

When present, the open_basedir configuration option attempts to prevent PHP programs from operating on files outside of the directory trees specified in php.ini. If the working directory is specified with ., this can potentially be changed by an attacker by using chdir().

Although the open_basedir option is an overall boon to security, the implementation suffers from a race condition that can permit attackers to bypass its restrictions in some circumstances [2]. A time-of-check, time-of-use (TOCTOU) race condition exists between the time PHP performs the access permission check and when the file is opened. As with file system race conditions in other languages, this race condition can allow attackers to replace a symlink to a file that passes an access control check with another for which the test would otherwise fail, thereby gaining access to the protected file.

The window of vulnerability for such an attack is the period of time between when the access check is performed and when the file is opened. Even though the calls are performed in close succession, modern operating systems offer no guarantee about the amount of code that will be executed before the process yields the CPU. Attackers have a variety of techniques for expanding the length of the window of opportunity in order to make exploits easier, but even with a small window, an exploit attempt can simply be repeated over and over until it is successful.

Windows Communication Foundation (WCF) offers the ability to log successful and/or failed authentication attempts. Logging failed authentication attempts can warn administrators of potential brute-force attacks. Similarly, logging successful authentication events can provide a useful audit trail when a legitimate account is compromised.

The default escaping performed in Handlebars templates helps protect the application from attackers. This can prevent many attack vectors across different types of vulnerabilites. The most prominent protection is against certain types of cross-site scripting attacks. In this application, this protection mechanism is specifically disabled.

Example 1: The following example shows Handlebars template escaping disabled.

  let template = Handlebars.compile('{{foo}}', { noEscape: true })

Handlebars templates cannot access an object's prototypes as it makes the application susceptible to Prototype Pollution attacks.

Prototype Pollution attacks occur when a malicious user can control functions or properties on the prototypes of objects. Controlling the prototypes of an object that is passed into a template allows many vulnerabilities, including Dynamic Code Evaluation, Cross-Site Scripting, and Remote Code Execution.

Example 1: In the following example configuring Handlebars templates, prototype methods are allowed by default, as well as the special __defineGetter__ function.

let template2 = Handlebars.compile('{{foo}}')
console.log(template2({ foo: argument }, {
    allowProtoMethodsByDefault: true,
    allowedProtoMethods: {
        __defineGetter__: true
    }
}))

The Kubernetes API server automatically rotates log files. To facilitate post-incident analysis and threat detection, as well as to meet compliance requirements, you must retain a sufficient amount of log data. The --audit-log-maxbackup flag defines the maximum number of log files to retain. Either this flag is not present in the command to start a Kubernetes API server or the maximum number of log files to retain is less than 10.

Example 1: The following command starts a Kubernetes API server and sets the --audit-log-maxbackup flag to 2, which insufficiently retains only two log files.

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

The Kubernetes API server automatically rotates log files. To facilitate post-incident analysis and threat detection, as well as to meet compliance requirements, you must retain a sufficient amount of log data. The --audit-log-maxsize flag sets the maximum size in megabytes (MB) of the audit log file before it's automatically rotated. Either this flag is not present in the command to start a Kubernetes API server or the maximum size of the audit log file is set to less than 100 MB.

Example 1: The following command starts a Kubernetes API server and sets the --audit-log-maxsize flag to 2 (megabytes), which is insufficient.

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

If the PHP interpreter is installed as a CGI binary then requests for PHP resources are typically redirected by the Web server to the interpreter. In this situation, when a user requests http://www.example.com/content/page.php, the server first performs the necessary access control checks on the directory /content, then redirects control to the PHP interpreter with a request to http://www.example.com/cgi-bin/php/content/page.php.

If cgi.force_redirect, which is enabled by default, is disabled, then attackers with access to /cgi-bin/php can use the permissions of the PHP interpreter to access arbitrary Web documents, thus bypassing any access control checks that would have been performed by the server.

The enable_dl configuration allows dynamic loading of libraries. These could potentially allow an attacker to circumvent the restrictions set with the open_basedir configuration, and potentially allow access to any file on the system.

Enabling enable_dl can make it easier for attackers to exploit other vulnerabilities.