Las operaciones de la API definen los requisitos de seguridad para informar a los consumidores de la API sobre los parámetros de autenticación y autorización necesarios para invocarlos correctamente.

Las operaciones que hacen que la seguridad sea opcional pueden permitir a los atacantes interactuar con puntos finales de API sensibles y permitirles realizar acciones que deberían estar restringidas a cuentas de usuario específicas con privilegios explícitos.

Ejemplo 1: La siguiente especificación de OpenAPI hace que la seguridad sea opcional al incluir un objeto vacío {} en la definición security de una operación confidencial. Esto anula los requisitos de seguridad definidos globalmente y hace que la operación createUsers sea vulnerable al acceso no autorizado y no autenticado.

{
    "openapi": "3.0.0",
    "info": {
     ...
    },    
    "paths": {
      "/users": {
        "post": {
           "security": [
            {},
            {
              "my_auth": [
                "write:users"
              ]
            }
          ],
          "summary": "Create a user",
          "operationId": "createUsers",
         ...
        }
    ...
    }
}

Los métodos de autenticación inseguros pueden permitir a los atacantes obtener privilegios de administración y poner en riesgo a todo el sistema.

Nunca es una buena idea utilizar una cadena vacía como contraseña. Es demasiado fácil de adivinar.

El almacenamiento de una contraseña de texto sin formato en un archivo de configuración permite que acceda al recurso protegido por contraseña cualquiera que pueda leer el archivo. 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 contraseñas requieren que una contraseña nunca se almacene en texto sin formato.

Cuando está activada, la opción allow_url_fopen permite funciones de PHP que aceptan un nombre de archivo para trabajar con archivos remotos mediante una URL HTTP o FTP. Esta opción, que se introdujo en PHP 4.0.4 y se encuentra activada de forma predeterminada, es peligrosa porque puede permitir a los atacantes introducir contenido malintencionado en una aplicación. En el mejor de los casos, trabajar con archivos remotos hace que la aplicación sea susceptible de ataques que alteran el archivo remoto para incluir contenido malintencionado. En el peor de los casos, si los atacantes pueden controlar una URL con la que trabaja la aplicación, pueden introducir contenido malintencionado arbitrario en la aplicación suministrando una URL a un servidor remoto.

Ejemplo 1: El siguiente código abre un archivo cuyo nombre está controlado por un parámetro de solicitud y lee su contenido. Dado que el valor de $file se controla mediante un parámetro de solicitud, un atacante podría burlar las suposiciones del programador suministrando una URL a un archivo remoto.

<?php
$file = fopen ($_GET["file"], "r");
if (!$file) {
    // handle errors
}
while (!feof ($file)) {
    $line = fgets ($file, 1024);
    // operate on file content
}
fclose($file);
?>

Cuando está activada, la opción allow_url_include permite funciones de PHP que especifican un archivo para que se incluya en la página actual, como include() y require(), y acepte una URL HTTP o FTP a un archivo remoto. Esta opción, que se introdujo en PHP 5.2.0 y se encuentra desactivada de forma predeterminada, es peligrosa porque puede permitir a los atacantes introducir contenido malintencionado en una aplicación. En el mejor de los casos, incluir archivos remotos hace que la aplicación sea susceptible de ataques que alteran el archivo remoto para incluir contenido malintencionado. En el peor de los casos, si los atacantes pueden controlar una URL que la aplicación utiliza para especificar el archivo remoto que se debe incluir, pueden introducir contenido malintencionado arbitrario en la aplicación suministrando una URL a un servidor remoto.

Si el intérprete de PHP está instalado como un binario CGI, las solicitudes de recursos PHP las suele redireccionar el servidor web al intérprete. En esta situación, cuando un usuario solicita http://www.ejemplo.com/contenido/pagina.php, el servidor realiza en primer lugar las comprobaciones de control de acceso necesarias en el directorio /contenido y, a continuación, redirige el control al intérprete de PHP con una solicitud para http://www.ejemplo.com/cgi-bin/php/contenido/pagina.php.

Si la opción cgi.force_redirect, que está activada de forma predeterminada, se encuentra desactivada, los atacantes con acceso a /cgi-bin/php pueden utilizar los permisos del intérprete de PHP para acceder a documentos web arbitrarios, con lo que estarían burlando las comprobaciones de control de acceso que realiza el servidor.

La configuración enable_dl permite la carga dinámica de bibliotecas. Estas bibliotecas podrían hacer que un atacante eludiera las restricciones establecidas con la configuración open_basedir y permitirle el acceso a cualquier archivo del sistema.

La habilitación de enable_dl puede facilitar a los atacantes el aprovechamiento de otras vulnerabilidades.

Cuando la opción file_uploads está activada, permite a los usuarios de PHP que carguen archivos arbitrarios al servidor. Permitir a los usuarios que carguen archivos no representa una vulnerabilidad de seguridad en sí misma. Sin embargo, esta función puede permitir distintos ataques dado que brinda a los usuarios malintencionados una vía para introducir datos en el entorno de servidor.

Independientemente del lenguaje en el que esté escrito un programa, los ataques más devastadores normalmente incluyen la ejecución remota de código, con la cual un atacante consigue ejecutar código malintencionado en el contexto del programa. Si se permite a los atacantes que carguen archivos a un directorio accesible desde la Web que hace que estos archivos se pasen al intérprete de PHP, los atacantes pueden provocar que el código malintencionado contenido en los archivos se ejecute en el servidor.

Ejemplo 1: el siguiente código procesa los archivos cargados y los mueve a un directorio de la raíz web. Los atacantes pueden cargar archivos de origen de PHP malintencionados a este programa y, a continuación, solicitarlos del servidor, lo que hará que el intérprete de PHP los ejecute.

<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
    echo "Valid upload received\n";
} else {
    echo "Invalid upload rejected\n";
} ?>

Incluso en el caso de un programa que almacene los archivos cargados en un directorio que no sea accesible desde la Web, los atacantes pueden conseguir introducir contenido malintencionado en el entorno del servidor para preparar otros ataques. Si el programa es susceptible a las vulnerabilidades de manipulación de rutas, inserción de comandos o introducción remota, un atacante puede cargar un archivo con contenido malintencionado y provocar que el programa lo lea o ejecute aprovechando otra vulnerabilidad.

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 directorios especificados en php.ini. Si no se especifican directorios mediante la opción open_basedir, los programas que se ejecutan bajo PHP tienen acceso completo a archivos arbitrarios en el sistema de archivos local, lo que puede permitir a los atacantes leer, escribir o crear archivos a los que no deberían tener acceso.

No especificar un conjunto restrictivo de directorios con open_basedir puede facilitar a los atacantes la explotación de otras vulnerabilidades.

Aunque la opción open_basedir es una bendición general para la seguridad, la implementación adolece de una condición de carrera que puede permitir a los atacantes eludir sus restricciones en algunas circunstancias [2]. Existe una condición de carrera de tiempo de comprobación, tiempo de uso (TOCTOU) entre el momento en que PHP realiza la comprobación de permisos de acceso y cuando se abre el archivo. Al igual que con las condiciones de carrera del sistema de archivos en otros lenguajes, esta condición de carrera puede permitir a los atacantes reemplazar un vínculo simbólico a un archivo que pasa una verificación de control de acceso por otro para el cual la prueba fallaría, obteniendo así acceso al archivo protegido.

La ventana de vulnerabilidad para un ataque de esta naturaleza se da en el período de tiempo entre que se realiza la comprobación del acceso y se abre el archivo. Incluso si las llamadas se suceden una detrás de otra, los sistemas operativos modernos no garantizan la cantidad de código que se ejecuta antes de que el proceso abandone la CPU. Los atacantes disponen de varias técnicas para ampliar la duración de la ventana de oportunidad con el fin de facilitar las vulnerabilidades, pero incluso con una ventana pequeña, un intento de explotación puede simplemente repetirse una y otra vez hasta que tenga éxito.

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.

Cuando la opción de configuración open_basedir está presente, intenta impedir a los programas de PHP que trabajen con archivos ubicados fuera del los árboles de directorios especificados en php.ini. 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 vulnerabilidad puede permitir a los atacantes que sustituyan un symlink a un archivo que pasa la 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.

Los nombres de form-bean duplicados no sirven para nada, ya que solo se registrará la última entrada cuando se utilice el mismo nombre en varias etiquetas <form-bean>.

Ejemplo 1: La siguiente configuración tiene dos entradas de form-bean con el mismo nombre.

<form-beans>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaActionForm">
    <form-property name="favoriteColor" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts usa el atributo path para localizar el recurso necesario para controlar una solicitud. Dado que la ruta de acceso es una ubicación relativa al módulo, es un error si no comienza con un carácter "/".

Ejemplo 1: La siguiente configuración contiene una ruta de acceso vacía.

<global-exceptions>
  <exception key="global.error.invalidLogin" path="" scope="request" type="InvalidLoginException" />
</global-exceptions>

Ejemplo 2: La siguiente configuración utiliza una ruta de acceso que no empieza por un carácter "/".

<global-forwards>
  <forward name="login" path="Login.jsp" />
</global-forwards>

La especificación de Struts requiere un atributo input siempre que una acción con nombre devuelva errores de validación [2]. El atributo input especifica la página utilizada para mostrar mensajes de error cuando ocurren errores de validación.
Ejemplo 1: La siguiente configuración define una acción de validación con nombre, pero no especifica un atributo input.

<action-mappings>
  <action   path="/Login"
            type="com.LoginAction"
            name="LoginForm"
            scope="request"
            validate="true" />
</action-mappings>

La etiqueta <exception> requiere que se defina un tipo de excepción. La ausencia de un atributo type o que esté vacío indica un controlador de excepciones superfluo o una omisión accidental. Si un desarrollador tenía la intención de controlar una excepción, pero olvidó definir el tipo de excepción, entonces la aplicación podría filtrar información confidencial sobre el sistema.
Ejemplo 1: La siguiente configuración omite el tipo de la etiqueta <exception>.

  <global-exceptions>
    <exception
      key="error.key"
      handler="com.mybank.ExceptionHandler"/>
  </global-exceptions>