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.

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
}

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.