Struts uses form-bean entries to map HTML forms to actions. If the name attribute in an <action> tag does not correspond with the name of a form-bean, the action cannot be mapped and indicates either a superfluous definition or a typographical error.

Example 1: The following configuration does not contain a mapping for bean2.

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean" />
</form-beans>

<action-mappings>
  <action path="/actions/register1" type="coreservlets.RegisterAction1" name="bean1" scope="request" />
  <action path="/actions/register2" type="coreservlets.RegisterAction2" name="bean2" scope="request" />
</action-mappings>

Every filter mapping must correspond to a valid filter definition in order for it to be applied.

Example 1: The following example shows a filter mapping that references the non-existent filter AuthenticationFilter. Because the definition is missing, the filter AuthenticationFilter will not be applied to the designated URL pattern /secure/* and might cause a runtime exception.

<filter>
    <description>Compresses images to 64x64</description>
    <filter-name>ImageFilter</filter-name>
    <filter-class>com.ImageFilter</filter-class>
</filter>

<!-- AuthenticationFilter is not defined -->
<filter-mapping>
    <filter-name>AuthenticationFilter</filter-name>
    <url-pattern>/secure/*</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>ImageFilter</filter-name>
    <servlet-name>ImageServlet</servlet-name>
</filter-mapping>

The use of ENABLEDEBUGGER and ENABLEDEBUGGER2 enables support for remote debugging and also contains a poorly salted MD5 password hash. The tag does not offer any security guarantees and can be easily circumvented by using any hex editor tool. Not only is the remote debugging protection easily bypassed, the password the developer used to secure the file is easily recoverable. Flash uses a 16-bit salt added to the password and applies the MD5 hash algorithm to it. This is a weak salt and the password can be recovered using password cracking programs.

The absence of a valid servlet mapping prevents all access to the unmapped servlet.

Example 1: The following entry from web.xml defines ExampleServlet but fails to define a corresponding servlet mapping.

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

    <servlet>
      <servlet-name>ExampleServlet</servlet-name>
      <servlet-class>com.class.ExampleServlet</servlet-class>
      <load-on-startup>1</load-on-startup>
    </servlet>

</web-app>

Windows Communication Foundation (WCF) offers the ability to throttle service requests. Allowing too many client requests can flood a system and exhaust its resources. On the other hand, allowing only a small number of requests to a service can prevent legitimate users from using the service. Each service should be individually tuned to and configured to allow the appropriate amount of resources.

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" %>

By default, the .NET framework prevents new line characters from being sent to APIs that set HTTP header values. However, this behavior can be disabled programmatically by setting the EnableHeaderChecking property on the HttpRuntimeSection object to false.

Example 1: The following code disables header checking.

Configuration config = WebConfigurationManager.OpenWebConfiguration("/MyApp");
HttpRuntimeSection hrs = (HttpRuntimeSection) config.GetSection("system.web/httpRuntime");
hrs.EnableHeaderChecking = false;

When this check is disabled, code that allows user input to reach header setting APIs is vulnerable to attacks such as HTTP Response Splitting.

Insecure HTTP header processing exists by setting the useUnsafeHeaderParsing property to true. This setting enables attacks against vulnerable applications because of insufficient validation rules on HTTP headers.

The following validation is NOT performed when this attribute is set to true:

- Use CRLF for end-of-line code. A separate CR or LF is not permitted.
- No spaces in header names.
- All but the first status line is interpreted as a faulty header name/value pair.
- The status line must include a code and a description.

This setting additionally means that certain exceptions concerning prohibited characters will no longer be thrown.

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

...
<configuration>
   <system.net>
   <settings>
      <httpWebRequest useUnsafeHeaderParsing="true" />
   </settings>
   </system.net>
</configuration>
...

A Kubernetes capability permits a Pod to perform named root actions without giving full root access. The CAP_SYS_ADMIN capability grants the permission to perform the widest possible range of system administration operations to a Pod.

Example 1: The following Kubernetes manifest adds the CAP_SYS_ADMIN capability to a container in a Pod.

...
kind: Pod
...
spec:
  containers:
...
    securityContext:
      capabilities:
        add:
        - CAP_SYS_ADMIN
        - SYS_TIME
        ...

Setting the certificate validation mode to None disables the entire certification validation process, which exposes the application to Man-in-the-Middle attacks. This mode should never be used in production environments.

When axis.development.system is set to true in the server configuration file, the system behaves as if it is a development environment. It sends stack traces in SOAP responses that can leak information about the system or application.

Admission controllers validate and customize requests to a Kubernetes API Server. They can implement security controls such as rejecting unauthorized privileged requests, enforcing namespace isolation, limiting excessive resource requests, and many more. The API Server does not validate requests because there is no admission controller or the deprecated AlwaysAdmit admission controller is enabled.

Example 1: The following configuration starts a Kubernetes API server with the AlwaysAdmit admission controller.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=AlwaysAdmit,PodSecurityPolicy
    ...

A Kubernetes API server, the central management entity of a cluster, accepts HTTP Basic Authentication to authenticate users. HTTP Basic Authentication is deprecated and susceptible to brute force attacks and leaks user credentials to attackers in a misconfigured environment.

Example 1: The following configuration starts a Kubernetes API server and sets the --basic-auth-file=<filename>> flag to use HTTP basic authentication.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-apiserver
      - --basic-auth-file=<filename>
    image: example.domain/kube-apiserver-amd64:v1.6.0
    livenessProbe:
...

A Kubernetes API server authenticates requests by comparing bearer tokens to a list kept in a static token file. The token file stores secrets in plaintext and is static in nature. Static token-based authentication is susceptible to brute force attacks and can leak access credentials to attackers in a misconfigured environment. To add, replace, or revoke a token, you must restart the API server.

Example 1: Using the --token-auth-file flag, the following configuration starts a Kubernetes API server that authenticates requests by static tokens.

...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --token-auth-file=<filename>
    ...

A missing or duplicate servlet name in web.xml is an error. Every Servlet should have a unique name (servlet-name) and a corresponding mapping (servlet-mapping).

Example 1: The following entry from web.xml shows several erroneous servlet definitions.

<!-- No <servlet-name> specified: -->
    <servlet>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Empty <servlet-name> node: -->
    <servlet>
        <servlet-name/>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Duplicate <servlet-name> nodes: -->
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-name>Servlet</servlet-name>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

These errors may cause an unintentional denial of access to the Servlet.

ASP .NET applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. The debug attribute of the <compilation> 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.

ASP .NET applications should be configured to use custom error pages instead of the framework default page. The default error page gives detailed information about the error that occurred, and should not be used in production environments. The mode attribute of the <customErrors> tag defines whether custom or default error pages are used.

Attackers may leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application.

ASP.NET applications can be configured to output trace debugging information. Trace output contains details about the request made to the current page, header information, methods, and controls used on the page and the active session state. Attackers may leverage the additional information they gain from trace output to mount attacks targeted on the framework, database, or other resources used by the application.

Trace information is enabled at the page level by setting the Trace attribute of the <page> directive to true or on the application level by adding a trace element in the web.config file and setting its enabled attribute to true.

The use of impersonated credentials allows an ASP.NET application to run with either the privileges of the client on whose behalf it is executing or with arbitrary privileges granted in its configuration.

When axis.disableServiceList is set to false, Apache Axis will return a list of available services when a GET is performed on a servlet root. The service list may contain a list of features that show not be publicly accessible.