El estándar de Java exige que las implementaciones de Object.equals(), Comparable.compareTo() y Comparator.compare() devuelvan un valor especificado si sus parámetros son null. De no cumplir el contrato se daría lugar a un comportamiento inesperado.

Ejemplo 1: La implementación siguiente del método equals() no compara su parámetro con null.

public boolean equals(Object object)
{
   return (toString().equals(object.toString()));
}

Las vulnerabilidades de inyección de cadenas de consulta se producen cuando:
1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear de forma dinámica una cadena de consulta de SimpleDB.

Ejemplo 1: el siguiente código crea y ejecuta de forma dinámica una consulta select() de SimpleDB que busca facturas que coincidan con una categoría de productos especificada por el usuario. El usuario también puede especificar la columna por la que se ordenarán los resultados. Imagine que la aplicación ya ha autenticado y establecido correctamente el valor de customerID antes de este segmento de código.

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

La consulta que este código tiene intención de ejecutar presentará un aspecto similar al siguiente:

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

Sin embargo, debido a que la consulta se ha creado de forma dinámica mediante la concatenación de una cadena de consulta base constante y una cadena de entrada de usuario, esta solo se comportará correctamente si productCategory y price no contienen caracteres de comillas simples. Sin embargo, si un usuario malintencionado proporciona la cadena "Fax Machines' or productCategory = \"" para productCategory y la cadena "\" order by 'price" para sortColumn, la consulta se convierte en lo siguiente:

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

o, en un formato más adecuado para la lectura humana,

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

Estas entradas permiten a un usuario malintencionado omitir la autenticación necesaria de customerID y ver los registros de facturas que coinciden con 'Fax Machines' de todos los clientes.

Las vulnerabilidades de inyección de cadenas de consulta se producen cuando:
1. Los datos entran en un programa desde un origen que no es de confianza.



En este caso, Fortify Static Code Analyzer no pudo determinar que el origen de los datos era de confianza.

2. Los datos se utilizan para crear dinámicamente una consulta SQLite.

La inyección de cadenas de consulta SQLite permite a los usuarios malintencionados ver registros no autorizados, pero les impide modificar de cualquier modo el estado de la base de datos.

Ejemplo 1: el siguiente código crea y ejecuta dinámicamente una consulta SQLite que busca facturas asociadas a un cliente y una categoría de productos especificada por el usuario. Este también puede especificar la columna por la que deben ordenarse los resultados. Imagine que el programa ya ha realizado correctamente la autenticación y establecido el valor de customerID que antecede a este segmento de código.

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

La consulta que este código tiene intención de ejecutar presentará un aspecto similar al siguiente:

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

Sin embargo, la consulta se crea de forma dinámica mediante la concatenación de una cadena de consulta base constante y una cadena de entrada de usuario productCategory. Por lo tanto, la consulta solo presentará el comportamiento correcto si productCategory y sortColumn no contienen caracteres de comillas simples. Si un usuario malintencionado proporciona la cadena "Fax Machines' or productCategory = \"" para productCategory, y la cadena "\" order by 'price" para sortColumn, la consulta se convierte en:

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

o bien en un formato más legible,

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

Estas entradas permiten a un usuario malintencionado omitir la autenticación necesaria para customerID y ver registros de facturas que coincidan con 'Fax Machines' de todos los clientes.

La clase HttpRequest proporciona acceso programático a las variables procedentes de las colecciones QueryString, Form, Cookies o ServerVariables en la forma de un acceso de matriz (p. ej. Request["myParam"]). Cuando existe más de una variable con el mismo nombre, .NET Framework devuelve el valor de la variable que aparece primero cuando se buscan las colecciones en el siguiente orden: QueryString, Form, Cookies y ServerVariables. Como QueryString está primero en el orden de búsqueda, los parámetros QueryString pueden sustituir los valores de variables de servidor, cookies y formularios. Del mismo modo, los valores de formularios pueden reemplazar las variables de las colecciones Cookies y ServerVariables, y las variables de la colección Cookies pueden reemplazar las de ServerVariables.
Ejemplo 1: imaginemos que una aplicación bancaria almacena de forma temporal la dirección de correo electrónico de un usuario en una cookie y que lee este valor cuando quiere ponerse en contacto con el usuario en cuestión. El siguiente código lee el valor de la cookie y envía un balance de cuentas a la dirección de correo electrónico especificada.

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

Supongamos que el código en el Example 1 se ejecuta al visitar http://www.example.com/GetBalance.aspx. Si un atacante puede hacer que un usuario autenticado haga clic en un enlace que solicite http://www.example.com/GetBalance.aspx?email=evil%40evil.com, se enviará un mensaje de correo electrónico con el balance de cuentas del usuario a evil@evil.com.

La clase HttpRequest proporciona acceso programático a las variables procedentes de las colecciones QueryString, Form, Cookies o ServerVariables en la forma de un acceso de matriz (p. ej. Request["myParam"]). Cuando existe más de una variable con el mismo nombre, .NET Framework devuelve el valor de la variable que aparece primero cuando se buscan las colecciones en el siguiente orden: QueryString, Form, Cookies y ServerVariables. Como QueryString está primero en el orden de búsqueda, los parámetros QueryString pueden sustituir los valores de variables de servidor, cookies y formularios. Del mismo modo, los valores de formularios pueden reemplazar las variables de las colecciones Cookies y ServerVariables, y las variables de la colección Cookies pueden reemplazar las de ServerVariables.
Ejemplo 1: el siguiente código comprueba la variable del servidor del encabezado de referencia HTTP para ver si la solicitud proviene de www.example.com antes de proporcionar contenido.

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

Supongamos que el código en el Example 1 se ejecuta al visitar http://www.example.com/ProtectedImages.aspx. Si un atacante realiza una solicitud directa a la URL, no se establecerá el encabezado de referencia correspondiente y la solicitud no se cumplirá. No obstante, si el atacante envía un parámetro HTTP_REFERER artificial con el valor requerido, como http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com, la búsqueda devolverá el valor de QueryString en lugar de ServerVariables y se realizará la comprobación.