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

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
}

ASP.NET MVC provides a convenient way to better protect an application against cross-site request forgery by adding an antiforgery token at the form side and validating that antiforgery token at the controller. If used, this token is usually included as a hidden form field and validated when the form is submitted, which increases the chances that a request is from your application and not forged.

The following controller code does not include the built-in defense against cross-site request forgery:

public ActionResult ActionName(Model model, string returnurl)
{
  // ... controller logic
}

ASP.NET MVC provides a convenient way to better protect an application against cross-site request forgery by adding an antiforgery token at the HTML form and validating that antiforgery token at the controller. If used, this token is usually included as a hidden form field and validated when the form is submitted, which increases the chances that a request is from your application and not forged.

Generally, a programmer should include this antiforgery token since it increases the cost of malicious scripting against an application.

Example 1:The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery:

@using (Html.BeginForm(new { ReturnUrl = ViewBag.ReturnUrl })) {
  // ... form elements
}

Example 2::The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery. Note that parameter antiforgery is set to either false or null:

@using (Html.BeginForm("actionName", "controllerName", routeValues, FormMethod.Post, antiforgery: false, htmlAtts)) {
  // ... form elements
}

Using a model class that has properties that are required (as marked with the [Required] attribute) and properties that are optional (as not marked with the [Required] attribute) can lead to problems if an attacker communicates a request that contains more data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties.

Having mixed requiredness without explicitly communicating which parameters are to be model-bound may indicate that there are model properties for internal use but can be controlled by attacker.

The following code defines a possible model class that has properties that have [Required] and properties that do not have [Required]:

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

If any optional parameters can change the behavior of an application, then an attacker may be able to actually change that behavior by communicating an optional parameter in a request.

Using a model class that has non-nullable properties that are required (as marked with the [Required] attribute) can lead to problems if an attacker communicates a request that contains less data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties.

If a model has a required non-nullable parameter and an attacker does not communicate that required parameter in a request -- that is, the attacker uses an under-posting attack -- then the property will have the default value (usually zero) which will satisfy the [Required] validation attribute. This may produce unexpected application behavior.

The following code defines a possible model class that has a required enum, which is non-nullable:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

If a model class has required property and is the type of an optional member of a parent model class, it may be susceptible to under-posting attacks if an attacker communicates a request that contains less data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties, including submodels.

If a submodel is optional -- that is, the parent model has a property without the [Required] attribute -- and if an attacker does not communicate that submodel, then the parent property will have a null value and the required fields of the child model will not be asserted by model validation. This is one form of an under-posting attack.

Consider the following the model class definitions:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

If an attacker does not communicate a value for the ParentModel.Child property, then the ChildModel.RequiredProperty property will have a [Required] which is not asserted. This may produce unexpected and undesirable results.

The NSURLConnectionDelegate.connection(_:willSendRequestFor:) delegate method allows the delegate to make an informed decision about connection authentication at once. If the delegate implements this method, it has no need to implement NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) or NSURLConnectionDelegate.connection(_:didReceive:). In fact, these methods are not invoked, so any security checks on them will be ignored.

Before creating a server trust credential, it is the responsibility of the delegate of an NSURLConnection object, an NSURLSession object or an NSURLDownload object to evaluate the trust chain.

Example 1: The following code initializes an NSURLCredential using a non-evaluated server trust:

-(void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * credential)) completionHandler {
        ...
        [challenge.sender useCredential:[NSURLCredential credentialForTrust: challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
        ...
}

Before creating a server trust credential, it is the responsibility of the delegate of an NSURLConnection object, NSURLSession object or an NSURLDownload object to evaluate the server trust. In order to evaluate the server trust, the SecTrustEvaluate(_:_:) method should be called with the trust obtained from the serverTrust method of the server's NSURLProtectionSpace object.

The SecTrustEvaluate(_:_:) method returns two different values:

- The returned OSStatus value represents the result code.
- The object pointed by the second argument represents the result type of the evaluation.

If the trust is invalid, the authentication challenge should be canceled with cancel(_:).

Example 1: In the following example, the server trust is evaluated but the received credentials are used without checking the result of this evaluation:

SecTrustRef trust = [[challenge protectionSpace] serverTrust];
SecTrustResultType result = kSecTrustResultInvalid;
OSStatus status = SecTrustEvaluate(trust, &result);
completionHandler(NSURLSessionAuthChallengeUseCredential, [challenge proposedCredential]);

An NSURLProtectionSpace object represents a server or an area on a server, commonly referred to as a realm, that requires authentication.
When establishing a URL connection that requires authentication against a protection space, the NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) method will be called right before the call to the NSURLConnectionDelegate.connection(_:didReceive:) method that should perform the authentication. This allows the NSURLConnectionDelegate to inspect the protection space before attempting to authenticate against it. By returning true, the delegate indicates that it can handle the form of authentication, which it does in the subsequent call to connection(_:didReceive:). If your delegate does not implement this method and the protection space uses client certificate authentication or server trust authentication, the system will attempt to use the user's keychain to authenticate which may not be the desired behavior.

The application implements the NSURLConnection or NSURLSession callbacks to handle authentication requests. Forgetting to ensure that the authentication request comes from the expected host would result in credentials being sent to every URL the application loads. In addition, failing to check that the credentials can be sent securely would result in credentials being stolen.

Example 1: The following application sends user credentials to any host asking for authentication:

- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NS URLAuthenticationChallenge *)challenge completionHandler:(void (^)(NS URLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler { 
    NSString *user = [self getUser]; 
    NSString *pass = [self getPassword]; 

    NSURLCredential *cred = [NSURLCredential credentialWithUser:user 
    password:pass persistence:NSURLCredentialPersistenceForSession]; 
    completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
}