Denial of Service

Artigo
08/31/2009

Denial of service occurs when a system is overwhelmed in such a way that messages cannot be processed, or they are processed extremely slowly.

Excess Memory Consumption

A problem can occur when reading an XML document with a large number of unique local names, namespaces, or prefixes. If you are using a class that derives from XmlReader, and you call either the LocalName, Prefix or NamespaceUri property for each item, the returned string is added to a NameTable. The collection held by the NameTable never decreases in size, creating a virtual "memory leak" of the string handles.

Mitigations include:

Derive from the NameTable class and enforce a maximum size quota. (You cannot prevent the use of a NameTable or switch the NameTable when it is full.)
Avoid using the properties mentioned and instead use the MoveToAttribute method with the IsStartElement method where possible; those methods do not return strings and thus avoid the problem of overfilling the NameTable collection.

Malicious Client Sends Excessive License Requests to Service

If a malicious client bombards a service with excessive license requests, it can cause the server to use excessive memory.

Mitigation: Use the following properties of the LocalServiceSecuritySettings class:

MaxCachedCookies: controls the maximum number of time-bounded SecurityContextTokens that the server caches after SPNego or SSL negotiation.
IssuedCookieLifetime: controls the lifetime of the SecurityContextTokens that the server issues following SPNego or SSL negotiation. The server caches the SecurityContextTokens for this period of time.
MaxPendingSessions: controls the maximum number of secure conversations that are established at the server but for which no application messages have been processed. This quota prevents clients from establishing secure conversations at the service, thereby causing the service to maintain state per client, but never using them.
InactivityTimeout: controls the maximum time the service keeps a secure conversation alive without receiving an application message from the client for the conversation. This quota prevents clients from establishing secure conversations at the service, thereby causing the service to maintain state per client, but never using them.

WSDualHttpBinding or Dual Custom Bindings Require Client Authentication

By default, the WSDualHttpBinding has security enabled. It is possible, however, that if the client authentication is disabled by setting the ClientCredentialType property to None, a malicious user can cause a denial of service attack on a third service. This can occur because a malicious client can direct the service to send a stream of messages to a third service.

To mitigate this, do not set the property to None. Also be aware of this possibility when creating a custom binding that has a dual message pattern.

Auditing Event Log Can Be Filled

If a malicious user understands that auditing is enabled, that attacker can send invalid messages that cause audit entries to be written. If the audit log is filled in this manner, the auditing system fails.

To mitigate this, set the SuppressAuditFailure property to true and use the properties of the Event Viewer to control the auditing behavior. For more information about using the Event Viewer to view and manage event logs, see https://go.microsoft.com/fwlink/?LinkID=89150&clcid=0x409. For more information, see Auditing Security Events.

Invalid Implementations of IAuthorizationPolicy Can Cause Service Hangs

Calling the Evaluate method on a faulty implementation of the IAuthorizationPolicy interface can cause the service to hang.

Mitigation: Use only trusted code. That is, use only code that you have written and tested, or that comes from a trusted provider. Do not allow untrusted extensions of IAuthorizationPolicy to be plugged into your code without due consideration. This applies to all extensions used in a service implementation. WCF does not make any distinction between application code and foreign code that is plugged in using extensibility points.

Kerberos Maximum Token Size May Need Resizing

If a client belongs to a large number of groups (approximately 900, although the actual number varies depending on the groups), a problem may occur when a message header's block exceeds 64 kilobytes. In that case, you can increase the maximum Kerberos token size, as described in the Microsoft Support article "Internet Explorer Kerberos authentication does not work because of an insufficient buffer connecting to IIS." You may also need to increase the maximum WCF message size to accommodate the larger Kerberos token.

Autoenrollment Results in Multiple Certificates with Same Subject Name for Machine

Autoenrollment is the capability of Windows Server 2003 to automatically enroll users and computers for certificates. When a machine is on a domain with the feature enabled, an X.509 certificate with the intended purpose of client authentication is automatically created and inserted into the local computer's Personal certificates store whenever a new machine is joined to the network. However, autoenrollment uses the same subject name for all certificates it creates in the cache.

The impact is that WCF services may fail to open on domains with autoenrollment. This occurs because the default service X.509 credential search criteria might be ambiguous because multiple certificates with the machine's fully qualified Domain Name System (DNS) name exist. One certificate originates from autoenrollment; the other might be a self-issued certificate.

To mitigate this, reference the exact certificate to use by using a more precise search criterion on the serviceCredentials element. For example, use the FindByThumbprint option, and specify the certificate by its unique thumbprint (hash).

For more information about the autoenrollment feature, see Certificate Autoenrollment in Windows Server 2003.

Last of Multiple Alternative Subject Names Used for Authorization

In the rare case when an X.509 certificate contains multiple alternative subject names, and you authorize using the alternative subject name, authorization may fail.

Protect Configuration Files with ACLs

You can specify required and optional claims in code and configuration files for CardSpace issued tokens. This results in corresponding elements being emitted in RequestSecurityToken messages that are sent to the security token service. An attacker can modify code or configuration to remove required or optional claims, potentially getting the security token service to issue a token that does not allow access to the target service.

To mitigate: Require access to the computer to modify the configuration file. Use file access control lists (ACLs) to secure configuration files. WCF requires that code be in the application directory or the global assembly cache before it will allow such code to be loaded from configuration. Use directory ACLs to secure directories.

Maximum Number of Secure Sessions for a Service Is Reached

When a client is successfully authenticated by a service and a secure session is established with the service, the service keeps track of the session until the client cancels it or the session expires. Every established session counts against the limit for the maximum number of active simultaneous sessions with a service. When this limit is reached, clients that attempt to create a new session with that service are rejected until one or more active sessions expire or are canceled by a client. A client can have multiple sessions with a service, and each one of those sessions counts toward the limit.

Note

When you use stateful sessions, the previous paragraph does not apply. For more information about stateful sessions, see How to: Create a Stateful Security Context Token for a Secure Session.

To mitigate this, set the limit for the maximum number of active sessions and the maximum lifetime for a session by setting the SecurityBindingElement property of the SecurityBindingElement class.

Partilhar via