Resulta confuso tener un campo miembro y un método con el mismo nombre. Facilita que el programador llame accidentalmente el método cuando intenta acceder al campo o viceversa.

Ejemplo 1:

public class Totaller {
  private int total;
  public int total() {
    ...
  }
}

La sincronización en Java puede ser complicada. Un bloque vacío sincronizado es con frecuencia una señal de que un programador está luchando con la sincronización, pero todavía no ha conseguido el resultado previsto.

Ejemplo 1:

synchronized(this) { }

Aunque la especificación de lenguaje Java permite que un método finalize() de objeto sea llamado desde fuera del finalizador, se trata de una mala idea. Por ejemplo, llamar finalize() explícitamente indica que finalize() se llamará más de una vez: la primera vez será la llamada explícita y la última vez será la llamada que se hace después de que el objeto sea recolectado.

Ejemplo 1: el fragmento de código siguiente llama finalize() explícitamente:

// time to clean up
widget.finalize();

La sección 3.8 de la especificación de lenguaje Java reserva el signo de dólar ($) para identificadores que se usan solo en código fuente generado mecánicamente.

Ejemplo 1:

int un$afe;

Normalmente, no se desea dar a las clases externas acceso directo a sus campos miembros del objeto porque cualquier clase externa puede cambiar un campo público. Un buen diseño orientado al objeto usa la encapsulación para evitar que detalles de implementación, como campos de miembro, queden expuestos a otras clases. Además, si el sistema asume que no se puede cambiar este campo, entonces el código malintencionado podría ser capaz de cambiar negativamente el comportamiento del sistema.

Ejemplo 1: en el siguiente código, el campo ERROR_CODE se declara como público y estático, pero no como final:

public class MyClass
{
public static int ERROR_CODE = 100;
//...
}

En este caso, el código malintencionado podría ser capaz de cambiar este código de error y provocar que el programa se comporte de forma inesperada.

Este valor inicial de la variable no se utiliza. Tras la inicialización, a la variable se le asigna otro valor o esta sale del ámbito.

Ejemplo 1: La siguiente cita de código se asigna a la variable r y, a continuación, sobrescribe el valor sin usarlo.

  int r = getNum();
  r = getNewNum(buf);

Este valor de la variable no se utiliza. Tras la asignación, a la variable se le asigna otro valor o se sale del ámbito.

Ejemplo 1: La siguiente cita de código se asigna a la variable r y, a continuación, sobrescribe el valor sin usarlo.

  r = getName();
  r = getNewBuffer(buf);

Esta variable no se utiliza nunca. Es probable que la variable sea simplemente residual, pero también es posible que la variable sin utilizar muestre un error.

Ejemplo 1: En el código siguiente, un error de copiar y pegar ha provocado que se utilice dos veces un iterador de bucle (i). La variable j no se utiliza nunca.

  int i,j;

  for (i=0; i < outer; i++) {
    for (i=0; i < inner; i++) {
      ...

El comportamiento de las funciones de esta categoría varía en función del sistema operativo y, a veces, entre versiones de los mismos. Entre las diferencias de implementación, se incluyen:

- Ligeras diferencias en la forma en que se interpretan los comandos, lo que da lugar a resultados incoherentes.

- Algunas implementaciones de la función conllevan considerables riesgos de seguridad.

- Es posible que la función no se defina en todas las plataformas.

Cada sistema operativo utiliza caracteres diferentes como separadores de archivos. Por ejemplo, los sistemas Microsoft Windows utilizan "\", mientras que los sistemas UNIX utilizan "/". Cuando las aplicaciones tienen que ejecutarse en distintas plataformas, el uso de separadores de archivos codificados puede provocar la ejecución incorrecta de la lógica de la aplicación y, posiblemente, una denegación de servicio.

Ejemplo 1: el siguiente código utiliza un separador de archivos codificados para abrir un archivo:

...
File file = new File(directoryName + "\\" + fileName);
...

Es necesario especificar una configuración regional concreta al comparar datos que depende de ella.

Ejemplo 1: el siguiente ejemplo trata de llevar a cabo la validación para determinar si la entrada del usuario incluye una etiqueta<script>.

  ...
  public String tagProcessor(String tag){
    if (tag.toUpperCase().equals("SCRIPT")){
      return null;
    }
    //does not contain SCRIPT tag, keep processing input
    ...
  }
  ...

El problema con el Example 1 es que java.lang.String.toUpperCase(), cuando se usa sin configuración regional, emplea las reglas de la configuración regional predeterminada. El hecho de utilizar la configuración regional turca "title".toUpperCase() devuelve "T\u0130TLE", donde "\u0130" es el carácter "I LATINA MAYÚSCULA CON PUNTO". Esto puede dar lugar a resultados inesperados, como en el Example 1, en el que se impide que la validación capture la palabra "script", lo que puede dar lugar a una potencial vulnerabilidad de scripts entre sitios.

Los sistemas SAP están diseñados para ser independientes de la plataforma. Open SQL, el dialecto SQL portátil de SAP, hace que las aplicaciones sean independientes de un controlador JDBC de un determinado proveedor de base de datos. El uso de Open SQL elimina las complejidades de la base de datos subyacente y proporciona una interfaz común a programas de aplicaciones para todas las operaciones de base de datos. Sin embargo, SQL nativo es específico de la base de datos subyacente y, por lo tanto, su uso en otras plataformas podría provocar a una ejecución incorrecta de la lógica de las aplicaciones y conducir potencialmente a una denegación de servicio.
Ejemplo 1: el siguiente código usa SQL nativo:

...
import java.sql.PreparedStatement;
import com.sap.sql.NativeSQLAccess;

String mssOnlyStmt = "...";
// variant 1
  PreparedStatement ps =
  NativeSQLAccess.prepareNativeStatement(
    conn, mssOnlyStmt);
  . . .
// variant 2
  Statement stmt =
  NativeSQLAccess.createNativeStatement(conn);
  int result = stmt.execute(mssOnlyStmt);
  . . .
// variant 3
  CallableStatement cs =
  NativeSQLAccess.prepareNativeCall(
  conn, mssOnlyStmt);
  . . .

Las funciones que pueden sobrescribir las variables que ya se han inicializado pueden permitir a un usuario malintencionado influir en la ejecución de código que se basa en las variables que se sobrescriben.
puede sobrescribir variables.

Ejemplo 1: si un atacante facilita un valor malintencionado para varName en el siguiente segmento de código ColdFusion, la llamada a SetVariable() podría sobrescribir cualquier variable arbitraria, incluida #first#. En este caso, si un valor malintencionado que contenga JavaScript sobrescribe #first#, el programa es vulnerable a los Cross-Site Scripting.

<cfset first = "User">
<cfscript>
SetVariable(url.varName, url.varValue);
</cfscript>
<cfoutput>
#first#
</cfoutput>

Las funciones que pueden sobrescribir las variables que ya se han iniciado en el ámbito actual pueden permitir a un usuario malintencionado influir en la ejecución de código que se basa en las variables que se sobrescriben.
Ejemplo 1: si un atacante facilita un valor malintencionado para str en el siguiente segmento de código PHP, la llamada a parse_str() podría sobrescribir cualquier variable arbitraria, incluida first. En este caso, si un valor malintencionado que contenga JavaScript sobrescribe first, el programa es vulnerable a los Cross-Site Scripting.

<?php
    $first="User";
    ...
    $str =  $_SERVER['QUERY_STRING'];
    parse_str($str);
    echo $first;
?>

Las funciones que pueden sobrescribir variables globales que ya se han iniciado pueden permitir a un usuario malintencionado influir en la ejecución de código que se basa en las variables que se sobrescriben.
Ejemplo 1: si un atacante facilita un valor malintencionado para str en el siguiente segmento de código PHP, la llamada a mb_parse_str() podría sobrescribir cualquier variable arbitraria, incluida first. En este caso, si un valor malintencionado que contenga JavaScript sobrescribe first, el programa es vulnerable a los Cross-Site Scripting.

<?php
    $first="User";
    ...
    $str =  $_SERVER['QUERY_STRING'];
    mb_parse_str($str);
    echo $first;
?>

Las instancias de NSPredicate especifican cómo debe obtenerse o filtrarse una colección de orígenes como CoreData del sistema de almacenamiento complejo, una matriz y un diccionario. El lenguaje de consulta proporciona un lenguaje expresivo similar a SQL para definir condiciones lógicas en las que se debe buscar la colección.

Un atacante que puede influir en el predicado también puede ser capaz de modificar su significado para, por ejemplo, filtrar datos, eludir controles de seguridad o suplantar a otros usuarios.

Ejemplo 1: En el ejemplo siguiente se muestra cómo se utiliza un NSPredicate como factor de autenticación para acceder a algunos datos almacenados por la aplicación. Dado que los usuarios pueden proporcionar valores PIN arbitrarios, podrán utilizar un carácter comodín (*) para eludir la protección PIN.

NSString *pin = [self getPinFromUser];
NSPredicate *predicate = [NSPredicate predicateWithFormat:@"pin LIKE %@", pin];

Se producen violaciones de la privacidad cuando:

1. La información privada del usuario entra en el programa.

2. Los datos se escriben en una ubicación externa, como la consola, el sistema de archivos o la red.
Ejemplo 1: el siguiente código contiene una instrucción de registro que realiza un seguimiento de los registros agregados a una base de datos almacenando el contenido en un archivo de registro.

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

El código del Example 1 registra una contraseña de texto sin formato en el sistema de archivos. Aunque muchos desarrolladores confían en el sistema de archivos como una ubicación segura de almacenamiento para los datos, el usuario no debería confiar absolutamente, en especial, cuando la privacidad es una preocupación.

La privacidad es una de las mayores preocupaciones en las plataformas móviles debido a un par de motivos. Uno de ellos es la mayor probabilidad de pérdida del dispositivo. El otro está relacionado con las comunicaciones entre procesos entre aplicaciones móviles. En las plataformas móviles, las aplicaciones se descargan desde diversos orígenes y se ejecutan junto con otras aplicaciones en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que los autores de aplicaciones deben tener cuidado con la información que incluyen en los mensajes dirigidos a otras aplicaciones que se ejecutan en el dispositivo. La información confidencial nunca debería formar parte of las comunicaciones entre procesos entre aplicaciones móviles.

Ejemplo 2: El siguiente código lee el nombre de usuario y la contraseña de un sitio determinado de un almacén WebView de Android y los difunde a todos los destinatarios registrados.

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

Este ejemplo pone de manifiesto varios problemas. El primero de todos es que, de manera predeterminada, las credenciales de WebView se almacenan en texto sin formato y no tienen hash. Si un usuario tiene un dispositivo con acceso root (o usa un emulador), podrá leer las contraseñas almacenadas de sitios determinados. El segundo es que las credenciales de texto sin formato se difunden a todos los destinatarios registrados, lo que significa que cualquier destinatario registrado para escuchar las finalidades con la acción SEND_CREDENTIALS recibirá el mensaje. La difusión ni siquiera está protegida con un permiso para limitar el número de destinatarios, aunque en este caso no recomendamos el uso de permisos como solución.

Los datos privados se pueden escribir en un programa de varias formas:

- Directamente desde el usuario en forma de una contraseña o información personal

- La aplicación accede desde una base de datos u otro almacén de datos

- Indirectamente desde un asociado de negocios u otra tercera parte

Normalmente, en el contexto de un entorno móvil, esta información privada incluye (junto con contraseñas, SSN y otra información personal general):

- Ubicación

- Número de teléfono móvil

- Números de serie e identificadores de dispositivos

- Información del operador de red

- Información del buzón de voz


A veces los datos que no están etiquetados como privados pueden tener una implicación de privacidad en un contexto diferente. Por ejemplo, los números de identificación de alumnos generalmente no se consideran privados porque no hay ninguna asignación explícita y disponible públicamente a la información personal de un alumno. Sin embargo, si una escuela genera números de identificación basados en los números de seguridad social de los alumnos, los números de identificación se deberán considerar privados.

Las preocupaciones de seguridad y privacidad a menudo parece que compiten entre sí. Desde una perspectiva de seguridad, debería registrar todas las operaciones importantes de modo que posteriormente se pueda identificar cualquier actividad anómala. Sin embargo, cuando se trata de datos privados, esta práctica puede crear riesgos.

Aunque hay muchas maneras de tratar los datos privados de forma no segura, un riesgo común se deriva de la confianza mal depositada. Los programadores a menudo confían en el entorno operativo en el que se ejecuta un programa, y por lo tanto, creemos que es aceptable para almacenar información privada en el sistema de archivos, en el registro o en otros recursos controlados localmente. Sin embargo, incluso si se restringe el acceso a determinados recursos, esto no garantiza que se pueda confiar en las personas que tienen acceso. Por ejemplo, en el año 2004, un empleado sin escrúpulos de AOL vendió aproximadamente 92 millones de direcciones de correo electrónico privadas de los clientes a un remitente de marketing de correo electrónico no deseado, un sitio web de juegos de azar ubicado en el extranjero [1].

En respuesta a dichos ataques de alto perfil, la recopilación y gestión de datos privados se está convirtiendo en algo cada vez más regulado. Dependiendo de su ubicación, el tipo de negocio que desarrolle y la naturaleza de los datos privados que controle, una organización puede verse obligada a cumplir uno o varios de los siguientes reglamentos federales y estatales:

- Marco de privacidad de Safe Harbor [3]

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

- Ley de portabilidad y responsabilidad de seguros médicos (Health Insurance Portability and Accountability Act, HIPAA) [5]

- California SB-1386 [6]

A pesar de estas regulaciones, se siguen produciendo con alarmante frecuencia violaciones de la privacidad.

La indexación insegura amenaza la confidencialidad de los datos de los sitios web y las aplicaciones móviles que permiten la indexación para una búsqueda eficiente de texto completo; la inclusión de datos privados o confidenciales en los documentos indexados por el motor de búsqueda de Android puede dar lugar a la fuga de información sobre la existencia y el contenido de los datos. En el proceso de indexación, la información se recopila y almacena. Un atacante puede recuperar más tarde esta información (aunque no de manera trivial), generalmente a través de una serie de consultas a la función de búsqueda en un dispositivo móvil Android.

La biblioteca AppSearch, una solución de búsqueda de alto rendimiento de los dispositivos de Android, es un ejemplo típico de indexación de datos, particularmente cuando una determinada aplicación contribuye a un índice central de todo el sistema en el dispositivo, que se denomina almacenamiento de plataforma. El acceso a los datos dentro del índice central está restringido a los datos que la aplicación ha aportado y los datos que otra aplicación ha compartido explícitamente mediante la concesión de permisos adecuados. Si un documento confidencial en particular se indexa por error o accidentalmente mediante este proceso, puede dar lugar a una violación de la privacidad, al permitir que se busque en este documento.

Ejemplo 1: El siguiente código muestra un ejemplo de cómo se indexa un documento privado en Android usando la biblioteca AppSearch. Este documento contiene datos privados que se supone que están ocultos de cara al proceso de indexación y a los que no se permite el acceso mediante el código AppSearch.

...
// Document object to index
val doc = Doc(
    namespace="user1",
    id="noteId",
    score=10,
    text="This document contains private data"
)
// Adding document object to AppSearch index
val putRequest = PutDocumentsRequest.Builder().addDocuments(doc).build()

Se producen violaciones de la privacidad cuando:

1. La información privada del usuario entra en el programa.

2. Los datos se escriben en una ubicación externa, como la consola, el sistema de archivos o la red.

En este caso, los datos se guardan en el dispositivo Android físico mediante la clase SharedPreferences.

Ejemplo 1: el siguiente código almacena las preferencias de usuario mediante la clase SharedPreferences de Android. Entre los valores adicionales que se almacenan en el dispositivo, se incluye la password proporcionada por el usuario, que se guarda como texto sin formato.

SharedPreferences userPreferences = this.getSharedPreferences("userPreferences", MODE_WORLD_READABLE);
SharedPreferences.Editor editor = userPreferences.editor();
editor.putString("username", userName);
editor.putString("password", password);
...
editor.language("language", language);
...

Aunque una instancia de SharedPreferences de Android es, de forma predeterminada, privada para la aplicación y no se puede acceder a ella desde otras aplicaciones, el acceso físico al dispositivo podría permitir el acceso a estos archivos. Además, en el Example 1, al establecer el modo en MODE_WORLD_READABLE, se facilita el archivo de preferencias a otras aplicaciones, infringiendo de forma adicional la privacidad del usuario.

Muchos desarrolladores confían en el sistema de archivos como ubicación de almacenamiento seguro de los datos, pero no se debería confiar en este de forma implícita, sobre todo, cuando la privacidad supone una preocupación.

Los datos privados se pueden escribir en un programa de varias formas:

- Directamente desde el usuario en forma de una contraseña o información personal

- La aplicación accede desde una base de datos u otro almacén de datos

- Indirectamente desde un asociado de negocios u otra tercera parte

Normalmente, en el contexto de un entorno móvil, esta información privada incluye (junto con contraseñas, SSN y otra información personal general):

- Ubicación

- Número de teléfono móvil

- Números de serie e identificadores de dispositivos

- Información del operador de red

- Información del buzón de voz

A veces los datos que no están etiquetados como privados pueden tener una implicación de privacidad en un contexto diferente. Por ejemplo, los números de identificación de alumnos generalmente no se consideran privados porque no hay ninguna asignación explícita y disponible públicamente a la información personal de un alumno. Sin embargo, si una escuela genera números de identificación basados en los números de seguridad social de los alumnos, los números de identificación se deberán considerar privados.

Las preocupaciones de seguridad y privacidad a menudo parece que compiten entre sí. Desde una perspectiva de seguridad, debería registrar todas las operaciones importantes de modo que posteriormente se pueda identificar cualquier actividad anómala. Sin embargo, cuando se trata de datos privados, esta práctica puede crear riesgos.

Aunque hay muchas maneras de tratar los datos privados de forma no segura, un riesgo común se deriva de la confianza mal depositada. Los programadores a menudo confían en el entorno operativo en el que se ejecuta un programa, y por lo tanto, creemos que es aceptable para almacenar información privada en el sistema de archivos, en el registro o en otros recursos controlados localmente. Sin embargo, incluso si se restringe el acceso a determinados recursos, esto no garantiza que se pueda confiar en las personas que tienen acceso. Por ejemplo, en el año 2004, un empleado sin escrúpulos de AOL vendió aproximadamente 92 millones de direcciones de correo electrónico privadas de los clientes a un remitente de marketing de correo electrónico no deseado, un sitio web de juegos de azar ubicado en el extranjero [1].

En respuesta a dichos ataques de alto perfil, la recopilación y gestión de datos privados se está convirtiendo en algo cada vez más regulado. Dependiendo de su ubicación, el tipo de negocio que desarrolle y la naturaleza de los datos privados que controle, una organización puede verse obligada a cumplir uno o varios de los siguientes reglamentos federales y estatales:

- Marco de privacidad de Safe Harbor [3]

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

- Ley de portabilidad y responsabilidad de seguros médicos (Health Insurance Portability and Accountability Act, HIPAA) [5]

- California SB-1386 [6]

A pesar de estas regulaciones, se siguen produciendo con alarmante frecuencia violaciones de la privacidad.

Cuando la función de autocompletar está activada, algunos exploradores conservan los datos introducidos por los usuarios en distintas sesiones, lo cual podría permitir a alguien que utilice el equipo tras el usuario inicial ver la información enviada anteriormente.