The longer a session stays open, the larger the window of opportunity an attacker has to compromise user accounts. While a session remains active, an attacker may be able to brute-force a user's password, crack a user's wireless encryption key, or commandeer a session from an open browser. Longer session timeouts can also prevent memory from being released and eventually result in a denial of service if a sufficiently large number of sessions are created.

Example 1: If the session timeout is zero or less than zero, the session never expires. The following example shows a session timeout set to -1, which will cause the session to remain active indefinitely.

<session-config>
    <session-timeout>-1</session-timeout>
</session-config>

The <session-timeout> tag defines the default session timeout interval for all sessions in the web application. If the <session-timeout> tag is missing, it is left to the container to set the default timeout.

If an application uses SSL to guarantee confidential communication with client browsers, the application configuration should make it impossible to view any access controlled page without SSL.

There are three common ways for SSL to be bypassed:

- A user manually enters URL and types "HTTP" rather than "HTTPS".

- Attackers intentionally send a user to an insecure URL.

- A programmer erroneously creates a relative link to a page in the application, failing to switch from HTTP to HTTPS. (This is particularly easy to do when the link moves between public and secured areas on a web site.)

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following snippet from a WSE policy file is an example where timestamps are not include in SOAP faults:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
...
      <protection>
        <fault signatureOptions="IncludeAddressing, IncludeSoapBody" encryptBody="true" />

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following snippet from a WSE policy file is an example where timestamps are not include in SOAP message requests:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
...
      <protection>
        <request signatureOptions="IncludeAddressing, IncludeSoapBody" encryptBody="true" />

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following snippet from a WSE policy file is an example where timestamps are not included in SOAP message responses:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
...
      <protection>
        <response signatureOptions="IncludeAddressing, IncludeSoapBody" encryptBody="true" />

Sending plain text passwords over an unencrypted channel can expose the credential to attackers who can sniff the SOAP message.

Example 1: The following policy entry uses the UsernameToken.

<wssp:SupportedTokens>
    <wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken" />
</wssp:SupportedTokens>

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>

An API operation has been detected that allows credentials to travel over an unencrypted channel. OpenAPI security requirements and target servers definitions for an API operation will always override the respective global settings.

However, when these settings are not defined for an operation, they default to the globally specified values.

A Security timestamp indicates the freshness of a message's security data. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker could intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may trick a recipient into accepting a malicious message.

Example 1: The following policy entry has the <MessageAge> tag commented out.

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  >
...
<!--   <wssp:MessageAge/> -->

</wsp:Policy>

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.

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

Unencrypted communication channels are prone to eavesdropping and tampering. Servicing client requests over an insecure communication channel allows attackers to perform man-in-the-middle attacks, and gives them access to read or modify the data in transit.

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>

Acegi Security allows for temporarily replacing the Authentication object in the SecurityContext during the secure object callback phase. This only occurs if the original Authentication object was successfully processed by the AuthenticationManager and AccessDecisionManager. The RunAsManager creates this Authentication object.
Typically developers use RunAsManager to configure one or more additional roles for an authenticated user for the duration of a method invocation. This is useful for a secure bean that needs to access a remote application. Since the remote application might demand different credentials, this allows translating between calling roles and those needed by the remote application so that the remote access can succeed. The new Authentication object (called RunAsUserToken) will be simply accepted as a valid Authentication object without any further authentication or authorization check.
Adding new roles or privileges to the new Authentication object has the potential to temporarily elevate the user's privileges, allowing the user to take an unauthorized action.
The following configuration shows using RunAsManager to add the role "UBER_BOSS" to a user who has the role "ROLE_PEON", thus temporarily elevating this user to have manager privileges, which enables all peons to get data from the PrivateCatalog.

<bean id="bankManagerSecurity" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
...
 <property name="objectDefinitionSource">
   <value>
     com.example.service.PrivateCatalog.getData=ROLE_PEON,RUN_AS_UBER_BOSS
...
   </value>
 </property>
</bean>

Loose access configurations can 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, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.