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.

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.

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.

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.

The longer a session stays open, the larger the window of opportunity an attacker has to compromise user accounts. While a session remains active, an attacker may be able to brute-force a user's password, crack a user's wireless encryption key, or commandeer a session from an open browser. Longer authentication timeouts can also prevent memory from being released and eventually result in a denial of service if a sufficiently large number of sessions are created.

Example 1: The following example shows ASP.NET MVC configured with an hour authentication timeout.

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

If the timeout attribute is not specified the authentication timeout defaults to 30 minutes.

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

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.

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

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.

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.

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.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.