Any delayed response to breaches undermines an organization's ability to limit the impact of a breach.

Configuration settings that undermine monitoring capabilities include but are not limited to:
- deliberately disabling monitoring
- not enabling optional monitoring
- not specifying relevant events to export to monitoring services
- exempting actions of specific users, groups, processes, and geographical regions from monitoring

By default, a Google Kubernetes Engine (GKE) cluster sends metrics from Pods to the Stackdriver Kubernetes Engine Monitoring Service. The Terraform script sets up a GKE cluster and explicitly disables the monitoring service. The absence of metrics undermines proper detection of and prompt response to security events.

Example 1: The following example shows a Terraform configuration that disables the monitoring service of a GKE cluster by setting monitoring_service to none.

resource "google_container_cluster" "cluster-demo" {
    name               = "name-demo"
    location           = "us-central1-a"
    monitoring_service = "none"
    ...
}

Cross-frame scripting vulnerabilities occur when an application:

1. Allows itself to be included inside an iframe.
2. Fails to specify framing policy via the X-Frame-Options header.
3. Uses poor protection, such as JavaScript-based frame busting logic.

Cross-frame scripting vulnerabilities often form the basis of clickjacking exploits that attackers may use to conduct cross-site request forgery or phishing attacks.

All modern web development frameworks provide built-in session management support. Prior knowledge of session identifiers is essential for hijacking user sessions using attacks such as Cross-Site Request Forgery and Clickjacking. This knowledge can also help attackers fingerprint the web frameworks and technologies used to build the target application. Attackers can use this information to discover hidden resources, customize their exploits, and target known exploits disclosed against the detected frameworks or technologies.

A lack of audit records limits the ability to detect and respond to security related incidents and prevents forensic investigation.

Example 1: The following example template shows an Azure SQL server configuration without auditing enabled.

@secure()
param sqlLogin string

@secure()
param sqlLoginPass string

param location string = resourceGroup().location

resource sqlServer 'Microsoft.Sql/servers@2021-11-01-preview' = {
    name: 'server name'
    location: location
    tags: {
        displayName: 'server name'
    }
    properties: {
        administratorLogin: sqlLogin
        administratorLoginPassword: sqlLoginPass
        version: '12.0'
        publicNetworkAccess: 'Disabled'
    }
}

The Django applications settings specifies "*" as an entry in the ALLOWED_HOSTS setting. This setting is used by django.http.HttpRequest.get_host() to validate the Host header. A value of "*" will allow any host in the Host header. An attacker may use this in cache poisoning attacks or for poisoning links in emails.

Example 1: An application offers a reset password feature where users can submit some kind of unique value to identify themselves (eg: email address) and then a password reset email will be sent with a link to a page to set up a new password. The link sent to the user can be constructed using the Host value to reference the site that serves the reset password feature in order to avoid hardcoded URLs. For example:

...
def reset_password(request):
  url = "http://%s/new_password/?token=%s" % (request.get_host(), generate_token())
  send_email(reset_link=url)
  redirect("home")
...

An attacker may try to reset a victim's password by submitting the victim's email and a fake Host header value pointing to a server he controls. The victim will receive an email with a link to the reset password system and if he decides to visit the link, she will be visiting the attacker-controlled site which will serve a fake form to collect the victim's credentials.

Attackers can target unauthenticated MongoDB servers to compromise the data stored in it and depending on the MongoDB version, to get a foothold on your internal network by compromising the server.

Different attacks can be used against a MongoDB server to get arbitrary code execution on its underlying operating system. For example, vulnerabilities existed in the past that allowed attackers to turn a server-side JavaScript injection into remote code execution. When used to store objects, an attacker can also store deserialization payloads for different languages such as Java, Python, Ruby, PHP, etc. in order to get remote code execution on the deserializing endpoint.

Please note that even if the MongoDB server is not exposed externally, an external attacker may still reach it or the REST API via a Server-Side Request Forgery vulnerability in any application on the same network. For example, MongoDB Servers can be attacked using HTTP or Gopher protocols.

Failure to protect the MongoDB port externally can have a large security impact. For example, an external attacker can use a single remove command to delete the whole data set. Recently, there have been reports of malicious attacks on unsecured instances of MongoDB running openly on the internet. The attacker erased the database and demanded a ransom be paid before restoring it.

Unauthenticated Redis servers may be targeted by attackers to get a foothold on your internal network by compromising the server.

Different attacks may be used against a Redis server to get arbitrary code execution on its underlying operating system. For example, an attacker may use Redis commands to write a web shell into the web root. When used to store objects, an attacker may also store deserialization payloads for different languages such as Java, Python, Ruby, PHP, etc. in order to get remote code execution on the deserializating endpoint.

Please note that even if the Redis server is not exposed externally, an external attacker may still reach it via a Server-Side Request Forgery vulnerability in any application on the same network. Redis Servers can be attacker using HTTP or Gopher protocols for example.

Failing to protect the Redis port from the outside can have a big security impact because of the nature of Redis. For instance, a single FLUSHALL command can be used by an external attacker to delete the whole data set. Recently, there have been reports of malicious attacks on unsecured instances of Redis running openly on the internet. The attacker erased the database and demanded a ransom be paid before restoring it.

Event validation is an ASP.NET security feature that validates the event controls in postback requests to ensure that the controls are the same as when they were rendered during the initial page load. When this feature is disabled, attackers might carry out Cross-Site Request Forgery attacks with tampered event controls, leading to unauthorized accesses, Cross-Site Scripting attacks, etc.

Example 1: The following web app configuration disables event validation.

...
<system.web>
    ...
    <pages enableEventValidation="false">
    ...
    </pages>
</system.web>

Example 2: The following server page directive disables event validation.

<%@ Page ... EnableEventValidation="false" %>

Unmonitored systems provide attackers with a way to probe and potentially penetrate defenses without detection.

If security personnel are not alerted in a timely fashion to security-related events, they cannot respond to incidents in time to reduce the impact of an attack or breach.

Example 1: The following example template successfully defines a security contact but explicitly disables the delivery of security alert email notifications to that contact.

targetScope = 'subscription'

param emailAddress string
param phoneNumber string

resource example 'Microsoft.Security/securityContacts@2020-01-01-preview' = {
    ...
    properties: {
        ...
        emails: emailAddress
        phone: phoneNumber
        alertNotifications: {
            state: 'Off'
            minimalSeverity: 'High'
        }
    }
}

Granting allUsers or allAuthenticatedUsers a Cloud KMS CryptoKey role gives anyone access to sensitive data.

By default, Azure Kubernetes Service (AKS) clusters created by Ansible do not send log events to Azure Monitor. This can allow malicious behavior to go undetected and prevent forensic analysis in the event of a breach.

Example 1: The following example Ansible task shows an AKS cluster that does not send log events to Azure Monitor.

- name: AKS Instance
  azure_rm_aks:
    name:
    resource_group: testResourceGroup
    location: eastus
    ...
    addon:
      monitoring:
        log_analytics_workspace_resource_id: logws001
        enabled: no

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of self-XSS, data is read from a text box or other value that can be controlled from the DOM and written back into the page using client-side code.


2. The data is included in dynamic content that is sent to a web user without validation. In the case of self-XSS, malicious content is executed as part of DOM (Document Object Model) modification.

The malicious content in the case of self-XSS takes the form of a JavaScript segment, or any other type of code that the browser executes. As self-XSS is primarily an attack on oneself, it is often considered unimportant, but should be treated the same as a standard XSS weakness if one of the following can occur:

- A Cross-Site Request Forgery vulnerability is identified on your website.
- A social engineering attack can convince a user to attack their own account, compromising their session.
Example 1: Consider the HTML form:

  <div id="myDiv">
    Employee ID: <input type="text" id="eid"><br>
    ...
    <button>Show results</button>
  </div>
  <div id="resultsDiv">
    ...
  </div>
  

The following jQuery code segment reads an employee ID from the text box, and displays it to the user.

  $(document).ready(function(){
    $("#myDiv").on("click", "button", function(){
      var eid = $("#eid").val();
      $("resultsDiv").append(eid);
      ...
    });
  });
  

These code examples operate correctly if the employee ID from the text input with ID eid contains only standard alphanumeric text. If eid has a value that includes metacharacters or source code, then after the user clicks the button, the code is added to the DOM for the browser to execute. If an attacker can convince a user to input malicious input into the text input, then this is simply a DOM-based XSS.

By default, Azure Kubernetes Service (AKS) clusters do not send log events to Azure Monitor. This can allow malicious behavior to go undetected and prevent forensic analysis in the event of a breach.

Example 1: The following example template shows an AKS cluster that does not send log events to Azure Monitor.

resource example 'Microsoft.ContainerService/managedClusters@2018-03-31' = {
    ...
    properties: {
        ...
        addonProfiles: {}
    }
}

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
private static String hmacKey = "";
byte[] keyBytes = hmacKey.getBytes();
...
SecretKeySpec key = new SecretKeySpec(keyBytes, "SHA1");
Mac hmac = Mac.getInstance("HmacSHA1");
hmac.init(key);
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

By default, a Kubernetes API server does not authenticate itself to Kubelets when submitting requests. Kubelets, that provide access to a wide variety of resources, cannot verify the authenticity of these requests.

Example 1: The following command starts a Kubernetes API server without specifying a client certificate and the corresponding private key with the --kubelet-client-certificate flag and the --kubelet-client-key flag respectively to enable certificate-based authentication to Kubelets.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-maxage=50
    - --audit-log-maxbackup=20
    - --audit-log-maxsize=200
    image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
    ...

In Java, finally blocks are always executed after their corresponding try-catch blocks and are often used to free allocated resources, such as file handles or database cursors. Throwing an exception in a finally block can bypass critical cleanup code since normal program execution will be disrupted.

Example 1: In the following code, the call to stmt.close() is bypassed when the FileNotFoundException is thrown.

public void processTransaction(Connection conn) throws FileNotFoundException
{
    FileInputStream fis = null;
    Statement stmt = null;
    try
    {
        stmt = conn.createStatement();
        fis = new FileInputStream("badFile.txt");
        ...
    }
    catch (FileNotFoundException fe)
    {
        log("File not found.");
    }
    catch (SQLException se)
    {
        //handle error
    }
    finally
    {
        if (fis == null)
        {
            throw new FileNotFoundException();
        }

        if (stmt != null)
        {
            try
            {
                stmt.close();
            }
            catch (SQLException e)
            {
                log(e);
            }
        }
    }
}

A Kubernetes API server sends instructions to Kubelets to create workload, queries status of Kubelet-managed resources, and provides optional port-forwarding services to Kubelets. By default, the API server does not verify a Kubelet's serving certificate before establishing connection. This connection is therefore susceptible to a man-in-the-middle attack.

Example 1: The following command starts a Kubernetes API server without specifying a root certificate bundle to verify the Kubelet's serving certificate with the --kubelet-certificate-authority flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-maxage=50
    - --audit-log-maxbackup=20
    - --audit-log-maxsize=200
  image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
    ...

Content Security Policy (CSP) is a declarative security header that allows developers to dictate which domains the site is allowed to load content from or initiate connections to when rendered in the web browser. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code. An improperly configured header, however, fails to provide this additional layer of security. The policy is defined with the help of fifteen directives including eight that control resource access, namely: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src.

Each of these takes a source list as a value specifying domains the site is allowed to access for a feature covered by that directive. Developers may use wildcard * to indicate all or part of the source. None of the directives are mandatory. Browsers will either allow all sources for an unlisted directive or will derive its value from the optional default-src directive. Furthermore, the specification for this header has evolved over time. It was implemented as X-Content-Security-Policy in Firefox until version 23 and in IE until version 10, and was implemented as X-Webkit-CSP in Chrome until version 25. Both of the names are deprecated in favor of the now standard name Content Security Policy. Given the number of directives, two deprecated alternate names, and the way multiple occurrences of the same header and repeated directives in a single header are treated, there is a high probability that a developer might misconfigure this header.

Consider the following misconfiguration scenarios:

- Directives with unsafe-inline or unsafe-eval defeats the purpose of CSP.
- script-src directive is set but no script nonce is configured.
- frame-src is set but no sandbox is configured.
- Multiple instances of this header are allowed in same response. A development team and security team might both set a header but one may use one of the deprecated names. While deprecated headers are honored if a header with the latest name (that is, Content Security Policy) is not present, they are ignored if a policy with content-security-header name is present. Older versions only understand deprecated names, hence, in order to achieve desired support it is essential that the response include an identical policy with all three names.
- If a directive is repeated within the same instance of the header, all subsequent occurrences are ignored.

Example 1: The following django-csp configuration uses unsafe-inline and unsafe-eval insecure directives to allow inline scripts and code evaluation:

...
MIDDLEWARE_CLASSES = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

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:

<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.