A Kubernetes controller initiates garbage collection to reclaim resources occupied by terminated Pods when their number exceeds a threshold. Although excessive garbage collection degrades performance, the default threshold of 12500 is too high for a typical cluster. Before any garbage collection occurs, the cluster can run low on resources and become unstable.

Example 1: The following configuration starts a Kubernetes controller manager without specifying a threshold.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-controller-manager
    image: example.domain/kube-controller-manager:v1.9.7
    imagePullPolicy: IfNotPresent
...

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

Insecure authentication methods might allow attackers to gain administrative privileges and orchestrate a complete system compromise.

If profiling is enabled, a component provides performance metrics through a web interface. The performance metrics reveal system data that help an adversary form a plan of attack. Either the --profiling flag is not present in the command to start the component or the flag is set to true.

If profiling is enabled, a component provides performance metrics through a web interface. The performance metrics reveal system data that help an adversary form a plan of attack. Either the --profiling flag is not present in the command to start the component or the flag is set to true.

To maintain backward compatibility, a Kubelet can serve a subset of its APIs at a read-only port without requiring authentication or authorization. Return values of those APIs contain very detailed specifications and performance metrics of the node that the Kubelet serves as well as metadata of Pods deployed to the node.

Example 1: The following configuration sets the Kubelet read-only port to 12345.

...
kind: KubeletConfiguration
...
readOnlyPort: 12345
...

The <login-config> element is used to configure how users authenticate to an application. A missing authentication method means the application does not know how to apply authorization constraints since no one can log in. The authentication method is specified using the <auth-method> tag, which is a child of <login-config>.

There are four authentication methods: BASIC, FORM, DIGEST, and CLIENT_CERT.

BASIC denotes HTTP Basic authentication.
FORM denotes Form-based authentication.
DIGEST is like BASIC authentication; however, in DIGEST the password is encrypted.
CLIENT_CERT requires that clients have Public Key Certificates and use SSL/TLS.

Example 1: The following configuration does not specify a login configuration.

<web-app>

    <!-- servlet declarations -->
    <servlet>...</servlet>

    <!-- servlet mappings-->
    <servlet-mapping>...</servlet-mapping>

    <!-- security-constraints-->
    <security-constraint>...</security-constraint>

    <!-- login-config goes here -->

    <!-- security-roles -->
    <security-role>...</security-role>

</web-app>

Pulling a container image from a registry typically requires authorization. Kubernetes nodes, however, cache all images of previously started containers. An attacker can bypass the required authorization by starting a container with a cached image. The AlwaysPullImages admission controller can prevent this bypass.

Example 1: The following configuration starts a Kubernetes API server without the AlwaysPullImages admission controller in the --enable-admission-plugins flag.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=PodNodeSelector,LimitRanger
    ...

As a convenient debugging option, certain Flex authoring tools allow developers to export Flex projects with the source code files for the project. Failure to disable this access for production files could severely compromise the security of the application. It allows any end user to view the source of the Flex application by right-clicking the running SWF inside the browser and selecting view source. This results in a source disclosure vulnerability. It is recommended that this feature be turned off to avoid unintended access to the source code.

Source code often contains database usernames, passwords and connection strings, and locations of sensitive files. It also reveals the detailed mechanics and design of the application's logic, which can be used to develop other attacks.

Entity beans that expose a remote interface become part of an application's attack surface. For performance reasons, an application should rarely use remote entity beans, so there is a good chance that a remote entity bean declaration is an error.

Example 1: The following entity bean declaration includes a remote interface:

<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>EmployeeRecord</ejb-name>
<home>com.wombat.empl.EmployeeRecordHome</home>
<remote>com.wombat.empl.EmployeeRecord</remote>
...
</entity>
...
</enterprise-beans>
</ejb-jar>

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

Example 1: The following excerpt is an example of using a wildcard to programmatically specify to which domains the application is allowed to communicate.

   flash.system.Security.allowDomain("*");

Using the * as the argument to allowDomain() indicates that the application's data is accessible to other SWF applications from any domain.

ASP.NET Web services facilitate the development of Web services clients by automatically generating documentation that describes how to communicate with the Web service.

Web services that have the documentation protocol enabled generate an HTML-formatted page when a browser request is received.

This HTML-formatted page describes the following information:
1. The operations that are supported
2. The parameters that each operation accepts
3. The type of data that should be passed in those parameters

The documentation protocol also generates an XML-formatted Web Services Description Language (WSDL) file. This file is designed to allow applications to understand how to structure requests to the Web service. This information can be very useful to developers, especially developers who create clients for public Web services. However, revealing detailed information about the functionality of private Web services increases the risk that the Web service will be misused by a malicious attacker. The Documentation protocol always describes all functions and parameters of a Web service -- even if only a subset of those functions are intended to be publicly accessible.

Most web applications use a session identifier to uniquely identify users, which is typically stored in a cookie and transmitted transparently between the server and the web browser.


When the value of the attribute is set to either true or UseUri, the application does not use cookies regardless of whether the browser or device supports cookies. When the value of the attribute is set to either AutoDetect or UseDeviceProfile, the cookies are not used depending on the configuration of the requesting browser or device.

Applications that do not store session identifiers in cookies sometimes transmit them as an HTTP request parameter or as part of the URL. Accepting session identifiers specified in URLs makes it easy for attackers to perform Session Fixation attacks.

Placing session identifiers in URLs can also increase the chances of successful Session Hijacking attacks against the application. Session Hijacking occurs when an attacker takes control of a victim's active session or session identifier. It is common practice for web servers, application servers, and web proxies to store requested URLs. If session identifiers are included in URLs, they are also logged. Increasing the number of places session identifiers are viewed and stored increases the chances they will be compromised by an attacker.

By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. Starting with Flash Player 9,0,124,0, Adobe also introduced the capability to define which custom headers Flash Player can send across domains. However, caution should be taken when defining these settings because an overly permissive custom headers policy, when applied together with the overly permissive cross-domain policy, will allow a malicious application to send headers of their choosing to the target application, potentially leading to a variety of attacks or causing errors in the execution of the application that does not know how to handle received headers.

Example 1: The following configuration shows the use of a wildcard to specify which headers Flash Player can send across domains.

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

Using the * as the value of the headers attribute indicates that any header will be sent across domains.

Adobe Flash has been associated with multiple vulnerabilities since its inception. Many of which can lead to Remote Code Execution and Cross-Site Scripting attacks that can compromise user and/or system data and privacy.

Adobe has deprecated Flash with an end-of-life set to the end of 2020. Many browsers have already disabled Adobe Flash support by default, for example, starting in Chrome 76 and Firefox 69. Furthermore, starting in December 2020, Chrome, Firefox, and Microsoft Edge will completely eliminate support for Flash.
Using a deprecated, possibly vulnerable version of the player to execute an application introduces unnecessary risk. Consider updating your application to replace Adobe Flash with safer, alternative technologies that provide similar functionality such as HTML5, WebGL, and WebAssembly. Use of safe alternative technologies is critical to protect users from known player vulnerabilities including Cross-Site Scripting, and Remote Code Execution (on the client machine).

Always enable the NodeRestriction admission controller for a Kubernetes API server. The NodeRestriction admission controller limits every Kubelet to modify its Node and Pod objects as well as deny access to sensitive system objects. This prevents any compromised node from gaining privileges on other nodes of a Kubernetes cluster.

Example 1: The following Pod definition starts a Kubernetes API server without enabling the NodeRestriction admission controller.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=PodSecurityPolicy
    ...

An information leak occurs when system data or debug information leaves the program through an output stream, logging function, debugger, or profiler. Access to system data can help an adversary form a plan of attack.

Programs can be configured to validate X.509 certificates in one of three ways. By default, certificates are validated through their chain of trust back to a trusted root authority. This setting is known as ChainTrust and provides the maximum level of assurance that the certificate is valid. By default all certificates are validated using ChainTrust.

To make use of a certificate that was not issued by a trusted root authority, a program can be configured to trust certificates issued by its peers by setting either PeerTrust or PeerOrChainTrust. These settings should not be used in production environments because they significantly reduce the level of security granted by certificates.

The longer a session stays open, the larger the window of opportunity an attacker has to compromise user accounts. While a session remains active, an attacker may be able to brute-force a user's password, crack a user's wireless encryption key, or commandeer a session from an open browser. Longer authentication timeouts can also prevent memory from being released and eventually result in a denial of service if a sufficiently large number of sessions are created.

Example 1: The following example shows ASP.NET MVC configured with an hour authentication timeout.

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

If the timeout attribute is not specified the authentication timeout defaults to 30 minutes.

When enabled, the session.use_trans_sid causes PHP to pass the session ID on the URL, which makes it much easier for attackers to hijack active sessions or trick users into using an existing session already under the attackers' control.

Parameters passed on the URL are more visible than POST parameters and cookie values because they often appear in browser histories, bookmarks, log files, and other highly exposed locations. If attackers learn the secret session identifier for an active session on a system, then they could possibly supply the session identifier back to the program in order to hijack the user's session.

Beyond session hijacking, exposing the session ID on the URL also facilitates session fixation attacks. In the canonical exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using that session identifier, giving the attacker access to the user's account through the active session. Passing the session identifier on the URL allows attackers to reach a large number of potential victims by sending URLs that include a compromised session identifier to victims via email or another mass communication mechanism.