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.