Privacy violations occur when:

1. Private user information enters the program.

2. The data is written to an external location, such as the console, file system, or network.
Example 1: The following code contains a logging statement that tracks the records added to a database by storing the contents in a log file.

pass = getPassword();
...
dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);

The code in Example 1 logs a plain text password to the file system. Although many developers trust the file system as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

Privacy is one of the biggest concerns in the mobile world for a couple of reasons. One of them is a much higher chance of device loss. The other has to do with inter-process communication between mobile applications. With mobile platforms, applications are downloaded from various sources and are run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which is why application authors need to be careful about what information they include in messages addressed to other applications running on the device. Sensitive information should never be part of inter-process communication between mobile applications.

Example 2: The following code reads username and password for a given site from an Android WebView store and broadcasts them to all the registered receivers.

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
    String username = credentials[0];
    String password = credentials[1];
    Intent i = new Intent();
    i.setAction("SEND_CREDENTIALS");
    i.putExtra("username", username);
    i.putExtra("password", password);
    view.getContext().sendBroadcast(i);
  }
});
...

This example demonstrates several problems. First of all, by default, WebView credentials are stored in plain text and are not hashed. If a user has a rooted device (or uses an emulator), they can read stored passwords for given sites. Second, plain text credentials are broadcast to all the registered receivers, which means that any receiver registered to listen to intents with the SEND_CREDENTIALS action will receive the message. The broadcast is not even protected with a permission to limit the number of recipients, although in this case we do not recommend using permissions as a fix.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information

- Accessed from a database or other data store by the application

- Indirectly from a partner or other third party

Typically, in the context of the mobile environment, this private information includes (along with passwords, SSNs, and other general personal information):

- Location

- Cell phone number

- Serial numbers and device IDs

- Network Operator information

- Voicemail information


Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

Query string injection vulnerabilities occur when:
1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SimpleDB query string.

Example 1: The following code dynamically constructs and executes a SimpleDB select() query that searches for invoices that match a user-specified product category. The user can also specify the column by which the results are sorted. Assume that the application has already properly authenticated and set the value of customerID prior to this code segment.

...
String customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
...
AmazonSimpleDBClient sdbc = new AmazonSimpleDBClient(appAWSCredentials);
String query = "select * from invoices where productCategory = '"
            + productCategory + "' and customerID = '"
            + customerID + "' order by '"
            + sortColumn + "' asc";
SelectResult sdbResult = sdbc.select(new SelectRequest(query));
...

The query that this code intends to execute looks like:

select * from invoices
where productCategory = 'Fax Machines'
and customerID = '12345678'
order by 'price' asc

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if productCategory and price do not contain single-quote characters. If, however, an attacker provides the string "Fax Machines' or productCategory = \"" for productCategory, and the string "\" order by 'price" for sortColumn, then the query becomes the following:

select * from invoices
where productCategory = 'Fax Machines' or productCategory = "'
and customerID = '12345678'
order by '" order by 'price' asc

or, in a more human-readable form,

select * from invoices
where productCategory = 'Fax Machines'
or productCategory = "' and customerID = '12345678' order by '"
order by 'price' asc

These inputs allow an attacker to bypass the required authentication for customerID, and allows the attacker to view invoice records matching 'Fax Machines' for all customers.

Query string injection vulnerabilities occur when:
1. Data enters a program from an untrusted source.



In this case Fortify Static Code Analyzer could not determine that the source of the data is trusted.

2. The data is used to dynamically construct a SQLite query.

The SQLite query string injection allows malicious users to view unauthorized records, but does not allow them to alter the state of the database in any way.

Example 1: The following code dynamically constructs and executes a SQLite query that searches for invoices associated with a customer and a user-specified product category. The user can also specify the column by which the results should be sorted. Assume that the program has already properly authenticated and set the value of customerID prior to this code segment.

  ...
  productCategory = this.getIntent().getExtras().getString("productCategory");
  sortColumn = this.getIntent().getExtras().getString("sortColumn");
  customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
  c = invoicesDB.query(Uri.parse(invoices), columns, "productCategory = '" + productCategory + "' and customerID = '" + customerID + "'", null, null, null, "'" + sortColumn + "'asc", null);
  ...
  

The query that this code intends to execute looks like:

  select * from invoices
  where productCategory = 'Fax Machines'
  and customerID = '12345678'
  order by 'price' asc
  

However, the query is constructed dynamically by concatenating a constant base query string and a user input string productCategory. So the query behaves correctly only if productCategory and sortColumn do not contain single-quote characters. If an attacker provides the string "Fax Machines' or productCategory = \"" for productCategory, and the string "\" order by 'price" for sortColumn, then the query becomes:

  select * from invoices
  where productCategory = 'Fax Machines' or productCategory = "'
  and customerID = '12345678'
  order by '" order by 'price' asc
  

or, in a more readable form,

  select * from invoices
  where productCategory = 'Fax Machines'
  or productCategory = "' and customerID = '12345678' order by '"
  order by 'price' asc
  

These inputs allow an attacker to bypass the required authentication for customerID and allows the attacker to view invoice records matching 'Fax Machines' for all customers.

MongoDB is a type of NoSQL database that supports JSON-oriented document storage format. An injection vulnerability occurs when:
1. PHP objects are passed in with HTTP GET and HTTP POST requests and are not inherently sanitized
2. No datatype checks are performed against the GET and POST parameters
3. A simple variable can be converted into array object by passing it as an array reference
Example: The following code finds all users with username passed through the request parameter.

$collection->find(array("username" => $_GET['username']))

Instead of passing a username string, an attacker could manipulate the query by requesting http://www.example.com?username[$ne]=foo. This allows the attacker to manipulate the query as below:

$collection->find(array("username" => array('$ne' => "foo")))

The lack of user input validation can allow the attacker to enumerate the list of all the authorized users in the system.

The HttpRequest class provides programmatic access to variables from the QueryString, Form, Cookies or ServerVariables collections in the form of an array access (e.g. Request["myParam"]). When more than one variable exists with the same name, the .NET framework returns the value of the variable that appears first when the collections are searched in the following order: QueryString, Form, Cookies then ServerVariables. Since QueryString comes first in the search order, it is possible for QueryString parameters to supersede values from forms, cookies, and server variables. Similarly, form values can supersede variables in the Cookies and ServerVariables collections and variables from the Cookies collection can supersede those from ServerVariables.
Example 1: Imagine a banking application temporarily stores a user's email address in a cookie and reads this value when it wants to contact the user. The following code reads the cookie value and sends an account balance to the specified email address.

...
    String toAddress = Request["email"];        //Expects cookie value
    Double balance = GetBalance(userID);
    SendAccountBalance(toAddress, balance);
...

Assume the code in Example 1 is executed when visiting http://www.example.com/GetBalance.aspx. If an attacker can cause an authenticated user to click a link that requests http://www.example.com/GetBalance.aspx?email=evil%40evil.com, an email with the user's account balance will be sent to evil@evil.com.

The HttpRequest class provides programmatic access to variables from the QueryString, Form, Cookies or ServerVariables collections in the form of an array access (e.g. Request["myParam"]). When more than one variable exists with the same name, the .NET framework returns the value of the variable that appears first when the collections are searched in the following order: QueryString, Form, Cookies then ServerVariables. Since QueryString comes first in the search order, it is possible for QueryString parameters to supersede values from forms, cookies, and server variables. Similarly, form values can supersede variables in the Cookies and ServerVariables collections and variables from the Cookies collection can supersede those from ServerVariables.
Example 1: The following code checks the HTTP Referer header server variable to see if the request came from www.example.com before serving content.

    ...
    if (Request["HTTP_REFERER"].StartsWith("http://www.example.com"))
        ServeContent();
    else
        Response.Redirect("http://www.example.com/");
    ...

Assume the code in Example 1 is executed when visiting http://www.example.com/ProtectedImages.aspx. If an attacker makes a direct request to the URL, the appropriate referer header will not be set and the request will fail. However, if the attacker submits an artificial HTTP_REFERER parameter with the necessary value, such as http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com, then the lookup will return the value from QueryString instead of ServerVariables and the check will succeed.