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.

If the cacheRolesInCookie attribute of the configuration/system.web/authentication/forms element in web.config is set to true, then the roles for each user are cached in a cookie. 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 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.

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.

This ASP.NET Core application does not configure controllers or controller methods of sensitive nature to only be accessible over a secure connection.

ASP.NET W3Clogger.loggingFields can be configured to allow logging sensitive data such as private and system information.
This data can contain sensitive information related to HTTP requests and HTTP responses such as clients/server IP, server ports, header cookies and authenticated usernames that accessed the server.

In case of data breach, adversary can use this information to:

- Steal sensitive information or impersonate a user with higher privileges.
- Discover internal servers, gain unauthorized access to restricted resources.
- Devise attacks focused on exploiting known vulnerabilities reported against the detected server


Example 1: The following code shows an action method in a controller where validation has been disabled:

  builder.Services.AddW3CLogging(logging =>
    logging.LoggingFields = W3CLoggingFields.All;

    ... )

Example 1 shows how W3Clogging can be configure, using Flag All, to log all possible fields in Http request, including sensitive data such as ClientIpAddress, ServerName, ServerIpAddress, ServerPort, UserName, and Cookie.

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.

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