El sistema de administración de dependencias automatizado Apache Ivy permite a los usuarios especificar un estado de versión, conocido como revisión dinámica, para una dependencia en lugar de enumerar la específica. Si un atacante puede comprometer el repositorio de dependencias o engañar al sistema de compilación para que descargue dependencias de un repositorio bajo su control, entonces un especificador de revisión dinámica puede ser todo lo que haga falta para que el sistema de compilación descargue y ejecute silenciosamente la dependencia comprometida. Aparte de los riesgos de seguridad, las revisiones dinámicas también introducen un elemento de riesgo en el frente de la calidad del código: Las revisiones dinámicas colocan la seguridad y la estabilidad de su software bajo el control de terceros que desarrollan y liberan las dependencias que utiliza su software.

En el momento de la compilación, Ivy se conecta al repositorio e intenta recuperar una dependencia que coincida con el estado indicado.

Ivy acepta los siguientes especificadores de revisión dinámica:

- latest.integration: selecciona la última revisión del módulo de dependencias.
- latest.[any status]: selecciona la última revisión del módulo de dependencias con al menos el estado especificado. Por ejemplo, latest.milestone seleccionará la última versión que sea un hito o un lanzamiento, y latest.release solo seleccionará el último lanzamiento.
- Cualquier revisión que termine en +: selecciona la última subrevisión del módulo de dependencias. Por ejemplo, si la dependencia existe en las revisiones 1.0.3, 1.0.7 y 1.1.2, una revisión especificada como 1.0.+ seleccionará la revisión 1.0.7.
- Intervalos de versiones: la notación matemática para intervalos, como <y>, se puede utilizar para hacer coincidir un intervalo de versiones.

Ejemplo 1: La siguiente entrada de configuración indica a Ivy que recupere la última versión de lanzamiento del componente clover:

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

Si el repositorio está comprometido, un atacante podría simplemente cargar una versión que cumpla con los criterios dinámicos para hacer que Ivy descargue una versión malintencionada de la dependencia.

Existen varias herramientas dentro del mundo del desarrollo de Java que facilitan la administración de dependencias: tanto Apache Ant como Apache Maven son sistemas de compilación que incluyen funcionalidad específicamente diseñada para facilitar la administración de dependencias, y Apache Ivy está diseñado expresamente como administrador de dependencias. Aunque existen diferencias en su comportamiento, estas herramientas comparten la funcionalidad común de descargar de forma automática dependencias externas especificadas en el proceso de compilación en tiempo de compilación. Así, resulta mucho más sencillo para un desarrollador B compilar software de la misma forma que un desarrollador A. Los desarrolladores simplemente almacenan información de dependencias en el archivo de compilación, lo que significa que cada desarrollador e ingeniero de compilación tiene una forma consistente de obtener dependencias, compilar el código y llevar a cabo la implementación sin las complicaciones de la administración de dependencias que supone la administración manual. En los siguientes ejemplos, se ilustra cómo Ivy, Ant y Maven se pueden utilizar para administrar dependencias externas como parte de un proceso de compilación.

Los desarrolladores especifican las dependencias externas en un destino de Ant mediante una tarea <get>, que recupera la dependencia especificada por la dirección URL correspondiente. Este enfoque es funcionalmente equivalente al escenario en el que un desarrollador documenta cada dependencia externa como un artefacto incluido en el proyecto de software, pero es más deseable porque automatiza la recuperación e incorporación de las dependencias cuando se realiza una compilación.

Ejemplo 1: El siguiente extracto de un archivo de configuración build.xml de Ant muestra una referencia típica a una dependencia externa:

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

Dos tipos distintos de escenarios de ataque afectan a estos sistemas: Un atacante podría comprometer el servidor que hospeda la dependencia o el servidor DNS que utiliza la máquina de compilación para redirigir las solicitudes de nombre de host del servidor que hospeda la dependencia a una máquina controlada por el atacante. Ambos escenarios dan lugar a que el atacante consiga inyectar una versión malintencionada de una dependencia en una compilación que se ejecuta en una máquina no comprometida.

Independientemente del vector de ataque utilizado para entregar la dependencia de troyano, estos escenarios comparten el elemento común de que el sistema de compilación acepta ciegamente el archivo binario malintencionado y lo incluye en la compilación. Dado que el sistema de compilación no tiene ningún recurso para rechazar el binario malintencionado y que los mecanismos de seguridad existentes, como la revisión del código, suelen centrarse en el código desarrollado internamente y no en las dependencias externas, este tipo de ataque tiene un gran potencial para pasar desapercibido a medida que se extiende por el entorno de desarrollo y, potencialmente, a producción.

Aunque existe cierto riesgo de que se introduzca una dependencia comprometida en un proceso de compilación manual, la tendencia de los sistemas de compilación automatizados a recuperar la dependencia de un origen externo cada vez que el sistema de compilación se ejecuta en un nuevo entorno aumenta enormemente la ventana de oportunidad para un atacante. Un atacante solo necesita comprometer el servidor de dependencias o el servidor DNS durante una de las muchas veces que se recupera la dependencia para comprometer la máquina en la que se está produciendo la compilación.

Existen varias herramientas dentro del mundo del desarrollo de Java que facilitan la administración de dependencias: tanto Apache Ant como Apache Maven son sistemas de compilación que incluyen funcionalidad específicamente diseñada para facilitar la administración de dependencias, y Apache Ivy está diseñado expresamente como administrador de dependencias. Aunque existen diferencias en su comportamiento, estas herramientas comparten la funcionalidad común de descargar de forma automática dependencias externas especificadas en el proceso de compilación en tiempo de compilación. Así, resulta mucho más sencillo para un desarrollador B compilar software de la misma forma que un desarrollador A. Los desarrolladores simplemente almacenan información de dependencias en el archivo de compilación, lo que significa que cada desarrollador e ingeniero de compilación tiene una forma consistente de obtener dependencias, compilar el código y llevar a cabo la implementación sin las complicaciones de la administración de dependencias que supone la administración manual. En los siguientes ejemplos, se ilustra cómo Ivy, Ant y Maven se pueden utilizar para administrar dependencias externas como parte de un proceso de compilación.

En Ivy, en lugar de enumerar las direcciones URL explícitas de las que recuperar las dependencias, los desarrolladores especifican los nombres y las versiones de las dependencias, e Ivy se basa en su configuración subyacente para identificar los servidores de los que recuperar las dependencias. Para los componentes de uso común, esta medida evita que el desarrollador tenga que investigar las ubicaciones de las dependencias.

Ejemplo 1: El siguiente extracto de un archivo ivy.xml de Ivy muestra cómo un desarrollador puede especificar múltiples dependencias externas usando su nombre y versión:

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

Dos tipos distintos de escenarios de ataque afectan a estos sistemas: Un atacante podría comprometer el servidor que hospeda la dependencia o el servidor DNS que utiliza la máquina de compilación para redirigir las solicitudes de nombre de host del servidor que hospeda la dependencia a una máquina controlada por el atacante. Ambos escenarios dan lugar a que el atacante consiga inyectar una versión malintencionada de una dependencia en una compilación que se ejecuta en una máquina no comprometida.

Independientemente del vector de ataque utilizado para entregar la dependencia de troyano, estos escenarios comparten el elemento común de que el sistema de compilación acepta ciegamente el archivo binario malintencionado y lo incluye en la compilación. Dado que el sistema de compilación no tiene ningún recurso para rechazar el binario malintencionado y que los mecanismos de seguridad existentes, como la revisión del código, suelen centrarse en el código desarrollado internamente y no en las dependencias externas, este tipo de ataque tiene un gran potencial para pasar desapercibido a medida que se extiende por el entorno de desarrollo y, potencialmente, a producción.

Aunque existe cierto riesgo de que se introduzca una dependencia comprometida en un proceso de compilación manual, la tendencia de los sistemas de compilación automatizados a recuperar la dependencia de un origen externo cada vez que el sistema de compilación se ejecuta en un nuevo entorno aumenta la ventana de oportunidad para un atacante. Un atacante solo necesita comprometer el servidor de dependencias o el servidor DNS durante una de las muchas veces que se recupera la dependencia para comprometer la máquina en la que se está produciendo la compilación.

Existen varias herramientas dentro del mundo del desarrollo de Java que facilitan la administración de dependencias: tanto Apache Ant como Apache Maven son sistemas de compilación que incluyen funcionalidad específicamente diseñada para facilitar la administración de dependencias, y Apache Ivy está diseñado expresamente como administrador de dependencias. Aunque existen diferencias en su comportamiento, estas herramientas comparten la funcionalidad común de descargar de forma automática dependencias externas especificadas en el proceso de compilación en tiempo de compilación. Así, resulta mucho más sencillo para un desarrollador B compilar software de la misma forma que un desarrollador A. Los desarrolladores simplemente almacenan información de dependencias en el archivo de compilación, lo que significa que cada desarrollador e ingeniero de compilación tiene una forma consistente de obtener dependencias, compilar el código y llevar a cabo la implementación sin las complicaciones de la administración de dependencias que supone la administración manual. En los siguientes ejemplos, se ilustra cómo Ivy, Ant y Maven se pueden utilizar para administrar dependencias externas como parte de un proceso de compilación.

En Maven, en lugar de enumerar las direcciones URL explícitas de las que recuperar las dependencias, los desarrolladores especifican los nombres y las versiones de las dependencias y Maven se basa en su configuración subyacente para identificar los servidores de los que recuperar las dependencias. Para los componentes de uso común, esta medida evita que el desarrollador tenga que investigar las ubicaciones de las dependencias.

Ejemplo 1: El siguiente extracto de un archivo pom.xml de Maven muestra cómo un desarrollador puede especificar múltiples dependencias externas usando su nombre y versión:

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

Dos tipos distintos de escenarios de ataque afectan a estos sistemas: Un atacante podría comprometer el servidor que hospeda la dependencia o el servidor DNS que utiliza la máquina de compilación para redirigir las solicitudes de nombre de host del servidor que hospeda la dependencia a una máquina controlada por el atacante. Ambos escenarios dan lugar a que el atacante consiga inyectar una versión malintencionada de una dependencia en una compilación que se ejecuta en una máquina no comprometida.

Independientemente del vector de ataque utilizado para entregar la dependencia de troyano, estos escenarios comparten el elemento común de que el sistema de compilación acepta ciegamente el archivo binario malintencionado y lo incluye en la compilación. Dado que el sistema de compilación no tiene ningún recurso para rechazar el binario malintencionado y que los mecanismos de seguridad existentes, como la revisión del código, suelen centrarse en el código desarrollado internamente y no en las dependencias externas, este tipo de ataque tiene un gran potencial para pasar desapercibido a medida que se extiende por el entorno de desarrollo y, potencialmente, a producción.

Aunque existe cierto riesgo de que se introduzca una dependencia comprometida en un proceso de compilación manual, la tendencia de los sistemas de compilación automatizados a recuperar la dependencia de un origen externo cada vez que el sistema de compilación se ejecuta en un nuevo entorno aumenta enormemente la ventana de oportunidad para un atacante. Un atacante solo necesita comprometer el servidor de dependencias o el servidor DNS durante una de las muchas veces que se recupera la dependencia para comprometer la máquina en la que se está produciendo la compilación.

CakePHP puede configurarse para que exponga información de depuración que incluya errores, advertencias, instrucciones SQL y seguimientos de la pila. La información de depuración no se debe utilizar en los entornos de producción.

Ejemplo 1:

    Configure::write('debug', 3);

el segundo parámetro para el método Configure::write() indica el nivel de depuración. Cuanto mayor sea el número, más detallados serán los mensajes de registro.

Cuanto más tiempo permanezca una sesión abierta, más oportunidades tendrá un atacante para poner en peligros las cuentas de los usuarios. Durante el tiempo que una sesión permanece activa, un usuario malintencionado puede ser capaz de forzar el robo de la contraseña de un usuario, descifrar la clave de cifrado inalámbrico de un usuario o dirigir una sesión desde un explorador abierto. Los tiempos de expiración de sesión largos pueden, además, impedir que se libere memoria y que se produzca al final una denegación de servicio si se crea un número de sesiones suficientemente largo.

Ejemplo 1: en el siguiente ejemplo se muestra CakePHP configurado con la sesión de seguridad low.

    Configure::write('Security.level', 'low');

Junto con la opción Session.timeout, las opciones Security.level definen cuánto tiempo es válida una sesión. El tiempo de espera de sesión real es igual al Session.timeout por uno de los siguientes múltiplos:

'high' = x 10
'medium' = x 100
'low' = x 300

Incluso aunque Castor cree un bloqueo en un objeto, eso no impide que otros subprocesos lean o escriban en él. Las consultas de solo lectura son también unas siete veces más rápidas en comparación con el modo compartido predeterminado.

Ejemplo 1: el ejemplo siguiente especifica el modo de consulta como SHARED, que permite tener acceso de lectura y escritura.

results = query.execute(Database.SHARED);

De forma predeterminada, Castor ejecuta consultas en modo compartido. Como el modo compartido permite acceso de lectura y escritura, no está claro para qué tipo de operación está destinada la consulta. Si el objeto se va a usar en un contexto de solo lectura, el acceso compartido agrega una sobrecarga de rendimiento innecesaria.

Ejemplo 1: el ejemplo siguiente no especifica un modo de consulta.

results = query.execute();    //missing query mode

El almacenamiento de un certificado de texto sin formato en una configuración o un archivo de manifiesto permite que cualquier persona que pueda leer el archivo acceda al recurso protegido por certificado. Los desarrolladores a veces creen que no pueden proteger la aplicación de alguien que tenga acceso a la configuración, pero esta actitud facilita el trabajo de un atacante. Las buenas pautas de administración de certificados requieren que un certificado nunca se almacene en texto sin formato.

La manipulación de ClassLoader permite a un atacante acceder a la configuración del servidor de aplicaciones subyacente y modificarla. En ciertos servidores de aplicaciones, como Tomcat 8, un atacante puede modificar estas configuraciones para cargar un shell web y ejecutar comandos arbitrarios.

Los motores de plantillas se usan para procesar contenido mediante datos dinámicos. El usuario suele controlar estos datos de contexto, a los que se les da formato mediante una plantilla para generar páginas web, correos electrónicos, etc. Los motores de plantillas permiten usar potentes expresiones de lenguaje en plantillas para procesar contenido dinámico; para ello, los datos de contexto se procesan con construcciones de codificación, como condicionales, bucles, etc. Si un atacante controla la plantilla que se desea procesar, puede inyectar expresiones que expongan los datos de contexto y ejecuten comandos arbitrarios en el explorador.

Ejemplo 1: en el ejemplo siguiente se muestra cómo recuperar una plantilla de una dirección URL y cómo se representa la información con AngularJS.

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

En este caso, $stateParams.expression tomará datos potencialmente controlados por el usuario y los evaluará como una plantilla para utilizarlos con un contexto especificado. Esto, a su vez, puede permitir a un usuario malintencionado ejecutar cualquier código que desee en el explorador, recuperando información sobre el contexto en el que se ejecute, buscando información adicional sobre cómo se crea la aplicación o convirtiéndolo en un auténtico ataque XSS.

Las operaciones aritméticas no actúan del mismo modo en valores booleanos a como lo harían en valores integrales, lo que podría ocasionar un comportamiento inesperado.

Cuando los datos de una matriz de bytes se convierten en String, no se especifica lo que ocurrirá con los datos que quedan fuera del conjunto de caracteres correspondiente. Esto puede suponer una pérdida de datos o una disminución en el nivel de seguridad cuando se necesitan datos binarios para garantizar que se cumplen las medidas de seguridad apropiadas.

Ejemplo 1: el siguiente código convierte los datos en una cadena para crear un hash.

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

Si el tamaño del archivo es menor que BUFSIZE, funcionará siempre y cuando la información de myFile se encuentre codificada igual que el conjunto de caracteres predeterminado. Sin embargo, si utiliza una codificación diferente o es un archivo binario, se perderá información. A su vez, esto provocará que el hash de SHA resultante no sea de confianza y que sea más fácil causar conflictos, especialmente si hay algún dato fuera del conjunto de caracteres predeterminado que se represente con el mismo valor, como un signo de interrogación.

En algún momento de la carrera profesional del desarrollador de .NET, surge un problema para parece tan misterioso, impenetrable e inmune a la depuración que no queda otra opción que culpar al recopilador de elementos no utilizados. Sobre todo, cuando el error está relacionado con el tiempo y el estado, existe un indicio de prueba empírica que apoya esta teoría: la inserción de una llamada a GC.Collect() a menudo parece lograr que el problema desaparezca.

En casi todos los casos que hemos visto, la llamada a GC.Collect() es el método incorrecto. De hecho, llamar a GC.Collect() puede provocar problemas de rendimiento si se realiza con demasiada frecuencia.

No hay forma de especificar qué subproceso se activará con llamadas para notify().

Ejemplo 1: en el código siguiente, notifyJob() llama notify().

public synchronized notifyJob() {
flag = true;
notify();
}
...
public synchronized waitForSomething() {
while(!flag) {
    try {
        wait();
    }
    catch (InterruptedException e)
    {
        ...
    }
}
...
}

En es caso, el desarrollador pretende activar el subproceso que llama wait(), pero es posible que notify() notifique un subproceso diferente al previsto.

Si hay varios subprocesos intentando obtener el bloqueo de un recurso, llamar sleep() mientras se mantiene un bloqueo podría causar que todos los demás subprocesos esperen a que el recurso se libere, lo que podría dar lugar a un rendimiento degradado y un interbloqueo.

Ejemplo 1: el código siguiente llama sleep() mientras mantiene un bloqueo.

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();

En algún momento de la vida profesional de todos los desarrolladores de Java, surge un problema que parece tan misterioso, impenetrable e inmune a la depuración que parece que no hay otra alternativa que culpar al recopilador de elementos no utilizados. Sobre todo, cuando el error está relacionado con el tiempo y el estado, existe un indicio de prueba empírica que apoya esta teoría: la inserción de una llamada a System.gc() a menudo parece lograr que el problema desaparezca.

En casi todos los casos que hemos visto, la llamada a System.gc() es el método incorrecto. De hecho, llamar a System.gc() puede provocar problemas de rendimiento si se realiza con demasiada frecuencia.

En la mayoría de los casos, una llamada directa a un método run() del objeto Thread indica un error. El programador tenía intención de iniciar un nuevo subproceso de control, pero llamó accidentalmente a run() en lugar de a start(), por lo que el método run() se ejecutará en el subproceso de control del autor de la llamada.

Ejemplo 1: el siguiente extracto de un programa de Java llama por error a run() en lugar de a start().

    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };

  thr.run();

En la mayoría de los casos, una llamada directa a un método stop() de un objeto Thread es un error. El programador pretende detener la ejecución de un subproceso pero no es consciente de que esa no es la mejor forma de detener un subproceso. La función stop() en Thread produce una excepción ThreadDeath en cualquier lugar del objeto Thread, lo que puede dejar a los objetos en un estado de incoherencia y filtrar recursos. Hace mucho que esta API está en desuso debido a que no es segura por naturaleza.

Ejemplo 1: el siguiente extracto de un programa de Java llama por error a Thread.stop().

  ...
  public static void main(String[] args){
    ...
    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };
    ...
    thr.start();
    ...
    thr.stop();
    ...
  }

Al parecer, el programador previó implementar para esta clase la interfaz Cloneable, ya que implementa un método llamado clone(). Sin embargo, la clase no implementa la interfaz Cloneable y el método clone() no se comportará correctamente.

Ejemplo 1: llamar clone() para esta clase dará lugar a una CloneNotSupportedException.

public class Kibitzer {
  public Object clone() throws CloneNotSupportedException {
    ...
  }
}