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.

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.

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, the role information for each user is cached in a cookie. By default, ASP.NET applications encrypt the cookie and validate the cookie content when sending it to the server. However, cookie protection can be weakened by setting the CookieProtection attribute to Validation or Encryption, which disables either the encryption step or or the validation step. If the encryption step is disabled, anyone with access to machines used to interact with the application have access to the role information stored in the cookie. If the validation step is disabled, attackers can potentially modify the data stored in cookies and falsify information provided to the application and potentially alter its behavior to their advantage.

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

ASP.NET applications can store user name and password pairs in <credentials> elements in the web.config file for an ASP.NET application, which supports plain text, MD5 and SHA1 password formats.

Passwords stored in plain text or using a weak encryption algorithm are accessible to anyone with the access to the application's configuration files. This may include the machine where the application is hosted or the source code repository where the application lives.

Example 1: The following web.config entry incorrectly stores its passwords in plain text.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET supports credential passwords stored in three formats, specified by the passwordFormat attribute of the configuration/system.web/authentication/forms/credentials element. The possible values for this attribute are:

Clear - indicates that the password is stored in plain text (least secure)
MD5 - indicates that the password's MD5 hash is stored
SHA1 - indicates that the password's SHA1 hash is stored (most secure)

While an MD5 hash is more secure than plain text, researchers have found brute-force attacks against the MD5 hashing algorithm. At this time, a SHA1 hash still provides reasonable protection against such attacks.

The FormsAuthentication.RedirectFromLoginPage() method issues an authentication ticket, which allows users to remain authenticated for a specified period of time. When the method is invoked with the second argument false, it issues a temporary authentication ticket that remains valid for a period of time configured in web.config. When invoked with the second argument true, the method issues a persistent authentication ticket. On .NET 2.0, the lifetime of the persistent ticket respects the value in web.config, but on .NET 1.1, the persistent authentication ticket has a ridiculously long default lifetime -- fifty years.

Allowing persistent authentication tickets to survive for a long period of time leaves users and the system vulnerable in the following ways:

It expands the period of exposure to session hijacking attacks for users who fail to log out.

It increases the average number of valid session identifiers available for an attacker to guess.

It lengthens the duration of exploit when an attacker succeeds in hijacking a user's session.

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

If the cacheRolesInCookie attribute of the configuration/system.web/authentication/forms element in web.config is set to true, the role information for each user is cached in a cookie. By default, ASP.NET applications encrypt the cookie and validate the cookie content when sending it to the server. However, cookie protection can be disabled by setting the CookieProtection attribute to None. In this case, anyone with access to the machines used to interact with the application have access to the role 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.

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.

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.

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

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.

In ASP.NET, the view state is a mechanism to persist state in web forms across postbacks. Data stored in the view state is not trustworthy because there is no mechanism for preventing replay attacks. Trusting the view state is particularly dangerous when the view state message authentication check is disabled. Disabling this check allows attackers to make arbitrary changes to the data stored in the view state and can open the door for attacks against code that trusts the view state. Attackers might use this kind of error to defeat authentication checks or alter item pricing.
Example 1: The following code disables view state message authentication checks.

Page.EnableViewStateMac = false;

ASP.NET applications can store user name and password pairs in <credentials> elements in the web.config file for an ASP.NET application, which supports plain text, MD5 and SHA1 password formats.

Passwords stored in plain text or using a weak encryption algorithm are accessible to anyone with the access to the application's configuration files. This may include the machine where the application is hosted or the source code repository where the application lives.

Example 1: The following web.config entry incorrectly stores its passwords in plain text.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET supports credential passwords stored in three formats, specified by the passwordFormat attribute of the configuration/system.web/authentication/forms/credentials element. The possible values for this attribute are:

Clear - indicates that the password is stored in plain text (least secure)
MD5 - indicates that the password's MD5 hash is stored
SHA1 - indicates that the password's SHA1 hash is stored (most secure)

While an MD5 hash is more secure than plain text, researchers have found brute-force attacks against the MD5 hashing algorithm. At this time, a SHA1 hash still provides reasonable protection against such attacks.

ASP.NET MVC controller actions that modify data by writing, updating, or deleting could benefit from being restricted to accept one of the following HTTP verbs: Post, Put, Patch, or Delete. This increases the difficulty of cross-site request forgery because accidental clicking of links will not cause the action to execute.

The following controller action by default accepts any verb and may be susceptible to cross-site request forgery:

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}