Programs deployed outside an enterprise's network infrastructure lose the internal guarantees of data transmission security. An attacker residing on a shared network may be able to snoop unencrypted traffic.

Storing session data in Cookies presents several problems:

1. Cookie-based sessions are not invalidated when a user logs out. If an attacker were to find, steal, or intercept a user's cookie they could impersonate the user even if that user had logged out.

2. Session cookies are signed to avoid tampering and guarantee the authenticity of the data, but it will not prevent replay attacks.

3. The session data will be stored using Django's tools for cryptographic signing and the SECRET_KEY setting. If the SECRET_KEY is leaked, an attacker cannot only falsify session data, but if application uses Pickle to serialize session data into cookies, an attacker will be able to craft malicious pickled data that will execute arbitrary code upon deserialization.

4. The session data is signed but not encrypted. This means that attackers will be able to read the session data but not modify it.

5. The cookie size and serialization process can pose a performace problem depending on site load.

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

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

<sp:SignedParts>
  <sp:Body/>
</sp:SignedParts>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

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

<sp:SignedParts>
  <sp:Header .../>
</sp:SignedParts>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

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

<sp:SignedParts>
  <sp:Body/>
</sp:SignedParts>

Information stored in the database is a prime target for attackers. Revealing information about the database structure through SQL queries exposes the application to severe threats such as information theft and denial of service. Disclosure of SQL queries, at a minimum, reveals details about the database technology used by the application. It can also provide specifics such as the database, table or column names.
An attacker can use this information to conduct SQL injection attacks.

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>

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 uses symmetric binding, but does not specify an encryption token:

<sp:SymmetricBinding>
    <wsp:Policy>
        <sp:SignatureToken>
            <wsp:Policy>
                ...
            </wsp:Policy>
        </sp:SignatureToken>
        ...
    </wsp:Policy>
</sp:SymmetricBinding>

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 uses asymmetric binding, but does not specify an initiator encryption token:

<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:InitiatorSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorSignatureToken>
    <sp:RecipientEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientEncryptionToken>
    <sp:RecipientSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientSignatureToken>
      ...
  </wsp:Policy>
</sp:AsymmetricBinding>

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 uses asymmetric binding, but does not specify a recipient encryption token:

<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:InitiatorEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorEncryptionToken>
    <sp:InitiatorSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorSignatureToken>
    <sp:RecipientSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientSignatureToken>
      ...
  </wsp:Policy>
</sp:AsymmetricBinding>

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

Android's backup service allows the application to save persistent data to a remote cloud storage in order to provide a restore point for the application data in the future.

Android applications can be configured with this backup service by setting the allowBackup attribute to true (the default value) and defining the backupAgent attribute on the <application> tag.

Android however, does not guarantee the security of your data while using backup, as the cloud storage and transport vary from device to device.

There is a vulnerability in implementations ofjava.lang.Double.parseDouble() and related methods that can cause the thread to hang when parsing any number in the range [2^(-1022) - 2^(-1075) : 2^(-1022) - 2^(-1076)]. This defect can be used to execute a Denial of Service (DoS) attack.

Example 1: The following code uses a vulnerable method.

Double d = Double.parseDouble(request.getParameter("d"));

An attacker could send requests where the parameter d is a value in the range, such as "0.0222507385850720119e-00306", to cause the program to hang while processing the request.

This vulnerability exists for Java version 6 Update 23 and earlier versions. It is not present for Java version 6 Update 24 and later.

Heap inspection vulnerabilities occur when sensitive data, such as a password or an encryption key, can be exposed to an attacker because they are not removed from memory.

The realloc() function is commonly used to increase the size of a block of allocated memory. This operation often requires copying the contents of the old memory block into a new and larger block. This operation leaves the contents of the original block intact but inaccessible to the program, preventing the program from being able to scrub sensitive data from memory. If an attacker can later examine the contents of a memory dump, the sensitive data could be exposed.

Example 1: The following code calls realloc() on a buffer containing sensitive data:

plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);

There is an attempt to scrub the sensitive data from memory, but realloc() is used, so a copy of the data can still be exposed in the memory originally allocated for plaintext_buffer.

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 WS-SecurityPolicy policy entry has the <IncludeTimestamp> tag commented out:

  <sp:AsymmetricBinding>
    <wsp:Policy>
      ...
      <!--<sp:IncludeTimestamp/>-->
      <sp:ProtectTokens/>
      <sp:OnlySignEntireHeadersAndBody/>
    </wsp:Policy>
  </sp:AsymmetricBinding>

Maintaining the confidentiality and integrity of information in transit is a primary function of the SSL/TLS protocol. Vulnerabilities in the protocol implementation could however severely compromise these guarantees. Failure to establish a cryptographic binding of a handshake to the enclosing session causes the SSL/TLS renegotiation protocol to fall victim to man-in-the-middle attacks that could allow an attacker to inject plaintext into the protocol stream. Renegotiation was developed to support long running sessions where encryption keys will need to be changed to ensure cryptographic security. However, the real problem manifests within the application using SSLv3/TLS. Since HTTP requests cannot be processed until they are complete, web servers cache the request until it is finished. When the SSLv3/TLS libraries receive new packets they are immediately forwarded to the web server once decrypted. This indeterminate buffer state is the manifestation of the problem. Unfortunately, servers vulnerable to this attack are SSLv3/TLS enabled web servers that do NOT flush the request buffers prior to the renegotiation of SSL Keys. Thus an attacker can leverage this oversight to inject data into the beginning of the conversation between unsuspecting clients and the web server.

A server configured to use the vulnerable protocol implementation exposes the hosted application to malicious data injection exploits. An application that lacks appropriate input filters to reject incoming malicious requests can enable an attacker to steal the authentication credentials of users, which can lead to further compromises by using the stolen privileges.

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.

Example 1: The following transport binding uses HTTP instead of HTTPS:

<sp:TransportBinding>
  <wsp:Policy>
    <sp:TransportToken>
      <wsp:Policy>
        <sp:HttpToken/>
       </wsp:Policy>
    </sp:TransportToken>
    ...
</sp:TransportBinding>