Strict Contextual Escaping (SCE) is a mechanism in AngularJS applications that helps protect the application from attackers. This can prevent many attack vectors across different types of vulnerabilites. The most prominent protection is against certain types of cross-site scripting attacks. In this application, this protection mechanism is specifically disabled.

Example 1: In this example we disable SCE on a module.

myModule.config(function($sceProvider){
  $sceProvider.enabled(false);
});

The application uses code that enables the permessage-deflate WebSocket extension which allows for compression over encrypted connections. Enabling this type of compression makes the application subject to the CRIME and BREACH type of attacks.

Example 1: The following code sets DangerousEnableCompression to true in order to enable the 'per-message-deflate' extension:

    app.Run(async context => {
        using var websocket = await context.WebSockets.AcceptWebSocketAsync(new WebSocketAcceptContext() { DangerousEnableCompression = true });
        await websocket.SendAsync(...);
        await websocket.ReceiveAsync(...);
        await websocket.CloseAsync(WebSocketCloseStatus.NormalClosure, null, default);
    });
    

Example 2: The following code uses DangerousDeflateOptions to set the options for the 'per-message-deflate' extension:

    using ClientWebSocket ws = new() {
        Options = {
            CollectHttpResponseDetails = true,
            DangerousDeflateOptions = new WebSocketDeflateOptions() {
                ClientMaxWindowBits = 10,
                ServerMaxWindowBits = 10
            }
        }
    };
    

Microsoft ASP.NET applications can impersonate the security context of the current user or the process that invoked them in order to execute privileged operations. Although impersonation contexts serve a variety of useful purposes, such as reducing the overall number of authentication attempts that must be made, a program that retains elevated privileges unnecessarily poses a risk to the overall security of the system. If an attacker exploits another vulnerability in the program while it is running in another security context, any unauthorized operations the attacker performs will be executed with the corresponding privileges.

Example 1: The following code example represents a typical use pattern for impersonating credentials using the WindowsIdentity.Impersonate() method.

using System.Security.Principal;
...

//Get the identity of the current user
IIdentity contextId = HttpContext.Current.User.Identity;
WindowsIdentity userId = (WindowsIdentity)contextId;

//Temporarily impersonate
WindowsImpersonationContext imp = userId.Impersonate();

//Perform tasks using the caller's security context
DoSecuritySensitiveTasks();

//Clean up and restore our old security context
impersonate.Undo();

The code in Example 1 impersonates the current user's security context and uses it to perform a privileged operation. After calling DoSecuritySensitiveTasks(), the code attempts to restore the original security context, but if DoSecuritySensitiveTasks() throws an exception, the Undo() method will never be called and the program will continue to use the impersonated security context.

Event validation is an ASP.NET security feature that validates the event controls in postback requests to ensure that the controls are the same as when they were rendered during the initial page load. When this feature is disabled, attackers might carry out Cross-Site Request Forgery attacks with tampered event controls, leading to unauthorized accesses, Cross-Site Scripting attacks, etc.

Example 1: The following web app configuration disables event validation.

...
<system.web>
    ...
    <pages enableEventValidation="false">
    ...
    </pages>
</system.web>

Example 2: The following server page directive disables event validation.

<%@ Page ... EnableEventValidation="false" %>

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.

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.

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.

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

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

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

The tx.origin global variable holds the address of the account from where a transaction originates.

If a smart contract, S1, receives a transaction from an account, A1, and then S1 calls another smart contract, S2, then inside S2, tx.origin contains the address of account, A1, used for calling S1. If the intent of tx.origin is to verify authorization of A1, then this authorization is bypassed.

Now, if an attacker can trick a user into sending a transaction into a malicious contract that them invokes the vulnerable contract where the user is authorized via tx.origin, then tx.origin will hold the address of the user account that initiated the transaction and authorization will be bypassed.

Example 1: The following code requires the owner of the contract (previously set in the constructor) to be the same as tx.origin before transferring funds to a provided address.

If an attacker is able to trick the owner of the contract into sending a transaction to a malicious contract which immediately calls the sendTo function in the vulnerable contract, then the condition within the require statement will be true and funds will be transferred to whatever address the attacker contract specified when calling sendTo.

function sendTo(address receiver, uint amount) public {
    require(tx.origin == owner);
    receiver.transfer(amount);
}

Loose access configurations unnecessarily 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 (e.g Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following Ansible task defines an AWS Security Group that opens to the world (0.0.0.0/0) the TCP port 22, where an SSH server typically responds to incoming connection requests.

- name: Task to open SSH port
  amazon.aws.ec2_group:
    name: demo_security_group
    description: Open the ssh port to the world
    state: present
    vpc_id: 123456
    region: us-west-1
    rules:
    - proto: tcp
        ports: 22
        cidr_ip: 0.0.0.0/0

A wildcard configuration for lambda principals violates the least privilege principle and allows an attacker to invoke the lambda from any account.

Example 1: The following example Ansible task defines a wildcard lambda principal.

- name: Create Lambda policy statement for S3 event notification
  community.aws.lambda_policy:
    action: lambda:InvokeFunction
    function_name: functionName
    principal: *
    statement_id: lambda-s3-demobucket-access-log
    source_arn: arn:aws:s3:us-west-2:123456789012:demobucket
    source_account: 123456789012
    state: present