SAP system provides for extensive authorization configuration and access management. System level configuration is also available to restrict permissions based on the system role. Together, these features make user or system dependent programming irrelevant. That is, there cannot be a scenario in a securely configured customer productive system where functionality of a program is dependent on the user executing the program or the system on which the program is being executed. Querying user or system details to influence program flow is therefore a bad practice and can indicate the presence of a possible backdoor.

The HttpRequest class provides programmatic access to variables from the QueryString, Form, Cookies or ServerVariables collections in the form of an array access (e.g. Request["myParam"]). When more than one variable exists with the same name, the .NET framework returns the value of the variable that appears first when the collections are searched in the following order: QueryString, Form, Cookies then ServerVariables. Since QueryString comes first in the search order, it is possible for QueryString parameters to supersede values from forms, cookies, and server variables. Similarly, form values can supersede variables in the Cookies and ServerVariables collections and variables from the Cookies collection can supersede those from ServerVariables.
Example 1: Imagine a banking application temporarily stores a user's email address in a cookie and reads this value when it wants to contact the user. The following code reads the cookie value and sends an account balance to the specified email address.

...
    String toAddress = Request["email"];        //Expects cookie value
    Double balance = GetBalance(userID);
    SendAccountBalance(toAddress, balance);
...

Assume the code in Example 1 is executed when visiting http://www.example.com/GetBalance.aspx. If an attacker can cause an authenticated user to click a link that requests http://www.example.com/GetBalance.aspx?email=evil%40evil.com, an email with the user's account balance will be sent to evil@evil.com.

The HttpRequest class provides programmatic access to variables from the QueryString, Form, Cookies or ServerVariables collections in the form of an array access (e.g. Request["myParam"]). When more than one variable exists with the same name, the .NET framework returns the value of the variable that appears first when the collections are searched in the following order: QueryString, Form, Cookies then ServerVariables. Since QueryString comes first in the search order, it is possible for QueryString parameters to supersede values from forms, cookies, and server variables. Similarly, form values can supersede variables in the Cookies and ServerVariables collections and variables from the Cookies collection can supersede those from ServerVariables.
Example 1: The following code checks the HTTP Referer header server variable to see if the request came from www.example.com before serving content.

    ...
    if (Request["HTTP_REFERER"].StartsWith("http://www.example.com"))
        ServeContent();
    else
        Response.Redirect("http://www.example.com/");
    ...

Assume the code in Example 1 is executed when visiting http://www.example.com/ProtectedImages.aspx. If an attacker makes a direct request to the URL, the appropriate referer header will not be set and the request will fail. However, if the attacker submits an artificial HTTP_REFERER parameter with the necessary value, such as http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com, then the lookup will return the value from QueryString instead of ServerVariables and the check will succeed.

A service that does not authenticate its clients allows access to all comers.

A service that does not authenticate its clients allows access to all comers.

Windows Communication Framework (WCF) services can be configured to expose debugging information. Debug information should not be used in production environments. The <serviceDebug> tag defines whether the debug information feature is enabled for a WCF service.



If the attribute includeExceptionDetailInFaults is set to true, exception information from the application will be returned to clients. 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.

Example: The following configuration file includes the <serviceDebug> tag:

<configuration>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServiceBehavior">
          <serviceDebug includeExceptionDetailInFaults="True" httpHelpPageEnabled="True"/>
...

If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel.

If WCF is configured not to throw an exception when it is unable to write to an audit log, the program will not be notified of the failure and auditing of critical security events may not occur.

Example 1: The <behavior/> element of the following WCF configuration file instructs WCF to not notify the application when WCF fails to write to an audit log.

<behaviors>
   <serviceBehaviors>
      <behavior name="NewBehavior">
         <serviceSecurityAudit auditLogLocation="Application"
             suppressAuditFailure="true"
             serviceAuthorizationAuditLevel="Success"
             messageAuthenticationAuditLevel="Success" />
      </behavior>
   </serviceBehaviors>
</behaviors>

Windows Communication Foundation (WCF) offers the ability to log successful and/or failed authentication attempts. Logging failed authentication attempts can warn administrators of potential brute-force attacks. Similarly, logging successful authentication events can provide a useful audit trail when a legitimate account is compromised.

WCF services can be configured to expose metadata. Metadata gives detailed service description information and should not be broadcast in production environments. The HttpGetEnabled / HttpsGetEnabled properties of the ServiceMetaData class defines whether a service will expose the metadata.
Example 1: The following code instructs WCF to broadcast a service's metadata.

    ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
    smb.HttpGetEnabled = true;
    smb.HttpGetUrl = new Uri(EndPointAddress);
    Host.Description.Behaviors.Add(smb);

If authentication is not used to connect to an MSMQ queue used to deliver a message to another program, an attacker could submit an anonymous message that is malicious.

Example 1: The <netMsmqBinding/> element of the following WCF configuration file instructs WCF to disable authentication when connecting to an MSMQ queue for message delivery.

    <bindings>
      <netMsmqBinding>
        <binding>
          <security>
            <transport msmqAuthenticationMode="None" />
          </security>
        </binding>
      </netMsmqBinding>
    </bindings>

Programs that transmit messages without transport or message security cannot guarantee the integrity or confidentiality of the messages. When a WCF security binding is set to None, both transport and message security are disabled.

Example 1: The following code sets the security mode of a WCF Basic HTTP Binding for a fictitious Widget Service to None.

BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;

ServiceHost serviceHost = new ServiceHost(typeof(Widget), baseAddress);
serviceHost.AddServiceEndpoint(typeof(Widget), binding, new URI("ExposureAddress"));

The <serviceMetadata> tag enables the metadata publishing feature. Service metadata could contain sensitive information that should not be publicly accessible.

Windows Communication Foundation (WCF) offers the ability to throttle service requests. Allowing too many client requests can flood a system and exhaust its resources. On the other hand, allowing only a small number of requests to a service can prevent legitimate users from using the service. Each service should be individually tuned to and configured to allow the appropriate amount of resources.

Transport security specifies that confidentiality, integrity, and authentication are provided by transport-layer mechanisms (such as HTTPS). When using a transport like HTTPS, this mode has the advantage of being efficient in its performance and well understood because of its prevalence on the Internet. The disadvantage is that this kind of security is applied separately on each hop in the communication path, making the communication susceptible to a man-in-the-middle attack. WCF offers two other transfer security modes, both of which are preferable: message and transport with message credential. Message security uses the WS-Security specification to ensure confidentiality, integrity, and authentication at the message level. This provides end-to-end security and flexibility in transport methods. However, it reduces performance.

The final method, transport with message credential, is a hybrid of transport and method. Message security is used to authenticate the client and transport security is used to authenticate the server and provide confidentiality, and integrity. It is nearly as efficient as pure transport security.

When a client calls a particular WCF service, WCF provides various authorization schemes that verify that the caller has permission to execute the service method on the server. If authorization controls are not enabled for WCF services, an authenticated user can achieve privilege escalation.

Example 1: The following code instructs WCF to not check the authorization level of the client when executing the service:

    ServiceHost myServiceHost = new ServiceHost(typeof(Calculator), baseUri);
    ServiceAuthorizationBehavior myServiceBehavior =
    myServiceHost.Description.Behaviors.Find<ServiceAuthorizationBehavior>();
    myServiceBehavior.PrincipalPermissionMode =
        PrincipalPermissionMode.None;

The certificate revocation list (CRL) is an optional component of a public key infrastructure (PKI) deployment that is created and signed by a certification authority and contains a list of certificates that it has issued and later revoked. Certificates can be revoked by a certification authority administrator, for example, if an issued certificate is known or suspected to be compromised.

Example 1: In the following example, a service behavior is configured to perform no revocation checking when authenticating a certificate.

<behavior name="DefaultBehavior" returnUnknownExceptionsAsFaults="false">
  <serviceCredentials>
    <serviceCertificate
      x509FindType="FindBySubjectName"
      findValue="MyCertificate"
      storeLocation="LocalMachine"
      storeName="My"/>
    <clientCertificate>
      <authentication certificateValidationMode="ChainTrust" revocationMode="None"/>
    </clientCertificate>
  </serviceCredentials>
  <metadataPublishing enableGetWsdl="true" enableMetadataExchange="true" enableHelpPage="true"/>
</behavior>

The program references a user-defined class that is not uniquely identified. When .NET loads this weakly identified class, the CLR type loader searches for the class in the following locations in the specified order:

- If the assembly of the type is known, the loader searches the configuration file's redirect locations, GAC, the current assembly using configuration information, and the application base directory.

- If the assembly is unknown, the loader searches the current assembly, mscorlib, and the location returned by the TypeResolve event handler.

This CLR search order can be modified with hooks such as the Type Forwarding mechanism and the AppDomain.TypeResolve event.

If an attacker exploits the CLR search order by creating an alternative class with the same name and placing it in an alternative location that the CLR will load first, the CLR will unintentionally execute the attacker-supplied code.

Example 1: The <behaviorExtensions/> element of the following WCF configuration file instructs WCF to add a custom behavior class to a particular WCF extension.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name="myBehavior" type="MyBehavior" />
       </behaviorExtensions>
    </extensions>
</system.serviceModel>

Service Providers that use the UsernameToken might accept passwords sent in plain text. Sending plain text passwords over an unencrypted channel can expose the credential to attackers who can sniff the SOAP message.

The following WCF service provider configuration uses the UsernameToken:

     ...
     <security mode="Message">
	 <message clientCredentialType="UserName" />
     ...

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.