Kubernetes distinguishes between the concept of a user account and a service account, which is for a process to run in a Pod. The ServiceAccount admission controller automates the service account management. Some benefits of the ServiceAccount admission controller are to mitigate access token exfiltration with automated credential rotation and eliminate the need to persist secrets in storage. The ServiceAccount admission controller is enabled by default but has been deliberately disabled.

Example 1: The following Pod definition starts a Kubernetes API server and disables the ServiceAccount admission controller.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --disable-admission-plugins=ServiceAccount,PodNodeSelector
    ...

By default, a Kubernetes container is denied access to all devices on the host. The privileged field allows the container almost all the same privileges as other processes running on the host. This expands the attack surface and violates the principle of running images with least privileges.

Example 1: The Pod runs in a privileged mode by setting privileged: true.

...
kind: Pod
...
spec:
  containers:
    - name: ...
      image: ...
      securityContext:
         privileged: true
...

Cookies are often used to store important information about users, such as personal information, authentication tokens and a history of their activity. If this information is stored in plain text, anyone with access to machines used to interact with the application will have access to the information stored in the cookie. Worse yet, if attackers are allowed to arbitrarily modify the data stored in cookies, they can falsify information provided to the application and potentially alter its behavior to their advantage.

In many cases, an application can validate input from cookies programmatically according to the context in which it is used, but the ASP.NET validation framework provides an excellent way to both protect the contents of the cookie and to verify that the cookie has not been modified unexpectedly. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.

Cookies are often used to store important information about users, such as personal information, authentication tokens and a history of their activity. If this information is stored in plain text, anyone with access to machines used to interact with the application will have access to the information stored in the cookie. Worse yet, if attackers are allowed to arbitrarily modify the data stored in cookies, they can falsify information provided to the application and potentially alter its behavior to their advantage.

In many cases, an application can validate input from cookies programmatically according to the context in which it is used, but the ASP.NET validation framework provides an excellent way to both protect the contents of the cookie and to verify that the cookie has not been modified unexpectedly. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.

By default, ASP.NET internally validates the cryptographic signatures before decrypting payloads such as ViewState, FormsAuth cookies, and ScriptResource.axd URLs and passes those values to the application for further processing. However, this functionality can be modified using the aspnet:UseLegacyEncryption setting to disable the cryptographic signature verification before decrypting payloads. This may allow a malicious client to decrypt, forge, or otherwise tamper with encrypted data.

Example 1: In the following example, aspnet:UseLegacyEncryption is set to true.

...
  <appSettings>
    <add key="aspnet:UseLegacyEncryption" value="true" />
  </appSettings>
...

When a Dockerfile does not specify a USER, Docker containers run with super user privileges by default. These super user privileges are propagated to the code running inside the container, which is usually more permission than necessary. Running the Docker container with super user privileges broadens the attack surface which might enable attackers to perform more serious forms of exploitation.

The SecurityContextDeny admission controller prevents Pods from setting certain SecurityContext fields that allow for privilege escalation in a Kubernetes cluster. Unless there is an alternative policy enforcement tool for Kubernetes, such as appropriate Pod security policies, the SecurityContextDeny admission controller should be enabled.

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

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

Allowing Servlets to be served by their class name allows any attacker who knows a Servlet's name to invoke it directly, even when it is not mapped in the application's deployment descriptor.

For example, consider an application that contains a Servlet named com.ibm.websphere.samples.MyServlet. When serveServletsByClassnameEnabled in ibm-web-ext.xmi (for WAS V6 and earlier) or enable-serving-servlets-by-class-name in ibm-web-ext.xml (from WAS V7 onwards) is set to true, it is possible to call the servlet by requesting:
http://www.example.com/SomeContextPath/servlet/com.ibm.websphere.samples.MyServlet.

Worse, depending on the server's classloader structure, an attacker may be able to invoke Servlets from other applications hosted in the same WebSphere instance.

When enabled, the allow_url_include option allows PHP functions that specify a file for inclusion in the current page, such as include() and require(), to accept an HTTP or FTP URL to a remote file. The option, which was introduced in PHP 5.2.0 and is disabled by default, is dangerous because it can allow attackers to introduce malicious content into an application. At best, including remote files leaves the application susceptible to attackers who alter the remote file to include malicious content. At worst, if attackers can control a URL that the application uses to specify the remote file to include, then they can inject arbitrary malicious content into the application by supplying a URL to a remote server.

By default, a Kubernetes container runtime prevents applications from writing to the root file system of the container. The readOnlyRootFilesystem: false setting disables this restriction, which allows an attacker to tamper with the local file system or write malicious executable to disk.

Example 1: The following manifest sets the readOnlyRootFilesystem field to false, which permits applications inside a container to write data to the local disk.

...
kind: Pod
...
spec:
  containers:
  - name: ...
    ...
    securityContext:
    readOnlyRootFilesystem: false
    ...

Kubernetes keeps sensitive data in an etcd cluster. Therefore, every etcd instance should only accept connections from authenticated and authorized clients and reject any client that uses a self-signed certificate for TLS connections.

Example 1: The following configuration starts an etcd instance and sets the --auto-tls flag to true. As a result, the etcd instance uses self-signed certificates for TLS connections with clients.

...
spec:
  containers:
  - command:
...
    - etcd
    ...
    - --auto-tls=true
    ...

When enabled, the allow_url_fopen option allows PHP functions that accept a filename to operate on remote files using an HTTP or FTP URL. The option, which was introduced in PHP 4.0.4 and is enabled by default, is dangerous because it can allow attackers to introduce malicious content into an application. At best, operating on remote files leaves the application susceptible to attackers who alter the remote file to include malicious content. At worst, if attackers can control a URL that the application operates on, then they can inject arbitrary malicious content into the application by supplying a URL to a remote server.

Example 1: The following code opens a file whose name is controlled by a request parameter and reads its contents. Because the value of $file is controlled by a request parameter, an attacker could violate the programmer's assumptions by providing a URL to a remote file.

<?php
$file = fopen ($_GET["file"], "r");
if (!$file) {
    // handle errors
}
while (!feof ($file)) {
    $line = fgets ($file, 1024);
    // operate on file content
}
fclose($file);
?>

Android applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. The debuggable attribute of the <application> tag defines whether compiled binaries should include debugging information.

The use of debug binaries causes an application to provide as much information about itself as possible to the user. Debug binaries are meant to be used in a development or testing environment and can pose a security risk if they are deployed to production. Attackers may leverage the additional information they gain from debugging output to mount attacks targeted on the framework, database, or other resources used by the application.

Unchecked input is the leading cause of vulnerabilities in ASP.NET applications. Unchecked input can lead to numerous vulnerabilities, including cross-site scripting, process control, and SQL injection.

To prevent such attacks, use the ASP.NET validation framework to check all program input before it is processed by the application.

Example uses of the validation framework include checking to ensure that:

- Phone number fields contain only valid characters in phone numbers
- Boolean values are only "T" or "F"
- Free-form strings are of a reasonable length and composition

CakePHP can be configured to expose debugging information that includes errors, warnings, SQL statements, and stack traces. Debug information should not be used in production environments.

Example 1:

    Configure::write('debug', 3);

The second parameter to the Configure::write() method indicates the debug level. The higher the number, the more verbose the log messages.

If you are using Tomcat to perform authentication, the Tomcat deployment descriptor file specifies a "Realm" used for authentication. It looks like the following:

Example 1:

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

This Realm tag takes an optional attribute called debug, which indicates the log level. The higher the number, the more verbose the log messages. If the debug level is set too high, Tomcat will write all usernames and passwords in plain text to the log file. The cutoff for debugging messages related to Tomcat's JAASRealm is 3 (3 or greater is bad, 2 or less is okay), but this cutoff may vary for the other types of realms that Tomcat provides.

Windows Communication Framework (WCF) services can be configured to expose debugging information. Debug information should not be used in production environments. The <serviceDebug> tag defines whether the debug information feature is enabled for a WCF service.



If the attribute includeExceptionDetailInFaults is set to true, exception information from the application will be returned to clients. Attackers may leverage the additional information they gain from debugging output to mount attacks targeted on the framework, database, or other resources used by the application.

Example: The following configuration file includes the <serviceDebug> tag:

<configuration>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServiceBehavior">
          <serviceDebug includeExceptionDetailInFaults="True" httpHelpPageEnabled="True"/>
...

The <authorization> element specifies a list of authorization rules. If an <authorization> element exists and no rules apply to a sender, access is denied [1].
In this case, no <authorization> tag exists in the identified configuration file and anonymous access might be possible.

Starting with Flash Player 7, SWF applications loaded over HTTP are not allowed to access data of SWF applications loaded over HTTPS by default. Adobe Flash allows developers to alter this restriction either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when defining these settings because HTTP loaded SWF applications are subject to man-in-the-middle attacks, and thus should not be trusted.

Example 1: The following code calls allowInsecureDomain(), which turns off the restriction that prevents HTTP loaded SWF applications from accessing the data of HTTPS loaded SWF applications.

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

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.