Microsoft ASP.NET applications can impersonate the security context of the current user or the process that invoked them in order to execute privileged operations. Although impersonation contexts serve a variety of useful purposes, such as reducing the overall number of authentication attempts that must be made, a program that retains elevated privileges unnecessarily poses a risk to the overall security of the system. If an attacker exploits another vulnerability in the program while it is running in another security context, any unauthorized operations the attacker performs will be executed with the corresponding privileges.

Example 1: The following code example represents a typical use pattern for impersonating credentials using the WindowsIdentity.Impersonate() method.

using System.Security.Principal;
...

//Get the identity of the current user
IIdentity contextId = HttpContext.Current.User.Identity;
WindowsIdentity userId = (WindowsIdentity)contextId;

//Temporarily impersonate
WindowsImpersonationContext imp = userId.Impersonate();

//Perform tasks using the caller's security context
DoSecuritySensitiveTasks();

//Clean up and restore our old security context
impersonate.Undo();

The code in Example 1 impersonates the current user's security context and uses it to perform a privileged operation. After calling DoSecuritySensitiveTasks(), the code attempts to restore the original security context, but if DoSecuritySensitiveTasks() throws an exception, the Undo() method will never be called and the program will continue to use the impersonated security context.

The Access-Control-Allow-Methods header, as reflected in the preflight response for the requested resource, indicates that it allows unsafe HTTP methods. An attacker can use HTTP methods such as PUT or DELETE to make unexpected modifications to a shared resource and pose a security threat to the overall site security. A user agent rejects any request for this resource with an HTTP method other than the ones that are listed in the Access-Control-Allow-Methods response header.
Cross-Origin Resource Sharing (CORS), allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. Therefore, execution and incorporation of remote methods and functions hosted on domains outside of the current domain are effectively prohibited. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

- Access-Control-Allow-Origin
- Access-Control-Allow-Headers
- Access-Control-Allow-Methods

In Web Cache Poisoning (WCP) the attacker exploits the behavior of caches. This is done by exploiting multiple mechanisms. Some of which include identifying unkeyed inputs such as headers. Unkeyed inputs are used to construct the response but are not the part of cache key.
Web cache ignores the unkeyed input when sending responses. Therefore, it sends the malicious responses that the attacker had cached with the help of these unkeyed inputs.
The unkeyed inputs can be reflected in the response or can be used to dynamically generate responses.
Another mechanism uses fat GET requests. Fat GET requests are GET requests with a request body. An attacker can duplicate a query parameter in the request body with attacker-controlled value and trick an application into responding differently. An intermediate cache might ignore such a request body when caching the response and respond with a cached fat GET response when a normal request arrives.

WCP is possible through a variety of methods including unkeyed headers, fat GET requests, unkeyed ports, unkeyed query parameters, and more.

Third-party applications, application servers, and web frameworks with known vulnerabilities expand the attack surface available to the attacker.

Sticky broadcasts cannot be secured with a permission and therefore are accessible to any receiver. If these broadcasts contain sensitive data or reach a malicious receiver, the application may be compromised.

Example 1: The following code sends a sticky broadcast.

...
context.sendStickyBroadcast(intent);
...

Omitting validation for even a single input field can allow attackers the leeway they need.

Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

Some applications use the same ActionForm for more than one purpose. In situations such as this, some fields may go unused under some action mappings. It is critical that unused fields be validated too. Preferably, unused fields should be constrained so that they can only be empty or undefined. If unused fields are not validated, shared business logic in an action could allow attackers to bypass the validation checks that are performed for other uses of the form.

If a Struts Action Form Mapping specifies a form, it must have a validation form defined under the Struts Validator. If an action form mapping does not have a validation form defined, it might be vulnerable to a number of attacks that rely on unchecked input.

Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

An action or a form may perform validation in other ways, but the Struts Validator provides an excellent way to verify that all input receives at least a basic level of checking. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.

Active user sessions can be compromised by:
- Disclosure of session cookies enabling session hijacking attacks
- Insecure caching policies that could instruct proxy servers to store web page responses containing authenticated session information
- Cache-control header is defined as public, all intermediate proxy servers and gateways between the client and server are permitted to cache web pages served by the application.
- Attackers can use unexpired session identifiers disclosed in the cached cookies to masquerade as legitimate users and steal personal data belonging to the victim of the session hijacking attack

Cross-Origin Resource Sharing (CORS) allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browsers restricted XHR requests to abide by the same origin policy. This policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. However, a few HTML tags, such as SCRIPT, IMG, and IFRAME, are exempt from the same origin policy and allow remote content to be loaded from a different domain. These are secure alternatives for the site that load content from remote domains and require no special permission or cross-domain policy from the hosting domain.
While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically communicated in specialized response headers, such as:

- Access-Control-Allow-Origin
- Access-Control-Allow-Headers
- Access-Control-Allow-Methods

However, caution should be taken when defining these headers because an overly permissive policy configured at the server level for a domain or directory on a domain can open more content for cross domain access than intended. CORS can allow a malicious application to communicate with victim applications, which can lead to information disclosure, spoofing, data theft, relay, or other attacks.
Implementing CORS can increase an application's attack surface and should be used only when necessary.

Receiver registered without the broadcaster permission will receive messages from any broadcaster. If these messages contain malicious data or come from a malicious broadcaster, the application may be compromised.

Example 1: The following code registers a receiver without specifying the broadcaster permission.

...
context.registerReceiver(broadcastReceiver, intentFilter);
...

Broadcasts sent without the receiver permission are accessible to any receiver. If these broadcasts contain sensitive data or reach a malicious receiver, the application may be compromised.

Example 1: The following code sends a broadcast without specifying the receiver permission.

...
context.sendBroadcast(intent);
...

An application should only have the minimum permissions required for its proper execution. Extra permissions might deter users from installing the application. This permission might be unnecessary for this program.

The application fails to define limits and constraints for the type of data received from a web form. It is a good practice to define a set of constraints, such as the maximum and minimum length, which the received data needs to meet.


Example 1: The following code defines a form but fails to define the data constraints:

  def form = Form(
    mapping(
      "name" -> text,
      "age" -> number
    )(UserData.apply)(UserData.unapply)
  )

Unchecked input is the leading cause of vulnerabilities in J2EE applications. Unchecked input can lead to numerous vulnerabilities, including cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

To prevent such attacks, use the Struts Validator to check all program input before it is processed by the application. Use Fortify Static Code Analyzer to ensure that there are no holes in your configuration of the Struts Validator.

Example uses of the validator 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

Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, culls through it, and communicates it back to the attacker. HTML5 makes it possible for JavaScript to access data across domains if a new HTTP header called Access-Control-Allow-Origin is defined. With this header, a Web server defines which other domains are allowed to access its domain using cross-origin requests. However, exercise caution when defining the header because an overly permissive CORS policy can enable a malicious application to inappropriately communicate with the victim application, which can lead to spoofing, data theft, relay, and other attacks.

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

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

Using the * as the value of the Access-Control-Allow-Origin header indicates that the application's data is accessible to JavaScript running on any domain.

APIs only intended for debug purposes are used.

If you do not want to include all of the hubs and methods in the JavaScript proxy file for each user, you can disable the automatic generation of the file. You might choose this option if you have multiple hubs and methods, but do not want every user to be aware of all of the methods.

The application uses code that enables the permessage-deflate WebSocket extension which allows for compression over encrypted connections. Enabling this type of compression makes the application subject to the CRIME and BREACH type of attacks.

Example 1: The following code sets DangerousEnableCompression to true in order to enable the 'per-message-deflate' extension:

    app.Run(async context => {
        using var websocket = await context.WebSockets.AcceptWebSocketAsync(new WebSocketAcceptContext() { DangerousEnableCompression = true });
        await websocket.SendAsync(...);
        await websocket.ReceiveAsync(...);
        await websocket.CloseAsync(WebSocketCloseStatus.NormalClosure, null, default);
    });
    

Example 2: The following code uses DangerousDeflateOptions to set the options for the 'per-message-deflate' extension:

    using ClientWebSocket ws = new() {
        Options = {
            CollectHttpResponseDetails = true,
            DangerousDeflateOptions = new WebSocketDeflateOptions() {
                ClientMaxWindowBits = 10,
                ServerMaxWindowBits = 10
            }
        }
    };
    

More than one field validator definition with the same name exist in ActionClass-validation.xml. Duplicate validation definitions with the same name may result in unexpected behavior.

Example 1: The following entry shows two duplicate field validator definitions.

   <field name="emailField">
      <field-validator type="email" short-circuit="true">
          <message>You must enter a value for email.</message>
      </field-validator>
      <field-validator type="email" short-circuit="true">
          <message>Not a valid email.</message>
      </field-validator>
  </field>
  

It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

More than one ActionClass-validation.xml file was discovered for this Struts2 Action definition. For each Struts2 Action defined in the form of ActionClass, Struts2 searches for a corresponding ActionClass-validation.xml for the necessary validation constraints. Having multiple validation definitions for one Action included in the deployment may result in unexpected behavior.

If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations. Moreover, it indicates that the validation logic is not being maintained, and can indicate that other, more subtle, validation errors are present.

It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.