If the expose_php option is enabled, every response produced by the PHP interpreter includes the version of PHP installed on the host system. Armed with the version of PHP running on the remote server, an attacker may enumerate the known exploits against the system, which can greatly lower the cost of mounting a successful attack.

Unbounded consumption occurs when LLM APIs are not adequately rate-limited, throttled, or otherwise restricted in terms of resource use. This can involve excessive model inference requests, unbounded query sizes, or long-running processes that put undue strain on the server hosting the model, causing delays, outages, or even a complete loss of service.

When LLM APIs are not properly controlled, an attacker can abuse the system by sending high volumes of requests, large data queries, or complex tasks that drain resources. This issue can compound in multi-tenant systems where excessive consumption from one user or process affects others, leading to potential performance bottlenecks or system downtime.
Additionally, a Denial of Wallet (DoW) attack can occur when attackers exploit the cost-per-use model of cloud-based AI services by initiating a high volume of requests, which leads to unsustainable financial burdens on the provider. This can result in financial ruin for the provider, as the cost of processing excessive requests becomes unmanageable.

Example 1: A user submits a series of large text generation requests to an LLM API without any timeout, which allows requests to run without limits. This causes the system to process excessive data and exhausts available server resources.

import openai

# OpenAI GPT model setup
openai.api_key = "your-api-key"

def generate_large_response(prompt):
  response = openai.Completion.create(
      engine="text-davinci-003",
      prompt=prompt,
      max_tokens=1000
  )
  return response

# Submitting unbounded requests with high complexity and token count
prompt = "Generate an extensive article on AI."
response = generate_large_response(prompt)
print(response)

Example 2: A chat model is utilized without configuring a rate_limiter parameter while interacting with the LLM model.

from langchain_anthropic import ChatAnthropic
model = ChatAnthropic(
	model_name="claude-3-opus-20240229",
# not using rate_limiter
)

These examples demonstrate how unbounded API calls that lack a timeout can consume significant resources. Without restrictions on the execution time, the system can become overloaded. This can negatively affect the stability of the service and possibly result in resource exhaustion or denial-of-service risks.

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

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

The WS-SecurityPolicy standard supports seven assertions when specifying supporting tokens: SupportingTokens, SignedSupportingTokens, EndorsingSupportingTokens, SignedEndorsingSupportingTokens, SignedEncryptedSupportingTokens, EndorsingEncryptedSupportingTokens, and SignedEndorsingEncryptedSupportingTokens.
It might be possible to breach the integrity or confidentiality of tokens that are not signed or encrypted. Endorsing tokens sign the message signature to prevent tampering of the message signature.

Example 1: The following WS-SecurityPolicy policy entry allows UsernameTokens to be sent in SOAP messages without a signature or encryption:

<sp:SupportingTokens>
  <wsp:Policy>
    <sp:UsernameToken
      sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
      <wsp:Policy>
        <sp:WssUsernameToken10/>
      </wsp:Policy>
    </sp:UsernameToken>
  </wsp:Policy>
</sp:SupportingTokens>

Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

Example 1: The following WS-SecurityPolicy policy entry does not require SOAP message attachments to be encrypted since the <EncryptedParts> tag does not contain an <sp:Attachments> tag:

<sp:EncryptedParts>
  <sp:Body/>
</sp:EncryptedParts>

Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

Example 1: The following WS-SecurityPolicy policy entry does not require SOAP message bodies to be encrypted since the <EncryptedParts> tag does not contain a <sp:Body> tag:

<sp:EncryptedParts>
  <sp:Header .../>
</sp:EncryptedParts>

Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

Example 1: The following WS-SecurityPolicy policy entry does not require SOAP message headers to be encrypted since the <EncryptedParts> tag does not contain a <sp:Header> tag:

<sp:EncryptedParts>
  <sp:Body/>
</sp:EncryptedParts>