Cuando safe_mode está activado, la opción safe_mode_exec_dir restringe la ejecución de comandos por parte de PHP a los comandos de los directorios especificados. Aunque la ausencia de una entrada safe_mode_exec_dir no supone una vulnerabilidad de seguridad en sí misma, los atacantes pueden aprovechar esta indulgencia añadida junto con otras vulnerabilidades para realizar acciones más peligrosas.

Cuando está presente, la opción de configuración open_basedir intenta evitar que los programas PHP operen en archivos fuera de los árboles de directorio especificados en el archivo php.ini. Si se especifica el directorio de trabajo con ., puede cambiarlo potencialmente un atacante que usechdir().

Aunque la opción open_basedir es un beneficio general para la seguridad, la implementación sufre una condición de carrera que puede permitir a los atacantes burlar las restricciones en algunas circunstancias [2]. Existe una condición de carrera de hora de comprobación/hora de uso (TOCTOU) entre la hora a la que PHP realiza la comprobación de permiso de acceso y el momento en que se abre el archivo. Como ocurre con las condiciones de carrera de los sistemas de archivos en otros lenguajes, esta condición de carrera puede permitir a los atacantes que sustituyan un symlink a un archivo que pasa una comprobación de control de acceso por otro que no superaría la prueba, obteniendo así acceso al archivo protegido.

Las oportunidades de vulnerabilidad para tal ataque se dan en el periodo de tiempo que va desde que se realiza la comprobación de acceso hasta que se abre el archivo. Aunque las llamadas se realizan muy seguidas, los sistemas operativos modernos no ofrecen ninguna garantía acerca de la cantidad de código que se ejecuta hasta que el proceso da paso a la CPU. Los atacantes cuentan con distintas técnicas para ampliar las oportunidades con el fin de aprovechar las vulnerabilidades con mayor facilidad pero, incluso con pocas oportunidades, un intento de aprovechar las vulnerabilidades puede simplemente repetirse una y otra vez hasta conseguir su objetivo.

Cuando está activada, la opción register_globals hace que PHP registre todas las variables EGPCS (entorno, GET, POST, cookie y servidor) de forma global, por lo que se puede acceder a ellas en cualquier ámbito de cualquier programa de PHP. Esta opción anima a los programadores a escribir programas más o menos desconocedores del origen de los valores en los que confían, lo cual puede provocar un comportamiento inesperado en entornos bienintencionados y deja la puerta abierta a los atacantes en entornos malintencionados. Al reconocerse las peligrosas implicaciones de seguridad de register_globals, esta opción estaba desactivada de forma predeterminada en PHP 4.2.0 y se eliminó en PHP 6.

Ejemplo 1: el siguiente código es vulnerable a los scripts entre sitios. El programador asume que el valor de $username se origina desde la sesión controlada por el servidor, pero un atacante puede suministrar un valor malintencionado para $username como un parámetro de solicitud. Con register_globals activado, este código incluirá un valor malintencionado enviado por un atacante en el contenido HTML dinámico que genere.

<?php
if (isset($username)) {
    echo "Hello <b>$username</b>";
} else {
    echo "Hello <b>Guest</b><br />";
    echo "Would you like to login?";

}
?>

La opción safe_mode es una de las funciones de seguridad más importantes de PHP. Cuando safe_mode está desactivado, PHP trabaja en los archivos con los permisos del usuario que lo invocó, que por lo general es un usuario con privilegios. Aunque configurar PHP con safe_mode desactivado no supone una vulnerabilidad de seguridad en sí misma, los atacantes pueden aprovechar esta indulgencia añadida junto con otras vulnerabilidades para realizar acciones más peligrosas.

Cuando la opción session.use_trans_sid está activada, PHP pasa el id. de sesión en la URL, lo cual hace mucho más sencillo para los atacantes secuestrar las sesiones activas o engañar a los usuarios para que utilicen una sesión existente que ya controla un atacante.

Los parámetros que se pasan en la URL son más visibles que los parámetros POST y los valores de las cookies ya que a menudo aparecen en los historiales de los navegadores, en los marcadores, en los archivos de registro y en otras ubicaciones de elevada exposición. Si los atacantes conocen el identificador de sesión secreto de una sesión activa en un sistema, podrían suministrar ese identificador de sesión al programa para secuestrar la sesión del usuario.

Además del secuestro de sesiones, la exposición del identificador de sesión en la URL también facilita los ataques de fijación de sesión. En la forma convencional de aprovechar las vulnerabilidades de fijación de la sesión, el atacante crea una nueva sesión en una aplicación web y graba el identificador de sesión asociado. A continuación, el atacante hace que la víctima se autentique en el servidor con ese identificador de sesión, con lo que el atacante obtiene acceso a la cuenta del usuario a través de la sesión activa. Pasar el identificador de la sesión en la URL permite a los atacantes llegar a un gran número de posibles víctimas enviando distintas URL que incluyen un identificador de sesión comprometido a las víctimas a través del correo electrónico u otros mecanismos de comunicación masiva.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta llamada de método no puede tener nunca errores" y "no importa si se produce un error en esta llamada". Cuando un programador ignora una condición, implícitamente indica que está funcionando según uno de estos supuestos.

Ejemplo 1: el siguiente fragmento de código ignora una condición de error que puede darse durante una transacción de CICS.

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

Si una transacción nunca hubiese fallado con esta condición de error, el programa debería seguir ejecutándose como si nada inusual hubiese ocurrido. El programa no registrará ninguna prueba que indique la situación especial, evitando potencialmente cualquier intento posterior de explicar el comportamiento del programa.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta llamada de método no puede tener nunca errores" y "no importa si se produce un error en esta llamada". Cuando un programador ignora una excepción, implícitamente indica que está funcionando según uno de estos supuestos.

Ejemplo 1: El fragmento de código siguiente ignora una excepción iniciada en pocas ocasiones desde doExchange().

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

Si una RareException se fuese a iniciar en algún momento, el programa seguiría ejecutándose como si no hubiese ocurrido nada inusual. El programa no registrará ninguna prueba que indique la situación especial, evitando potencialmente cualquier intento posterior de explicar el comportamiento del programa.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta llamada de función no puede tener nunca errores" y "no importa si se produce un error en esta llamada". Cuando un programador ignora una excepción, implícitamente indica que está funcionando según uno de estos supuestos.

Ejemplo 1: el siguiente código pasa por alto varias excepciones que se podrían producir al ejecutar la instrucción INSERT.

PROCEDURE do_it_all
IS
BEGIN
  BEGIN
    INSERT INTO table1 VALUES(...);
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;
END do_it_all;

Se podría producir una excepción porque no existe la tabla, no se ha proporcionado un valor requerido o por alguna otra razón. Si se produce un error, no hay ninguna manera de saberlo porque el procedimiento no informa del error ni registra el tipo de error producido.

Si los bloques catch son varios, pueden volverse repetitivos, pero si se "condensan" bloques catch obteniendo una clase de alto nivel como Exception, se pueden ocultar excepciones que requieran un tratamiento especial o que no se deberían obtener en este punto del programa. Si se obtiene una excepción demasiado amplia, básicamente hace fracasar el propósito de las excepciones tipificadas de Java, y puede resultar particularmente peligroso si el programa se desarrolla y comienza a iniciar nuevos tipos de excepciones. Los nuevos tipos de excepciones quedarán desatendidas.

Ejemplo 1: El fragmento de código siguiente trata tres tipos de excepciones de manera idéntica.

  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }

A primera vista, puede parecer preferible tratar estas excepciones en un solo bloque catch, de la siguiente forma:

  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }

No obstante, si se modifica doExchange() para iniciar un nuevo tipo de excepción que debería tratarse de forma diferente, el amplio bloque catch evitará que el compilador señale la situación. Es más, el nuevo bloque de filtrado ahora también administra las excepciones derivadas de RuntimeException como ClassCastException y NullPointerException, que no es el propósito del programador.

Declarar un método para lanzar Exception o Throwable dificulta a los autores de llamada hacer un buen trabajo en cuanto al tratamiento y la recuperación de errores. El mecanismo de excepciones de Java se ha configurado para facilitar a los autores de llamada la anticipación de qué puede salir mal y escribir código para administrar cada circunstancia de excepción específica. Declarar que un método lance una forma genérica de excepción frustra este sistema.

Ejemplo 1: El método siguiente lanza tres tipos de excepciones.

public void doExchange()
  throws IOException, InvocationTargetException,
         SQLException {
  ...
}

Aunque pueda parecer que es más organizado a la hora de escribir

public void doExchange()
  throws Exception {
  ...
}

al hacerlo se puede alterar la capacidad del autor de llamada para comprender y administrar las excepciones que se producen. Es más, si una revisión posterior de doExchange() introduce un nuevo tipo de excepción que debería tratarse de forma diferente a las excepciones anteriores, no hay una forma fácil de exigir este requisito.

Habitualmente, los programadores obtienen NullPointerException bajo tres circunstancias:

1. El programa contiene una anulación de referencia de puntero nulo. Obtener la excepción resultante era más sencillo que solucionar el problema subyacente.

2. El programa inicia de forma explícita una NullPointerException para señalar una condición de error.

3. El código es parte de un test de aprovechamiento que proporciona una entrada inesperada en las clases que se están probando.

De estas tres circunstancias, solo la última es aceptable.

Ejemplo 1: El código siguiente obtiene de forma errónea una NullPointerException.

  try {
    mysteryMethod();
  }
  catch (NullPointerException npe) {
  }

Habitualmente, los programadores obtienen NullReferenceException bajo tres circunstancias:

1. El programa contiene una anulación de referencia de puntero nulo. Obtener la excepción resultante era más sencillo que solucionar el problema subyacente.

2. El programa inicia de forma explícita una NullReferenceException para señalar una condición de error.

3. El código es parte de un test de aprovechamiento que proporciona una entrada inesperada en las clases que se están probando.

De estas tres circunstancias, solo la última es aceptable.

Ejemplo 1: El código siguiente obtiene de forma errónea una NullReferenceException.

  try {
    MysteryMethod();
  }
  catch (NullReferenceException npe) {
  }

Una instrucción return dentro de un bloque finally provocará que todas las excepciones que se puedan lanzar en el bloque try se descarten.

Ejemplo 1: en la siguiente cita de código, la MagicException lanzada por la segunda llamada para doMagic con true transferido a ella nunca se entregará al autor de llamada. La instrucción return dentro del bloque finally provocará que la excepción se descarte.

public class MagicTrick {

public static class MagicException extends Exception { }

public static void main(String[] args) {

  System.out.println("Watch as this magical code makes an " +
                     "exception disappear before your very eyes!");

  System.out.println("First, the kind of exception handling " +
                     "you're used to:");
  try {
    doMagic(false);
  } catch (MagicException e) {
    // An exception will be caught here
    e.printStackTrace();
  }

  System.out.println("Now, the magic:");
  try {
    doMagic(true);
  } catch (MagicException e) {
    // No exception caught here, the finally block ate it
    e.printStackTrace();
  }
  System.out.println("tada!");
}

public static void doMagic(boolean returnFromFinally)
throws MagicException {

  try {
    throw new MagicException();
  }
  finally {
    if (returnFromFinally) {
      return;
    }
  }
}

}

Los errores ThreadDeath solo deben filtrarse si una aplicación tiene que limpiar después de finalizar de forma asíncrona. Si se filtra un error ThreadDeath, es importante que se vuelva a lanzar para que el subproceso finalice realmente. El propósito de lanzar ThreadDeath es detener un subproceso. Si ThreadDeath es absorbido, puede impedir que un subproceso se detenga y dé lugar a un comportamiento inesperado, puesto que quien haya lanzado originalmente ThreadDeath espera que el subproceso se detenga.

Ejemplo 1: el código siguiente filtra ThreadDeath, pero no lo vuelve a lanzar.

try
{
//some code
}
catch(ThreadDeath td)
{
//clean up code
}

En Java, los bloques finally siempre se ejecutan después de su bloque try-catch correspondiente y se utilizan frecuentemente para liberar recursos asignados, como controladores de archivos o cursores de base de datos. Lanzar una excepción en un bloque finally puede derivar el código de limpieza crítico, puesto que la ejecución normal del programa se interrumpirá.

Ejemplo 1: en el código siguiente, la llamada para stmt.close() se deriva cuando se lanza la FileNotFoundException.

public void processTransaction(Connection conn) throws FileNotFoundException
{
    FileInputStream fis = null;
    Statement stmt = null;
    try
    {
        stmt = conn.createStatement();
        fis = new FileInputStream("badFile.txt");
        ...
    }
    catch (FileNotFoundException fe)
    {
        log("File not found.");
    }
    catch (SQLException se)
    {
        //handle error
    }
    finally
    {
        if (fis == null)
        {
            throw new FileNotFoundException();
        }

        if (stmt != null)
        {
            try
            {
                stmt.close();
            }
            catch (SQLException e)
            {
                log(e);
            }
        }
    }
}

Las vulnerabilidades de excepción no administradas se producen cuando:

1. Se arroja una excepción.

2. La excepción no se administra correctamente antes de que salga de la página actual.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta función no puede tener nunca errores" y "no importa si se produce un error en esta operación". Cuando un programador no puede detectar una excepción que puede arrojar una operación, implícitamente indica que está funcionando según uno de estos supuestos.

Las vulnerabilidades de excepción SSL no administradas se producen cuando:

1. Se lanza una excepción específica de SSL.

2. La excepción no se administra explícitamente.

Las excepciones específicas de SSL javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLKeyException y javax.net.ssl.SSLPeerUnverifiedException transmiten errores importantes relacionados con una conexión SSL. Si estos errores no se administran explícitamente, la conexión puede dejarse en un estado inesperado y potencialmente inseguro.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta función no puede tener nunca errores" y "no importa si se produce un error en esta operación". Cuando un programador no puede detectar una excepción que puede arrojar una operación, implícitamente indica que está funcionando según uno de estos supuestos.

En programación es una práctica recomendable compartir un solo objeto de registrador entre todas las instancias de una clase concreta y usar el mismo registrador para toda la duración del programa.

Ejemplo 1: la siguiente instrucción declara erróneamente un registrador no estático.

private final Logger logger =
            Logger.getLogger(MyClass.class);

Las prácticas recomendadas de registro dictan el uso de un solo registrador para cada clase.

Ejemplo 1: el código siguiente declara erróneamente varios registradores.

public class MyClass {
  private final static Logger good =
            Logger.getLogger(MyClass.class);
  private final static Logger bad =
            Logger.getLogger(MyClass.class);
  private final static Logger ugly =
            Logger.getLogger(MyClass.class);
  ...
}

Ejemplo 1: El primer programa Java que un desarrollador aprende a escribir tiene el siguiente aspecto:

public class MyClass
  ...
    System.out.println("hello world");
  ...
}

Aunque muchos programadores continúan aprendiendo los matices y sutilezas de Java, una cantidad sorprendente de ellos se quedan en esta primera lección y nunca dejan de escribir mensajes para salida estándar usando System.out.println().

El problema es que escribir directamente a salida estándar o error estándar a menudo se utiliza como una forma no estructurada de registro. Las interfaces de registro estructuradas proporcionan características como niveles de registro, formateo uniforme, un identificador de registros, marcas de tiempo y, puede que de forma más crítica, la capacidad para dirigir mensajes de registro al sitio adecuado. Cuando el uso de los flujos de salida del sistema se confunde con el código que utiliza los registros de forma adecuada, a menudo el resultado es un registro en buen estado al que le falta información esencial.

Los desarrolladores aceptan ampliamente la necesidad de los registros estructurados, aunque muchos siguen utilizando los flujos de salida del sistema en el desarrollo de "pre-producción". Si el código que está revisando está más allá de las fases iniciales de desarrollo, el uso de System.out o System.err podría indicar un descuido en el paso a un sistema estructurado de registro.