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);
}