It is never a good idea to use a null (nil) salt. Not only does using a null salt make it significantly easier to determine the hashed values, it also makes fixing the problem extremely difficult. After the code is in production, the salt cannot be easily changed. If attackers figure out that values are hashed with a null salt, they can compute "rainbow tables" for the application and more easily determine the hashed values.

Example 1: The following code uses a null (nil) salt:

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     password,
                     passwordLen,
                     nil,
                     0,
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

This code will run successfully, but anyone who has access to it will have access to the null salt. After the program ships, there is likely no way to change the null salt. An employee with access to this information can use it to break into the system.

Stream ciphers are vulnerable to "key re-use" attacks, also called "two-time pad" attacks. This type of vulnerability occurs when you use the same key more than once because it is trivial to XOR the two ciphertext strings and nullify the key, which leaves only XOR'ed plain text. Due to the way human language is formatted, it is usually trivial to recover to the original two messages.
To stop the aforementioned attacks requires the use of a fresh initialization vector (IV), and therefore stream ciphers are not suitable to store encrypted data, as it means that either:
1) The disk sector is used as the IV:
This is insecure as it requires re-using the same IV every time the stored data requires modification.
2) Using a complicated system to map fresh IVs to disk sectors:
This is difficult to maintain. Such an approach requires that IVs are continuously updated, need to be unreadable by users, and requires that the ciphertext consumes more disk space than the unencrypted plain text.

Based on these two points, it is disadvantageous to use stream ciphers instead of block ciphers to store encrypted data. Another problem with stream ciphers is that they provide no authentication and therefore are vulnerable to "bit-flipping" attacks. Some block ciphers such as "CTR" are vulnerable to these same attacks because they function similarly to stream ciphers.

Example 1: The following code creates a stream cipher that is used to encrypt data with a constant IV and store it on disk:

import (
    "crypto/aes"
    "crypto/cipher"
    "os"
)
...
iv = b'1234567890123456'
CTRstream = cipher.NewCTR(block, iv)
CTRstream.XORKeyStream(plaintext, ciphertext)
...
f := os.Create("data.enc")
f.Write(ciphertext)
f.Close()

In Example 1, because iv is set as a constant initialization vector, this is susceptible to re-use attacks.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a cloud-hosted web application through an untrusted source. In the case of Inter-Component Communication Cloud XSS, the untrusted source is data received from other components of the cloud application through communication channels provided by the cloud host.


2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Example 1: The following ASP.NET Web Form queries the Azure Table Service for an employee and prints the name.

<script runat="server">
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
</script>

Where EmployeeName is a form control defined as follows:

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

Example 2: The following ASP.NET code segment is functionally equivalent to Example 1, but implements all of the form elements programmatically.

protected System.Web.UI.WebControls.Label EmployeeName;
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;

These code examples function correctly when the values of Name are well-behaved, but they do nothing to prevent exploits if they are not. This code can appear less dangerous because the value of Name is read from a cloud-provided storage service, whose contents are apparently managed by the distributed application. However, if the value of Name originates from user-supplied data, then the cloud-provided storage service can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Inter-Component Communication Cloud XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.

Example 3: The following ASP.NET Web Form reads an employee ID number from an HTTP request and displays it to the user.

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

Where Login and EmployeeID are form controls defined as follows:

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

Example 4: The following ASP.NET code segment shows the programmatic way to implement Example 3.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

As in Example 1 and Example 2, these examples operate correctly if Login contains only standard alphanumeric text. If Login has a value that includes metacharacters or source code, then the code will be executed by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks in order to lure victims into clicking a link. When the victims click the link, they unwittingly reflect the malicious content through the vulnerable web application and back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

- As in Example 1 and Example 2, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Inter-Component Communication Cloud XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.

- As in Example 3 and Example 4, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.

- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.

A number of modern web frameworks provide mechanisms to perform user input validation (including ASP.NET Request Validation and WCF). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. With ASP.NET Request Validation, we also provide evidence for when validation is explicitly disabled. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.

SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without being validated.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is used for distributing spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker will be able to set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously since the email will be sent from the victim server.

Example: The following code segment reads the subject and body of a "Contact us" form:

  String subject = request.getParameter("subject");
  String body = request.getParameter("body");
  MimeMessage message = new MimeMessage(session);
  message.setFrom(new InternetAddress("webform@acme.com"));
  message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
  message.setSubject("[Contact us query] " + subject);
  message.setText(body);
  Transport.send(message);
  

Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:

  ...
  subject: [Contact us query] Page not working
  ...
  

However, because the value of the header is constructed from unvalidated user input the response will only maintain this form if the value submitted for subject does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", then the SMTP headers would be of the following form:

  ...
  subject: [Contact us query] Congratulations!! You won the lottery
  cc: victim1@mail.com,victim2@mail.com
  ...
  

This will effectively allow an attacker to craft spam messages or to send anonymous emails amongst other attacks.

The application communicates with its database server over unencrypted channels and may pose a significant security risk to the company and users of that application. In this case, an attacker can modify the user entered data or even execute arbitrary SQL commands against the database server.

Example 1: The following configuration causes the application to communicate with its database server over unencrypted channels:

<connectionStrings>
  <add name="Test" connectionString="Data Source=210.10.20.10,1433; Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;" providerName="System.Data.SqlClient" />
</connectionStrings>

An HTTPS stripping attack is a type of man-in-the-middle attack where the attacker watches all the HTTP traffic for location headers and links that reference HTTPS and replaces them with HTTP versions. The attacker keeps a list of all HTTP substitutions made so that they can make the HTTPS request back to the server. All stripped HTTP connections are proxied out to the server over HTTPS. All traffic between the victim and the attacker is sent over HTTP, revealing usernames, passwords, and other private information, but the server is still receiving the expected HTTPS traffic from the attacker so nothing seems wrong.


HTTP Strict Transport Security (HSTS) is a security header that instructs the browser to always connect to the site that returning the HSTS headers over SSL/TLS during a period specified within the header. Any connection to the server over HTTP is automatically replaced with an HTTPS connection, even if the user types a URL with http:// in the browser's URL bar.

Example: The following code configures a Spring Security protected application to disable HSTS headers:

	<http auto-config="true">
        ...
        <headers>
            ...
            <hsts disabled="true" />
        </headers>
	</http>

Memcached injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a Memcached key or value.

Example 1: The following code dynamically constructs a Memcached key.

    ...
            TextClient tc = (TextClient)Client.GetInstance("127.0.0.1", 11211, MemcachedFlags.TextProtocol);
            tc.Open();
            string id = txtID.Text;
            var result = get_page_from_somewhere();
            var response = Http_Response(result);
            tc.Set("req-" + id, response, TimeSpan.FromSeconds(1000));
            tc.Close();
            tc = null;
    ...
    

The operation that this code intends to execute follows:

    set req-1233 0 1000 n
    <serialized_response_instance>
    

Where n is length of the response.

However, because the operation is constructed dynamically by concatenating a constant key prefix and a user input string, an attacker may send the string ignore 0 0 1\r\n1\r\nset injected 0 3600 10\r\n0123456789\r\nset req-, then the operation becomes the following:

    set req-ignore 0 0 1
    1
    set injected 0 3600 10
    0123456789
    set req-1233 0 0 n
    <serialized_response_instance>
    

The preceding key will successfully add a new key/value pair in the cache injected=0123456789 and the attackers will be able to poison the cache.