OWASP_WSTG_ASVS_es.json

[
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/01-Information_Gathering/01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage"
                ],
                "locale": "es",
                "title": "Divulgación de información sensible indexada en buscadores web u otras fuentes públicas",
                "vulnType": "OWASP WSTG",
                "description": "<p>Los motores de búsqueda pueden utilizarse para realizar el reconocimiento de sitios y aplicaciones web. Existen elementos directos e indirectos en el descubrimiento y reconocimiento de motores de búsqueda: los métodos directos están relacionados con la búsqueda en los índices y el contenido asociado de las cachés, mientras que los métodos indirectos están relacionados con el aprendizaje de información sensible sobre el diseño y la configuración mediante la búsqueda en foros, grupos de noticias y sitios web.</p><p>Utilizando motores de búsqueda como Google, DuckDuckGo o Bing es posible encontrar información potencialmente sensible como:</p><ul><li><p>Diagramas y configuraciones de red.</p></li><li><p>Mensajes archivados y correos electrónicos de administradores u otro personal clave.</p></li><li><p>Procedimientos de inicio de sesión y formatos de nombres de usuario.</p></li><li><p>Nombres de usuario, contraseñas y claves privadas.</p></li><li><p>Archivos de configuración de terceros o servicios en la nube.</p></li><li><p>Contenido de mensajes de error reveladores.</p></li><li><p>Versiones de desarrollo, pruebas, pruebas de aceptación del usuario (UAT) y versiones de prueba de las aplicaciones.</p></li></ul>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Antes de publicar una aplicación, es esencial tener en cuenta la sensibilidad de los datos expuestos en ella para evitar la divulgación accidental de información sensible.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server",
                    "https://cwe.mitre.org/data/definitions/200.html",
                    "https://wiki.owasp.org/index.php/Testing_for_Web_Application_Fingerprint_(OWASP-IG-004)"
                ],
                "locale": "es",
                "title": "Revelación de información sensible en cabeceras HTTP",
                "vulnType": "OWASP WSTG",
                "description": "<p>Esta situación se produce cuando la aplicación revela el tipo y/o la versión de un componente interno que se está utilizando revelando información en las cabeceras del protocolo HTTP. A través de esta información, se puede revelar el sistema operativo, uno de sus servicios (web, correo, transferencia de archivos...), o uno de sus componentes (PHP, mod_proxy, WebDAV...).</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Para evitar este tipo de divulgación de la información, es necesario ocultar la información que aparece en las cabeceras del protocolo.Para evitar este tipo de divulgación de la información, es necesario ocultar la información que aparece en las cabeceras del protocolo.</p><p>Una corrección, que suele ser una actualización del mismo o la aplicación de un parche específico, suele ser necesaria para solucionar las vulnerabilidades publicadas de los componentes detectados y requiere atenerse a las recomendaciones del fabricante del software vulnerable para resolver las vulnerabilidades.</p><p>Habría que decidir si se deja de ofrecer el servicio hasta que se encuentre una solución o se corre el riesgo de hacerlo incluso en ausencia de una solución publicada.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/08-Fingerprint_Web_Application_Framework"
                ],
                "locale": "es",
                "title": "Revelación de información sensible en las cookies de las aplicaciones",
                "vulnType": "OWASP WSTG",
                "description": "<p>La configuración de las cookies expone información sensible tanto en el nombre preestablecido de la cookie como en su contenido, lo que conduce a esta vulnerabilidad. Por ejemplo, una cookie con el nombre del software con el que se creó.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Para evitar este tipo de divulgación de información, es necesario ocultar los datos que aparecen en las cookies o alterar su nombre o contenido.</p><p>Para solucionar las vulnerabilidades divulgadas públicamente de los componentes detectados, suele ser necesario seguir las recomendaciones del fabricante para resolver las vulnerabilidades, solución que suele implicar una actualización del software o la aplicación de un parche concreto.</p><p>Habría que decidir si dejar de ofrecer el servicio hasta que se encuentre una solución o arriesgarse a hacerlo incluso en ausencia de una solución publicada.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/03-Review_Webserver_Metafiles_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html",
                    "https://developers.google.com/search/docs/advanced/robots/intro"
                ],
                "locale": "es",
                "title": "Divulgación de información sensible en el archivo \"robots.txt",
                "vulnType": "OWASP WSTG",
                "description": "<p>Algunos programas utilizan robots araña para navegar automáticamente por los sitios web en un esfuerzo por indexarlos. Cualquier usuario puede acceder al archivo \"robots.txt\", que se utiliza para especificar los directorios y recursos que el administrador desea que se indexen y los que no. La configuración de este archivo debe manejarse con especial precaución porque puede revelar qué recursos son sensibles.</p><p>El archivo \"robots.txt\" contiene recursos sensibles que podrían ser utilizados por un atacante para lanzar ataques más sofisticados y precisos utilizando los datos recopilados.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>El archivo \"robots.txt\" no debe utilizarse como método para restringir el acceso a las zonas inseguras de la aplicación. Más allá de su protección frente a robots de tipo araña, el acceso a estas secciones debe controlarse adecuadamente frente a posibles ataques.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/03-Review_Webserver_Metafiles_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html"
                ],
                "locale": "es",
                "title": "Divulgación de información sensible en el archivo 'sitemap.xml",
                "vulnType": "OWASP WSTG",
                "description": "<p>Un desarrollador u organización puede proporcionar detalles sobre los recursos disponibles en la aplicación y sus conexiones en el archivo \"sitemap.xml\".</p><p>El archivo \"sitemap.xml\" contiene recursos sensibles que pueden ser utilizados por un atacante para lanzar ataques más avanzados y precisos utilizando los datos que ha recopilado.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Se aconseja eliminar cualquier dato sensible del archivo \"sitemap.xml\" que no sea necesario para el desarrollo de la aplicación.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/03-Review_Webserver_Metafiles_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html"
                ],
                "locale": "es",
                "title": "Divulgación de información sensible en el archivo \"security.txt",
                "vulnType": "OWASP WSTG",
                "description": "<p>Una norma propuesta permite que las páginas web especifiquen las políticas de seguridad y la información de contacto en el archivo \"security.txt\".</p><p>El archivo \"security.txt\" contiene información sensible que podría ser utilizada por un atacante para lanzar ataques más sofisticados y precisos utilizando los datos recopilados.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Se aconseja eliminar todos los datos privados del archivo \"security.txt\" que no sean necesarios para el desarrollo de la aplicación.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/03-Review_Webserver_Metafiles_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html"
                ],
                "locale": "es",
                "title": "Revelación de información sensible en el archivo 'humans.txt'",
                "vulnType": "OWASP WSTG",
                "description": "<p>El archivo \"humans.txt\" es un proyecto para conocer mejor a las personas que crean un sitio web.</p><p>El archivo \"humans.txt\" contiene información sensible que podría ser utilizada por un atacante para lanzar ataques más sofisticados y precisos utilizando los datos recopilados.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Se aconseja borrar todos los datos privados del archivo \"humans.txt\" que no sean necesarios para el desarrollo de la aplicación.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Webpage_Content_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/540.html"
                ],
                "locale": "es",
                "title": "Revelación de información sensible en el código fuente",
                "vulnType": "OWASP WSTG",
                "description": "<p>Esta situación se produce cuando el análisis de un archivo que se ha cargado en un servidor web revela información relacionada con el servidor que puede utilizarse para planificar nuevos ataques, como el tipo y la versión de las aplicaciones que se están utilizando, los componentes o extensiones que están en uso, las credenciales...</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Para evitar fugas de información sensible, hay que modificar el código fuente HTML que envía el servidor.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/497.html"
                ],
                "locale": "es",
                "title": "Revelación de información sensible porque el modo de depuración está activado",
                "vulnType": "OWASP WSTG",
                "description": "<p>En ocasiones es posible mostrar datos técnicos o secretos comerciales dentro de la aplicación utilizando un \"parámetro de depuración habilitado\". Como resultado, el atacante aumenta el tamaño de su superficie de ataque al conocer mejor el funcionamiento de la aplicación. Habilitar la bandera de depuración puede ocasionalmente incluso resultar en ataques de ejecución de código (versiones antiguas de werkzeug)</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Las aplicaciones de producción nunca deberían generar información interna como trazas de pila y mensajes de error, a menos que la envíen directamente a un registro que el usuario final no pueda ver. Antes de escribirlo en el archivo de registro, todo el texto de los mensajes de error debe estar codificado con entidades HTML para evitar posibles ataques de secuencias de comandos entre sitios contra el visor de registros.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Webpage_Content_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html"
                ],
                "locale": "es",
                "title": "Divulgación de información sensible (genérico)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Una contraseña, por ejemplo, es una información sensible que puede ser valiosa por sí misma o utilizarse para lanzar otros ataques más graves (como obtener un mensaje de error incontrolado). El contenido de un mensaje de error puede ser utilizado por un atacante para apoyar el lanzamiento de un ataque diferente, más centrado. Un intento de explotar un fallo de enumeración de directorios o de path traversal, por ejemplo, podría revelar la ruta completa a la aplicación instalada.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Cree zonas \"seguras\" dentro del sistema donde puedan definirse claramente los límites de confianza. No permitas que ninguna información sensible traspase las líneas de confianza, y extrema las precauciones siempre que interactúes con un compartimento fuera de una zona segura.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/200.html",
                    "https://cwe.mitre.org/data/definitions/359.html"
                ],
                "locale": "es",
                "title": "Revelación de credenciales (fuga de credenciales)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Ha sido posible verificar y comprobar la existencia de archivos que contienen información sensible, como credenciales válidas para acceder a otros sistemas, en diversos puntos finales. No es necesario ningún tipo de cookie o sistema de autenticación anterior para acceder a estas credenciales.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Independientemente del software para el que se utilicen estas credenciales de usuario, nunca se aconseja exponer archivos sensibles que expongan credenciales de usuario.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/798.html"
                ],
                "locale": "es",
                "title": "Uso de credenciales codificadas",
                "vulnType": "OWASP WSTG",
                "description": "<p>Para su propio cifrado interno de datos, la comunicación saliente con componentes externos y la autenticación entrante, el software tiene credenciales codificadas, como una contraseña o una clave criptográfica. Con frecuencia, las credenciales codificadas producen una brecha de seguridad considerable que permite a un atacante eludir la configuración de autenticación establecida por el administrador del software.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Si se utilizan contraseñas codificadas, es casi seguro que usuarios malintencionados obtendrán acceso a la cuenta en cuestión.</p></li><li><p>Control de acceso: Ejecución no autorizada de código o comandos: Esta debilidad puede llevar a la exposición de recursos o funcionalidades a actores no intencionados, posiblemente proporcionando a los atacantes información sensible o incluso ejecutar código arbitrario.</p></li></ul>",
                "remediation": "<p>En lugar de secretos y claves de API estáticos, utilice testigos de sesión.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Webpage_Content_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html",
                    "https://capec.mitre.org/data/definitions/118.html"
                ],
                "locale": "es",
                "title": "Revelación de información sensible en los metadatos de los archivos disponibles en la aplicación.",
                "vulnType": "OWASP WSTG",
                "description": "<p>El término \"metadatos\" se refiere a la información sobre un documento que es principalmente de naturaleza descriptiva. También puede incluir información sobre administración y gestión.</p><p>El conjunto de datos que caracterizan o definen una información concreta a la que están vinculados se conoce como metadatos. Al mejorar la información a la que están vinculados, los metadatos hacen que la interpretación de esa información por parte de un ordenador sea mucho más completa y mejoran la recuperación de documentos.</p><p>A través de sus metadatos, se ha descubierto que se han utilizado para extraer información sensible.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Se aconseja eliminar los metadatos de todos los archivos disponibles en la aplicación antes de hacerlos accesibles a la red para solucionar esta vulnerabilidad.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/04-Enumerate_Applications_on_Webserver",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/08-Fingerprint_Web_Application_Framework"
                ],
                "locale": "es",
                "title": "Divulgación de información sensible en contenidos predeterminados",
                "vulnType": "OWASP WSTG",
                "description": "<p>Esto ocurre cuando los archivos por defecto se dejan abiertos tras la instalación de un servicio o aplicación. Debido al tipo de información que divulgan, como el tipo y la versión del servidor Web que se está utilizando, la existencia de archivos predeterminados en un servidor Web supone una amenaza.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Para solucionarlo, hay que eliminar todos los archivos predeterminados que no sean necesarios para el funcionamiento del servidor, incluidas las páginas predeterminadas que se instalaron después del servidor.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/04-Enumerate_Applications_on_Webserver",
                    "https://cwe.mitre.org/data/definitions/538.html",
                    "https://www.owasp.org/index.php/Full_Path_Disclosure"
                ],
                "locale": "es",
                "title": "Revelación de rutas y directorios internos del servidor",
                "vulnType": "OWASP WSTG",
                "description": "<p>Este hecho se produce siempre que se puede determinar la ruta absoluta de un servidor web o de una aplicación alojada en él mediante cualquier mecanismo, como el envío de un mensaje de error, el seguimiento del envío de parámetros, etc.</p><p>Se puede encontrar el directorio absoluto del servidor, donde se almacena el contenido de la web.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Dependiendo del tipo de fallo que haya provocado la revelación, el mejor curso de acción variará. Si se obtuvo a raíz de un mensaje de error, es esencial cambiar estos mensajes de error del servidor por un mensaje genérico que se limite a informar de una situación anormal sin entrar en más detalles sobre su causa. Es necesario alterar la lógica de la aplicación para que sólo se muestren las rutas relativas o no se muestren en absoluto si esa ruta se ha hecho pública mediante un parámetro de la aplicación.</p><p>Se aconseja cambiar los mensajes de error del servidor por un mensaje genérico que simplemente informe de que algo es anormal sin entrar en más detalles sobre su causa.</p><p>Para ello debe utilizarse el fichero de configuración.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/04-Enumerate_Applications_on_Webserver",
                    "https://cwe.mitre.org/data/definitions/548.html"
                ],
                "locale": "es",
                "title": "Listado de directorios",
                "vulnType": "OWASP WSTG",
                "description": "<p>El listado de directorios es una función que, cuando está activada, hace que los servidores web listen el contenido de un directorio cuando no hay ningún archivo de índice (por ejemplo, index.php o index.html). Por lo tanto, si se realiza una solicitud a un directorio en el que el listado de directorios está activado y no hay ningún archivo de índice, aunque haya archivos de una aplicación web, el servidor web envía un listado de directorios como respuesta.</p><p>Cuando esto ocurre hay un problema de fuga de datos, y los atacantes pueden usar estos datos para construir otros ataques, incluyendo vulnerabilidades de ataque directo como XSS. Esto puede ser útil en entornos de desarrollo, pero no es una buena práctica para servidores de producción.</p><p>El hecho de que un servidor web permita listar un directorio tiene varias implicaciones de seguridad:</p><ul><li><p>Permite a los usuarios descargar ciertos archivos o acceder a ciertos directorios que de otra forma no sería posible.</p></li><li><p>Puede mostrar información que ayude a un atacante a averiguar detalles técnicos sobre el servidor web.</p></li><li><p>Muestra todo el contenido del directorio, sin discriminar entre los archivos que pueden ser públicos y los que deben permanecer privados.</p></li></ul><p>Esto suele ser accidental, ya que un servidor web por defecto muestra un listado de directorios en caso de que el archivo índice no sea válido o no exista.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de ficheros o directorios: Exponer el contenido de un directorio puede hacer que un atacante acceda al código fuente o proporcionarle información útil para idear exploits, como las horas de creación de los archivos o cualquier información que pueda estar codificada en los nombres de los archivos. El listado de directorios también puede comprometer datos privados o confidenciales.</p></li></ul>",
                "remediation": "<p>Configurar correctamente. Los servidores web, ya sean NGINX, Apache o IIS, deben configurarse para que no se permita ni el listado de directorios ni la navegación del usuario por las rutas.Por ejemplo, en un servidor web Apache, es necesario crear un archivo .htaccess en el directorio de la aplicación correspondiente para desactivar el listado de directorios. Las siguientes líneas pueden añadirse al archivo httpd.conf o sustituirse por las que ya existen:</p><p><Directory /{YOUR DIRECTORY}>Options FollowSymLinks</Directory></p><p>Como puede ver en el código de ejemplo anterior, para desactivar de forma segura la función de listado de directorios en un servidor web Apache, debe eliminar las sentencias Indexes y MultiViews.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/04-Enumerate_Applications_on_Webserver",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/04-Testing_for_Weak_Encryption",
                    "https://cwe.mitre.org/data/definitions/311.html",
                    "https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html",
                    "https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html",
                    "https://wiki.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)"
                ],
                "locale": "es",
                "title": "Ausencia de cifrado SSL/TLS",
                "vulnType": "OWASP WSTG",
                "description": "<p>En lugar del protocolo HTTPs, se utiliza HTTP para comunicarse con el servidor web. Para impedir que un atacante lea o altere los datos enviados entre el cliente y el servidor, éstos deben estar cifrados y protegidos. El método más común para hacerlo es a través de HTTPS, que sustituye el protocolo Transport Layer Security (TLS) por el protocolo Secure Socket Layer (SSL). Al mostrar un certificado digital de confianza, el servidor puede utilizar TLS para mostrar al cliente que está conectado al servidor correcto.</p><p>A lo largo de los años, se ha identificado un gran número de debilidades criptográficas en los protocolos SSL y TLS, así como en los cifrados que utilizan. Además, muchas de las implementaciones de estos protocolos también han presentado graves vulnerabilidades. Por lo tanto, es importante comprobar que los sitios no sólo implementan TLS, sino que lo hacen de forma segura.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: Un atacante puede ser capaz de descifrar los datos utilizando ataques de fuerza bruta.</p></li></ul>",
                "remediation": "<p>El servidor web debe estar configurado para soportar HTTPs. Además, es práctico utilizar el encabezado HSTS y cambiar todas las peticiones HTTP al protocolo HTTPs.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/03-Testing_for_Sensitive_Information_Sent_via_Unencrypted_Channels",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/319.html",
                    "https://capec.mitre.org/data/definitions/117.html"
                ],
                "locale": "es",
                "title": "Contenido mixto",
                "vulnType": "OWASP WSTG",
                "description": "<p>Los contenidos cargados mediante el protocolo HTTP son utilizados por la aplicación web, que utiliza el protocolo HTTPs. Dado que cualquier dato cargado a través de HTTP puede ser interceptado y alterado por un atacante, esta práctica se considera insuficiente.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>El servidor web debe estar configurado para soportar HTTPs. Además, es práctico utilizar el encabezado HSTS y cambiar todas las peticiones HTTP al protocolo HTTPs.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/04-Testing_for_Weak_Encryption",
                    "https://cwe.mitre.org/data/definitions/310.html",
                    "https://cwe.mitre.org/data/definitions/327.html"
                ],
                "locale": "es",
                "title": "Algoritmos de cifrado débiles",
                "vulnType": "OWASP WSTG",
                "description": "<p>Numerosos fallos en la configuración del servidor web del servicio SSL/TLS podrían conducir a una comunicación insegura entre el cliente y el servidor.</p><p>Se considera que los algoritmos de cifrado utilizados por el servicio SSL/TLS que se ejecuta en el servidor son débiles o presentan vulnerabilidades conocidas.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li><li><p>Control de acceso: Modificación de datos de aplicación: Un atacante puede engañar a un usuario para que realice acciones enmascaradas y ocultas a la vista del usuario. El impacto varía ampliamente, dependiendo de la funcionalidad de la aplicación subyacente. Por ejemplo, en una aplicación de redes sociales, el clickjacking podría utilizarse para engañar al usuario para que cambie la configuración de privacidad.</p></li></ul>",
                "remediation": "<p>Permitir sólo conexiones TLS con cifrado considerado seguro en las versiones 1.2 o 1.3.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security",
                    "https://cwe.mitre.org/data/definitions/326.html"
                ],
                "locale": "es",
                "title": "Uso de versiones obsoletas del protocolo SSL/TLS",
                "vulnType": "OWASP WSTG",
                "description": "<p>Para impedir que un atacante lea o altere los datos enviados entre el cliente y el servidor, es necesario cifrarlos y protegerlos. El método más popular para hacerlo es HTTPS, que sustituye el anticuado protocolo SSL (Secure Socket Layer) por el TLS (Transport Layer Security). Mostrando un certificado digital de confianza, el servidor puede utilizar TLS para mostrar al cliente que está conectado al servidor correcto.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>En el servidor web, las variantes inseguras del protocolo SSL/TLS deben estar desactivadas.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security"
                ],
                "locale": "es",
                "title": "Renegociación segura iniciada por el cliente",
                "vulnType": "OWASP WSTG",
                "description": "<p>En el lado del servidor, en comparación con el lado del cliente, se utilizan más recursos durante la negociación de la conexión SSL/TLS. En caso de que el servidor permita al cliente solicitar una renegociación de la conexión, un atacante podría aprovechar esta característica para enviar numerosas solicitudes de negociación, consumiendo recursos del servidor y posiblemente provocando una denegación de servicio (DoS).</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Para solucionar la vulnerabilidad, se aconseja aplicar el parche más reciente. Es esencial actualizar a la versión 0.9.8l o posterior en los sistemas que ejecuten OpenSSL. Por otro lado, también es posible deshabilitar el inicio de la renegociación por parte del cliente como mitigación sin necesidad de actualización.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/04-Testing_for_Weak_Encryption",
                    "https://cwe.mitre.org/data/definitions/16.html"
                ],
                "locale": "es",
                "title": "Certificado digital no fiable",
                "vulnType": "OWASP WSTG",
                "description": "<p>El certificado digital del servidor es inseguro y poco fiable debido a algunos parámetros incorrectos, lo que aumenta el riesgo de confidencialidad o fiabilidad para el sistema.</p>",
                "observation": "<ul><li><p>Otro: Impacto técnico: Varía según el contexto</p></li></ul>",
                "remediation": "<p>Se aconseja crear un certificado digital que los navegadores reconozcan como fiable (emitido por una autoridad reconocida, dentro del periodo de validez y con el nombre común del certificado igual al nombre del sitio Web que ofrece los servicios).</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/299.html"
                ],
                "locale": "es",
                "title": "Comprobación incorrecta de revocación de certificados (grapado OCSP)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Para detener los ataques man-in-the-middle a los usuarios de sus aplicaciones, siempre debe poder recuperar rápidamente estos certificados cuando su autoridad de certificación pierda la confianza.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: La confianza puede asignarse a una entidad que no es quien dice ser.</p></li><li><p>Otro: Otros: Pueden integrarse datos procedentes de una fuente no fiable (y posiblemente maliciosa).</p></li><li><p>Confidencialidad: Lectura de datos de aplicación: Los datos pueden ser revelados a una entidad que se haga pasar por una entidad de confianza, lo que da lugar a la divulgación de información.</p></li></ul>",
                "remediation": "<p>El archivo keyset del ordenador seguro de firma, que es también donde se almacenan las copias firmadas y sin firmar de la zona, contiene el ancla de confianza para la zona en cuestión. El procedimiento de firma incluye la creación automática de este archivo.</p><p>Una lista de revocación de certificados (CRL) es una lista, creada y firmada por una autoridad de certificación (CA), que contiene números de serie de certificados que han sido emitidos por esa CA y que están actualmente revocados. Además del número de serie de los certificados revocados, la CRL también contiene el motivo de la revocación de cada certificado y el momento en que se revocó el certificado. El número de serie de cada certificado revocado se guarda en la base de datos de la CA y se publica en la CRL hasta que el certificado caduca.</p><p>La entrada CRL para el certificado revocado se elimina una vez que ha caducado, y la CA es entonces libre de eliminar el certificado de su base de datos. El certificado revocado suele permanecer en la CRL durante un periodo de publicación tras la expiración del certificado. Siempre debe tener acceso a este conocimiento para poder actuar con rapidez.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/299.html"
                ],
                "locale": "es",
                "title": "Certificados CA",
                "vulnType": "OWASP WSTG",
                "description": "<p>Una organización que emite certificados digitales se conoce como autoridad de certificación (CA) en el campo de la criptografía. Un certificado digital da fe de que el sujeto del certificado es propietario de una clave pública. Una CA puede fallar ocasionalmente y ser eliminada del navegador. Si su aplicación utiliza un certificado emitido por esta CA, se producirán conexiones TLS no fiables.</p><p>Un certificado de identidad que está firmado por la misma entidad cuya identidad certifica se conoce como certificado autofirmado. Esta frase no tiene nada que ver con quién o qué ha sido el responsable de llevar a cabo el proceso de firma. Un certificado autofirmado es aquel que ha sido firmado utilizando una clave privada que pertenece al emisor.</p><p>En los acuerdos típicos de infraestructura de clave pública (PKI), una firma digital de una autoridad de certificación (CA) da fe de que un certificado de clave pública concreto es válido. Cada CA tiene una o varias claves raíz, y los certificados asociados a esas claves públicas son \"\"anclas de confianza\"\" que utilizan un tipo especial de certificados autofirmados. El establecimiento de la confianza en el certificado raíz de la CA depende de procedimientos que van más allá de la comprobación de su firma digital.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: La confianza puede asignarse a una entidad que no es quien dice ser.</p></li><li><p>Otro: Otros: Pueden integrarse datos procedentes de una fuente no fiable (y posiblemente maliciosa).</p></li><li><p>Confidencialidad: Lectura de datos de aplicación: Los datos pueden ser revelados a una entidad que se haga pasar por una entidad de confianza, lo que da lugar a la divulgación de información.</p></li></ul>",
                "remediation": "<p>Instale un certificado de confianza de una CA raíz de confianza en el servidor.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/306.html"
                ],
                "locale": "es",
                "title": "Garantizar la seguridad general",
                "vulnType": "OWASP WSTG",
                "description": "<p>Debido al hecho de que recibe mucha atención durante el desarrollo, el mecanismo de autenticación principal es frecuentemente una buena funcionalidad reforzada. Sin embargo, este no suele ser el caso de los mecanismos de autenticación secundarios, como las funciones de olvido de contraseña u otras rutas alternativas que podrían dar lugar a una autenticación satisfactoria de la aplicación.</p>",
                "observation": "<ul><li><p>Otro: Otros: Exponer una funcionalidad crítica proporciona esencialmente a un atacante el nivel de privilegio de esa funcionalidad. Las consecuencias dependerán de la funcionalidad asociada, pero pueden ir desde la lectura o modificación de datos sensibles, el acceso a funcionalidades administrativas u otras privilegiadas, o posiblemente incluso la ejecución de código arbitrario.</p></li></ul>",
                "remediation": "<p>Asegúrese de que todas las funciones de autenticación de la identidad de la cuenta (como actualizar el perfil, contraseña olvidada, token desactivado/perdido, servicio de asistencia o IVR) que podrían permitirle recuperar el acceso a su cuenta son al menos tan seguras contra la piratería informática como el método de autenticación principal.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/01-Test_Network_Infrastructure_Configuration",
                    "https://cwe.mitre.org/data/definitions/477.html"
                ],
                "locale": "es",
                "title": "Versión del sistema operativo obsoleta (vulnerabilidades asociadas conocidas)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Cuando se puede determinar la versión del sistema operativo del servidor que ejecuta la aplicación, se produce este problema.</p><p>Cualquier tipo de información relativa a la tecnología que sustenta la aplicación web debe mantenerse siempre en secreto para dificultar o directamente impedir que, una vez conocida esta información, se puedan planificar ataques dirigidos contra este software.</p>",
                "observation": "<ul><li><p>Otro: Degradación de calidad: El atacante está utilizando una función que no se actualiza</p></li></ul>",
                "remediation": "<p>Se aconseja actualizar el sistema operativo a la versión más reciente.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/01-Test_Network_Infrastructure_Configuration",
                    "https://cwe.mitre.org/data/definitions/477.html"
                ],
                "locale": "es",
                "title": "Dependencias y bibliotecas obsoletas",
                "vulnType": "OWASP WSTG",
                "description": "<p>Los investigadores de seguridad notifican y almacenan en la lista CVE las vulnerabilidades que encuentran en bibliotecas, módulos, marcos de trabajo, plataformas o sistemas operativos. Dado que la lista está disponible para todo el mundo, proporciona acceso a cualquier atacante que pretenda comprometer una aplicación web obsoleta.</p>",
                "observation": "<ul><li><p>Otro: Mantenibilidad reducida: El atacante podría encontrar vulnerabilidades de componentes obsoletos y utilizarlas para explotar nuevos vectores de ataque.</p></li></ul>",
                "remediation": "<p>El principal consejo es utilizar siempre las dependencias y bibliotecas más recientes que ofrezca el fabricante. Además, se recomienda encarecidamente utilizar herramientas como OWASP dependency check al ejecutar las bibliotecas y módulos de la aplicación a través del SDLC. Este programa analiza las bibliotecas y módulos importados en busca de CVE conocidas.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces",
                    "https://cwe.mitre.org/data/definitions/16.html"
                ],
                "locale": "es",
                "title": "Identificación de los paneles de gestión",
                "vulnType": "OWASP WSTG",
                "description": "<p>No es aconsejable que los paneles de administración o de autenticación de las distintas aplicaciones sean de acceso público en Internet. Por lo tanto, sería conveniente restringir el acceso a los paneles de administración o autenticación a conexiones VPN (Red Privada Virtual) siempre que sea posible.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Se aconseja utilizar VPN para conectarse a los recursos de la organización en lugar de abrir paneles de administración o autenticación a Internet.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces",
                    "https://cwe.mitre.org/data/definitions/16.html"
                ],
                "locale": "es",
                "title": "Configuración del servidor no reforzada",
                "vulnType": "OWASP WSTG",
                "description": "<p>Cualquier parte de la pila de aplicaciones, incluidos los servicios de red, la plataforma, el servidor web, el servidor de aplicaciones, la base de datos, los frameworks, el código personalizado, las máquinas virtuales preinstaladas, los contenedores o el almacenamiento, es susceptible de sufrir errores de configuración de seguridad.</p><p>Los atacantes suelen obtener acceso no autorizado a determinados datos o funcionalidades del sistema gracias a estos fallos. En ocasiones, estos fallos pueden comprometer todo el sistema. Los requisitos de protección de las aplicaciones y los datos determinan el impacto empresarial.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Aplicar procedimientos de instalación seguros, como:</p><ul><li><p>Un proceso de hardening repetible que haga que sea rápido y fácil desplegar otro entorno que esté debidamente bloqueado. Los entornos de desarrollo, control de calidad y producción deben configurarse de forma idéntica, utilizando credenciales diferentes en cada entorno. Este proceso debe automatizarse para minimizar el esfuerzo necesario para configurar un nuevo entorno seguro.</p></li><li><p>Una plataforma mínima sin características, componentes, documentación y muestras innecesarias. Eliminar o no instalar características y frameworks no utilizados.</p></li><li><p>Una tarea para revisar y actualizar las configuraciones adecuadas a todas las notas de seguridad, actualizaciones y parches como parte del proceso de gestión de parches. En particular, revisar los permisos de almacenamiento en la nube.</p></li><li><p>Una arquitectura de aplicaciones segmentada que proporcione una separación eficaz y segura entre componentes o inquilinos, con segmentación, contenedorización o grupos de seguridad en la nube (ACL).</p></li><li><p>Envío de directivas de seguridad a los clientes, por ejemplo, encabezados de seguridad.</p></li><li><p>Un proceso automatizado para verificar la eficacia de las configuraciones y ajustes en todos los entornos.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/02-Test_Application_Platform_Configuration",
                    "https://cwe.mitre.org/data/definitions/532.html"
                ],
                "locale": "es",
                "title": "Información sensible en registros accesibles",
                "vulnType": "OWASP WSTG",
                "description": "<p>Un log es un registro de las actividades que tienen lugar en las redes y sistemas de una organización. Los registros se componen de entradas de registro, y cada entrada de un registro contiene detalles sobre un evento específico que ha tenido lugar en un sistema o red.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Se recomienda mantener los registros en una ubicación separada y no en el propio servidor web. Esto también facilita la agregación de registros de diferentes fuentes que hacen referencia a la misma aplicación (como los de una granja de servidores web) y también facilita el análisis de registros (que puede requerir mucha CPU) sin afectar al propio servidor.</p><p>También se recomienda implementar una rotación de logs asegurando que:</p><ul><li><p>Los logs se mantengan durante el tiempo definido en la política de seguridad, ni más ni menos.</p></li><li><p>Los logs se compriman una vez rotados (esto es una conveniencia, ya que significará que se almacenarán más logs para el mismo espacio disponible en disco).</p></li><li><p>Los permisos del sistema de archivos de los archivos de registro rotados son los mismos (o más estrictos) que los de los propios archivos de registro. Por ejemplo, los servidores web necesitarán escribir en los registros que utilizan, pero en realidad no necesitan escribir en los registros rotados, lo que significa que los permisos de los archivos pueden cambiarse en el momento de la rotación para evitar que el proceso del servidor web los modifique.</p></li><li><p>Algunos servidores pueden rotar los registros cuando alcanzan un determinado tamaño. Si esto ocurre, asegúrese de que un atacante no pueda forzar la rotación de los registros para ocultar su rastro.</p></li></ul><p>Por último, implante un control de acceso para que la información del registro de eventos nunca sea visible para los usuarios finales y analice los registros periódicamente, por ejemplo, en función de los mensajes de error:</p><ul><li><p>Mensajes de error 40x (no encontrado). Un gran número de ellos procedentes de la misma fuente podría indicar que se está utilizando una herramienta de exploración CGI contra el servidor web.</p></li><li><p>Mensajes 50x (error del servidor). Estos pueden ser una indicación de que un atacante está abusando de partes de la aplicación que fallan inesperadamente. Por ejemplo, las primeras etapas de un ataque de inyección SQL producirán estos mensajes de error cuando la consulta SQL no esté bien construida y su ejecución falle en la base de datos de back-end.</p></li></ul><p>Las estadísticas o los análisis de registros no deben generarse, ni almacenarse, en el mismo servidor que produce los registros. De lo contrario, un atacante podría, a través de una vulnerabilidad del servidor web o de una configuración inadecuada, acceder a ellos y recuperar información similar a la que revelarían los propios archivos de registro.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information",
                    "https://cwe.mitre.org/data/definitions/200.html",
                    "https://cwe.mitre.org/data/definitions/530.html"
                ],
                "locale": "es",
                "title": "Identificación de archivos de copia de seguridad",
                "vulnType": "OWASP WSTG",
                "description": "<p>Los archivos que no están relacionados con la aplicación pero que se crean como resultado de la edición de archivos de la aplicación, después de hacer copias de seguridad mientras se están utilizando, o por dejar archivos obsoletos o sin referencia en el árbol web son una fuente importante de vulnerabilidad. La edición sobre la marcha y otras tareas administrativas en servidores web de producción pueden dejar involuntariamente copias de seguridad que fueron creadas automáticamente por el editor mientras se editaban o por el administrador mientras comprimía un grupo de archivos para crear una copia de seguridad.</p><p>La edición de archivos puede dejar copias de seguridad automáticas de tipo .bak, .sav, .old o ~. El servidor web no tiene por defecto definida una interpretación para este tipo de ficheros, por lo que el resultado suele ser o bien mostrar su contenido o bien proceder a su descarga.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Para eliminar el riesgo, es necesario eliminar el archivo de copia de seguridad descubierto. Es necesario buscar de forma rutinaria en el servidor archivos con las extensiones.bak,.bac,.sav,.old,.BAK,.BAC,.SAV,.OLD,.tar,.gz, y.tgz y eliminarlos del servidor para solucionar este tipo de defecto de forma general.Para evitar que el navegador descargue el archivo o muestre su contenido, también se aconseja configurar el servidor web para que sea capaz de entender estas extensiones.Si la raíz del documento se encuentra en un sistema de archivos que hace uso de esta tecnología, las instantáneas del sistema de archivos no deberían ser accesibles a través de la web. Configure su servidor web para denegar el acceso a tales directorios, por ejemplo, en Apache debería utilizarse una directiva de ubicación como ésta:</p><p><Location ~ \".snapshot\">Order deny,allowDeny from all</Location></p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods",
                    "https://cwe.mitre.org/data/definitions/16.html"
                ],
                "locale": "es",
                "title": "Métodos HTTP inseguros habilitados",
                "vulnType": "OWASP WSTG",
                "description": "<p>HTTP dispone de diversas técnicas para realizar operaciones en el servidor web (la norma HTTP 1.1 se refiere a ellas como métodos, pero también se suelen describir como verbos). Aunque GET y POST son, con diferencia, las formas más populares de acceder a los datos de un servidor web, HTTP también admite una serie de formas adicionales menos conocidas. Si el servidor web está configurado de forma incorrecta, algunas de ellas podrían utilizarse de forma maliciosa.</p>",
                "observation": "<ul><li><p>Otro: Impacto técnico: Varía según el contexto</p></li></ul>",
                "remediation": "<p>Los métodos que se hayan determinado como superfluos en la configuración del servidor deben desactivarse.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "es",
                "title": "Ausencia de cabeceras HTTP de seguridad",
                "vulnType": "OWASP WSTG",
                "description": "<p>Las cabeceras de seguridad se implementan como cabeceras de respuesta HTTP que limitan el potencial de explotación de vulnerabilidades del lado del cliente al indicar al navegador cómo comportarse en circunstancias específicas. La configuración de seguridad completa necesaria para establecer una conexión segura con el cliente no está presente en las respuestas del servidor.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li></ul>",
                "remediation": "<p>Se recomienda la implementación de todas las cabeceras HTTP de seguridad en las respuestas del servidor. Los valores recomendados son:</p><ul><li><p>Strict-Transport-Security (HSTS): max-age=31536000; includeSubDomains.</p></li><li><p>Content-Security-Policy: default-src https: 'self'.</p></li><li><p>X-XSS-Protección:1</p></li><li><p>X-Frame-Options: 'DENY' (si no es posible, 'SAMEORIGIN').</p></li><li><p>X-Content-Type-Options: nosniff.</p></li><li><p>Cache-Control: no-store.</p></li><li><p>Referrer-Policy: \"no-referrer\" (o \"same-origin\").</p></li><li><p>Política de permisos: Define las funciones mínimas permitidas y deniega las demás.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "es",
                "title": "Ausencia de cabecera HSTS (HTTP Strict Transport Security)",
                "vulnType": "OWASP WSTG",
                "description": "<p>El encabezado HTTP de \"seguridad de transporte estricta\" (HSTS) se utiliza para frustrar los intentos de interceptar comunicaciones, cookies, etc. Este mecanismo permite a un servidor web declarar que sólo se permiten conexiones HTTP seguras - HTTP sobre TLS/SSL - para la comunicación con el navegador.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Un atacante podría obtener acceso no autorizado al sistema recuperando las credenciales de autenticación de un usuario legítimo.</p></li></ul>",
                "remediation": "<p>Define la cabecera HTTP Strict-Transport-Security, que indica al navegador cliente que redirija automáticamente las solicitudes recibidas a través del protocolo HTTP al protocolo seguro HTTPS en lugar de utilizar o forzar un protocolo inseguro.</p><p><Strict-Transport-Security: max-age=60000; includeSubDomains></p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "es",
                "title": "Ausencia de la cabecera X-Frame-Options",
                "vulnType": "OWASP WSTG",
                "description": "<p>Se engaña a un usuario para que utilice una funcionalidad de un sitio web oculto haciendo clic en algún otro contenido de un sitio web falso mediante la vulnerabilidad Clickjacking. El método se basa en incrustar un botón o enlace oculto, por ejemplo, dentro de un iframe, en una página web visible y procesable (o páginas). El contenido de la página web señuelo previsto por el usuario se superpone al iframe.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Un atacante podría obtener privilegios modificando o leyendo datos críticos directamente, o accediendo a funcionalidades privilegiadas insuficientemente protegidas.</p></li></ul>",
                "remediation": "<p>El encabezado X-Frame-Options es compatible con la mayoría de los navegadores web actuales. Se recomienda configurar el servidor web de modo que esta cabecera esté habilitada para todas las páginas web. La opción SAMEORIGIN debe utilizarse si se prevé que la página contenga únicamente código del servidor.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "es",
                "title": "Ausencia de la cabecera de Content Security Policy (CSP)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Una cabecera de respuesta HTTP que aumenta la seguridad se llama Content-Security-Policy. Con la ayuda de esta cabecera, puedes limitar los recursos que el navegador puede cargar, incluyendo JavaScript, CSS y más.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Un atacante podría obtener privilegios modificando o leyendo datos críticos directamente, o accediendo a funcionalidades privilegiadas insuficientemente protegidas.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li><li><p>Confidencialidad: Lectura de datos de aplicación: Los datos pueden ser revelados a una entidad que se haga pasar por una entidad de confianza, lo que da lugar a la divulgación de información.</p></li><li><p>Control de acceso: Modificación de datos de aplicación: Un atacante puede engañar a un usuario para que realice acciones enmascaradas y ocultas a la vista del usuario. El impacto varía ampliamente, dependiendo de la funcionalidad de la aplicación subyacente. Por ejemplo, en una aplicación de redes sociales, el clickjacking podría utilizarse para engañar al usuario para que cambie la configuración de privacidad.</p></li></ul>",
                "remediation": "<p>Incluyendo la cabecera Content-Security-Policy en las cabeceras de respuesta HTTP, que indica al navegador que aplique las políticas deseadas, puede activar CSP en un sitio web.</p><p>Content-Security-Policy: script-src https://example.com:*;&gt;</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "es",
                "title": "Ausencia de la cabecera Cache Control",
                "vulnType": "OWASP WSTG",
                "description": "<p>Las directivas para los mecanismos de almacenamiento en caché se especifican en la cabecera HTTP Cache-Control.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li></ul>",
                "remediation": "<p>Cree una cabecera Cache-Control en su servidor web con las instrucciones necesarias. El valor del encabezado Pragma debe ser no-cache y el valor de Cache-Control debe ser no-cache, no-store si la página contiene información sensible.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "es",
                "title": "Ausencia de la cabecera Pragma",
                "vulnType": "OWASP WSTG",
                "description": "<p>La cabecera Pragma es una cabecera específica de la implementación que puede afectar a la cadena petición-respuesta de varias maneras. Cuando la cabecera HTTP/1.1 Cache-Control aún no está presente, se utiliza por compatibilidad con versiones anteriores de caché HTTP/1.0.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li></ul>",
                "remediation": "<p>La cabecera Cache-Control es la forma ideal de especificar una política de almacenamiento en caché cuando se utiliza al menos HTTP/1.1 en las respuestas del servidor. La cabecera Pragma se puede eliminar.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "es",
                "title": "Ausencia de la cabecera Feature Policy",
                "vulnType": "OWASP WSTG",
                "description": "<p>Los desarrolladores web pueden habilitar, deshabilitar y alterar de forma selectiva el comportamiento de APIs específicas y características web en el navegador utilizando la cabecera Feature-Policy. Tenga en cuenta que este encabezado se ha dividido en una Política de permisos y una Política de documentos, y que se considerará obsoleto una vez que todas las funciones afectadas se hayan eliminado de la Política de funciones.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li></ul>",
                "remediation": "<p>A continuación se muestra un ejemplo de cómo añadir la cabecera Feature-Policy a las respuestas del servidor web:</p><p><Feature-Policy: vibrate 'self'; usermedia *; sync-xhr 'self' https://example.com></p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/116.html"
                ],
                "locale": "es",
                "title": "Ausencia de la cabecera Referrer policy",
                "vulnType": "OWASP WSTG",
                "description": "<p>Las solicitudes realizadas desde un documento, y para las navegaciones fuera de ese documento se asocian con una cabecera Referer. Aunque este encabezado puede suprimirse en los enlaces con el tipo de enlace noreferrer, los autores pueden desear controlar el encabezado Referer de forma más directa por varias razones:</p><ul><li><p>Privacidad: un sitio de redes sociales tiene una página de perfil para cada uno de sus usuarios, y los usuarios añaden hipervínculos desde su página de perfil a sus grupos favoritos.Es posible que el sitio de redes sociales no desee filtrar la URL del perfil del usuario a los sitios web de las bandas cuando otros usuarios sigan esos hipervínculos (porque las URL del perfil podrían revelar la identidad del propietario del perfil).Sin embargo, algunos sitios web de redes sociales podrían querer informar a los sitios web de los grupos de que los enlaces proceden del sitio web de la red social, pero no revelar qué perfil de usuario concreto contiene los enlaces.</p></li><li><p>Seguridad: una aplicación web utiliza HTTPS y un identificador de sesión basado en URL. La aplicación web podría desear enlazar a recursos HTTPS en otros sitios web sin filtrar el identificador de sesión del usuario en la URL. Alternativamente, una aplicación web puede utilizar URLs que en sí mismas otorgan alguna capacidad. Controlar el referente puede ayudar a prevenir que estas URLs de capacidad se filtrena través de las cabeceras de referencia.</p></li></ul><p>Ten en cuenta que hay otras formas de que se filtren las URL de capacidad, y controlar el referente no es suficiente para controlar todas esas posibles filtraciones.</p><ul><li><p>Trackback: un blog alojado en HTTPS puede querer enlazar a un blog alojado en HTTP y recibir enlaces de trackback.</p></li></ul>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li></ul>",
                "remediation": "<p>Política de referencia La cantidad de datos de referencia, que se transmiten a través de la cabecera Referer, que deben incluirse en las solicitudes está controlada por la cabecera HTTP. La cabecera Referer tiene muchas buenas intenciones, pero también tiene efectos desfavorables en la seguridad y privacidad del usuario. Los siguientes valores deben ser configurados en la política:</p><p>Referrer-Policy: no-referrerReferrer-Policy: same-origin</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/116.html"
                ],
                "locale": "es",
                "title": "Ausencia de la cabecera X-Content-Type-Options",
                "vulnType": "OWASP WSTG",
                "description": "<p>Para protegerse contra la descarga reflexiva de archivos y otros tipos de inyecciones, algunas devoluciones de llamada de API deben tener cabeceras de seguridad configuradas correctamente.</p><p>Además, confirme si la entrada del usuario se refleja en la respuesta de la API y si es dinámica. Si es así, para detener ataques XSS y de ejecución del método del mismo origen, debe validar y codificar la entrada.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li></ul>",
                "remediation": "<p>Sanitize la entrada de su API; escapar es insuficiente en este caso; sólo deben permitir alfanumérico. Asegúrese de que X-Content-Type-Options está presente en todas las respuestas de la API. para evitar que el navegador interprete los archivos como algo distinto a lo que el tipo de contenido ha declarado, utilice nosniff (esto ayuda a evitar XSS si la página se interpreta como html o js).</p><p>Añada</p><p>Content-Disposition: attachment; filename=\"nombrearchivo.extension\"</p><p>con la extensión correspondiente a la extensión del archivo y el tipo de contenido, en las API que no se van a renderizar</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/524.html"
                ],
                "locale": "es",
                "title": "Cabecera Anti-Caching (del lado del servidor)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Las cabeceras anti-caching evitan que los datos sensibles se almacenen en proxies inversos, balanceadores de carga y módulos de caché de aplicaciones. Si no se implementan correctamente estas cabeceras, la información sensible puede almacenarse en la caché de estos módulos y quedar expuesta.Veamos dos ejemplos de cabeceras mal configuradas:Cache-Control: max-age=315360000, public: la respuesta puede ser almacenada por cualquier cachéCache-Control: private: la respuesta puede ser almacenada por la caché de un navegador</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Esta vulnerabilidad se reducirá si se implementan correctamente las cabeceras anti-caching. Una cabecera anti-caching usada apropiadamente se parecerá a:</p><p>Cache-Control: no-storePragma: no-cache (sólo para compatibilidad con clientes HTTP/1.0)</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/173.html"
                ],
                "locale": "es",
                "title": "Cabecera Content-Type insegura dentro de la respuesta",
                "vulnType": "OWASP WSTG",
                "description": "<p>Establecer las cabeceras de contenido adecuadas es crucial para reforzar la seguridad de sus aplicaciones, ya que reduce su exposición a ataques de descargas no autorizadas y a sitios web que alojan contenido cargado por el usuario que, debido a una nomenclatura inteligente, MS Internet Explorer puede confundir con archivos HTML ejecutables o dinámicos, creando fallos de seguridad.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li></ul>",
                "remediation": "<p>Un ejemplo de cabecera Content-type segura sería:</p><p>Content-Type: text/html; charset=UTF8Content-Type: application/json;</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/09-Test_File_Permission",
                    "https://cwe.mitre.org/data/definitions/732.html"
                ],
                "locale": "es",
                "title": "Permisos excesivos de archivos y directorios",
                "vulnType": "OWASP WSTG",
                "description": "<p>Si se da a un recurso una configuración de permisos que permita el acceso a un grupo de usuarios mayor del necesario, se corre el riesgo de exponer datos sensibles o permitir que personas no autorizadas modifiquen el recurso. Esto es especialmente arriesgado cuando el recurso está relacionado con la configuración o ejecución de un programa o con datos confidenciales del usuario.</p><p>Un ejemplo claro es un archivo de ejecución que puede ser ejecutado por usuarios no autorizados. Otro ejemplo es que la información de una cuenta o el valor de un token para acceder a una API (cada vez más común en los servicios web o microservicios actuales) pueda almacenarse en un archivo de configuración cuyos permisos estén configurados por defecto para ser legibles por todo el mundo desde la instalación. Estos datos sensibles pueden ser expuestos por usuarios internos malintencionados o por un atacante remoto que haya comprometido el servicio con otras vulnerabilidades, pero que tenga privilegios bajos.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El código inyectado podría acceder a datos / archivos restringidos.</p></li><li><p>Confidencialidad: Lectura de ficheros o directorios: Un atacante podría leer datos sensibles, ya sea leyendo los datos directamente desde un almacén de datos que no esté debidamente restringido, o accediendo a una funcionalidad privilegiada insuficientemente protegida para leer los datos.</p></li></ul>",
                "remediation": "<p>Configurar correctamente los permisos de archivos y directorios ayudará a solucionar esta vulnerabilidad al impedir que usuarios no autorizados accedan innecesariamente a recursos vitales.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/770.html"
                ],
                "locale": "es",
                "title": "Asignación de recursos sin límites ni estrangulamiento",
                "vulnType": "OWASP WSTG",
                "description": "<p>En contravención de la política de seguridad prevista para ese actor, el software asigna un recurso reutilizable o un conjunto de recursos en nombre del actor sin imponer ninguna limitación sobre el tamaño o la cantidad de recursos que pueden asignarse.</p>",
                "observation": "<ul><li><p>Disponibilidad: DoS: Consumo de recursos (Otros): Al asignar recursos sin límites, un atacante podría impedir que otros sistemas, aplicaciones o procesos accedieran al mismo tipo de recurso.</p></li></ul>",
                "remediation": "<p>Requisitos</p><ul><li><p>Especificar claramente las expectativas mínimas y máximas de las capacidades, y dictar qué comportamientos son aceptables cuando la asignación de recursos alcanza los límites.</p></li></ul><p>Arquitectura y diseño- Limitar la cantidad de recursos accesibles a los usuarios sin privilegios. Establezca límites por usuario para los recursos. Permita que el administrador del sistema defina estos límites. Tenga cuidado de evitar 410.- Diseñar mecanismos de estrangulamiento en la arquitectura del sistema. La mejor protección es limitar la cantidad de recursos que un usuario no autorizado puede hacer gastar. Un modelo fuerte de autenticación y control de acceso ayudará a prevenir que tales ataques ocurran en primer lugar, y ayudará al administrador a identificar quién está cometiendo el abuso. La aplicación de inicio de sesión debe estar protegida contra ataques DoS tanto como sea posible. Limitar el acceso a la base de datos, quizás almacenando en caché los conjuntos de resultados, puede ayudar a minimizar los recursos gastados. Para limitar aún más el potencial de un ataque DoS, considere el seguimiento de la tasa de solicitudes recibidas de los usuarios y el bloqueo de las solicitudes que superen un umbral de tasa definido.- Asegúrese de que los protocolos tienen límites de escala específicos.- Para cualquier comprobación de seguridad que se realice en el lado del cliente, asegúrese de que estas comprobaciones se duplican en el lado del servidor, para evitar 602: Client-Side Enforcement of Server-Side Security. Los atacantes pueden eludir las comprobaciones del lado del cliente modificando los valores después de que se hayan realizado las comprobaciones, o cambiando el cliente para eliminar por completo las comprobaciones del lado del cliente. Entonces, estos valores modificados se enviarían al servidor.</p><p>Implementación- Asumir que todas las entradas son maliciosas. Utilizar una estrategia de validación de entrada de \"aceptar lo bueno conocido\", es decir, utilizar una lista de entradas aceptables que se ajusten estrictamente a las especificaciones. Rechazar cualquier entrada que no se ajuste estrictamente a las especificaciones, o transformarla en algo que sí lo haga.- A la hora de validar las entradas, hay que tener en cuenta todas las propiedades potencialmente relevantes, como la longitud, el tipo de entrada, la gama completa de valores aceptables, las entradas que faltan o sobran, la sintaxis, la coherencia entre campos relacionados y la conformidad con las reglas de negocio. Como ejemplo de lógica de reglas de negocio, \"barco\" puede ser sintácticamente válido porque sólo contiene caracteres alfanuméricos, pero no es válido si sólo se espera que la entrada contenga colores como \"rojo\" o \"azul\".- No confíe exclusivamente en la búsqueda de entradas maliciosas o malformadas. Es probable que se pase por alto al menos una entrada no deseada, sobre todo si cambia el entorno del código. Esto puede dar a los atacantes suficiente margen para eludir la validación prevista. Sin embargo, las listas negras pueden ser útiles para detectar posibles ataques o determinar qué entradas están tan malformadas que deberían rechazarse directamente.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Identity Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account",
                    "https://cwe.mitre.org/data/definitions/203.html",
                    "https://cwe.mitre.org/data/definitions/204.html",
                    "https://cwe.mitre.org/data/definitions/200.html"
                ],
                "locale": "es",
                "title": "Enumeración de cuentas (usuarios)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Debido a errores de configuración o a elecciones de diseño intencionadas, las aplicaciones web suelen dejar claro si un nombre de usuario ya existe en el sistema. Por ejemplo, cuando se envían credenciales incorrectas, el mensaje resultante a veces puede indicar si el nombre de usuario ya existe en el sistema o si la contraseña se ha introducido incorrectamente. Un atacante puede utilizar la información recopilada para elaborar una lista de usuarios del sistema. Empleando un ataque de fuerza bruta o un ataque de nombre de usuario y contraseña por defecto, por ejemplo, esta información puede utilizarse para atacar la aplicación web.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li></ul>",
                "remediation": "<p>Existen varias recomendaciones para evitar este tipo de vulnerabilidades. La mejor solución es aplicar algunas de ellas o todas, según proceda:</p><ul><li><p>Evitar utilizar cualquier dato público (alias, email, etc.) como nombre de usuario para autenticarse en la aplicación. Estos datos deben ser privados y sólo conocidos por el usuario.</p></li><li><p>Durante la fase de desarrollo, optimiza el proceso de autenticación del usuario para evitar tiempos de respuesta \"elevados\" durante la autenticación.</p></li><li><p>No utilizar mensajes informativos que ayuden a adivinar la existencia de nombres de usuario.</p></li><li><p>Evitar comportamientos diferentes en la aplicación web en función de la existencia de nombres de usuario.</p></li><li><p>Delegue la generación de nombres de usuario a la aplicación web. El generador utilizado debe ser completamente aleatorio y nunca secuencial ya que sería predecible.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Identity Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/02-Test_User_Registration_Process",
                    "https://cwe.mitre.org/data/definitions/287.html"
                ],
                "locale": "es",
                "title": "Proceso de registro de usuarios inseguro",
                "vulnType": "OWASP WSTG",
                "description": "<p>La provisión de acceso al sistema a los usuarios está automatizada (o parcialmente automatizada) por el proceso de registro de usuarios de algunas aplicaciones web. Dependiendo de los requisitos de seguridad del sistema, los requisitos de identidad para el acceso pueden variar desde una identificación positiva hasta ninguna. Debido al tamaño de sus bases de usuarios, muchas aplicaciones públicas automatizan completamente los procesos de registro y aprovisionamiento. Un hacker podría utilizar esta vulnerabilidad para controlar otras cuentas de usuario, por ejemplo, si no se siguen las mejores prácticas a la hora de automatizar el proceso de registro.</p>",
                "observation": "<ul><li><p>Control de acceso: Ejecución no autorizada de código o comandos: Esta debilidad puede llevar a la exposición de recursos o funcionalidades a actores no intencionados, posiblemente proporcionando a los atacantes información sensible o incluso ejecutar código arbitrario.</p></li></ul>",
                "remediation": "<p>Se aconseja establecer requisitos de identificación y verificación acordes con los requisitos de seguridad de los datos que protegen las credenciales.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
        "category": "Identity Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/384.html"
                ],
                "locale": "es",
                "title": "La función de inicio de sesión debe generar siempre un nuevo identificador de sesión.",
                "vulnType": "OWASP WSTG",
                "description": "<p>La aplicación debe crear una nueva cookie de sesión cada vez que un usuario se autentique correctamente.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: La aplicación no invalida ningún identificador de sesión existente y da a un atacante la oportunidad de robar sesiones autenticadas.</p></li></ul>",
                "remediation": "<p>Después de un inicio de sesión exitoso, la funcionalidad de inicio de sesión siempre debe crear (y utilizar) un nuevo ID de sesión. Esto se hace para evitar que un atacante ataque a tus usuarios utilizando un ataque de fijación de sesión.Algunos frameworks, como las aplicaciones.net, no permiten cambiar el ID de sesión al iniciar sesión. Podrías añadir una cookie aleatoria extra con un token fuerte al iniciar sesión cuando surja este problema y almacenar el valor en una variable de sesión.</p><p>Ahora que la autenticación depende de algo más que el ID de sesión y la cookie aleatoria no puede ser predicha o fijada por un atacante, puedes comparar el valor de la cookie con la variable de sesión para prevenir la fijación de sesión.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Password_Policy",
                    "https://cwe.mitre.org/data/definitions/521.html"
                ],
                "locale": "es",
                "title": "Debilidades en la política de contraseñas",
                "vulnType": "OWASP WSTG",
                "description": "<p>Todos los elementos de seguridad incorporados a la infraestructura tecnológica pueden quedar expuestos por una política de contraseñas laxa. Sin utilizar ninguna otra vulnerabilidad, adivinar una contraseña permitiría acceder a sistemas legítimos. Ocurre con frecuencia en los dominios de las grandes organizaciones, donde los usuarios del administrador con mayores privilegios son completamente olvidados en favor de los usuarios normales con acceso restringido a los que se aplica una estricta política de contraseñas. En otras palabras, a diferencia de un usuario con privilegios limitados, un usuario administrador puede utilizar una contraseña considerada débil. Para facilitar la conexión a los nuevos usuarios, muchos servicios vienen con nombres de usuario y contraseñas por defecto al principio. A menudo se pasa por alto el paso crucial de cambiar esta información, dejando el sistema accesible utilizando lo que se conoce como las credenciales por defecto.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: A medida que las contraseñas envejecen, aumenta la probabilidad de que se vean comprometidas.</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Un atacante podría adivinar fácilmente las contraseñas de los usuarios y acceder a sus cuentas.</p></li></ul>",
                "remediation": "<p>Establezca una política de contraseñas segura que exija al usuario:</p><ul><li><p>Una longitud mínima de contraseña de 8 caracteresUtilizar todos los tipos de caracteres, incluidas mayúsculas y minúsculas, números y caracteres especiales.</p></li><li><p>Hacer uso de un algoritmo de cifrado eficaz como AES-128 o SHA-256</p></li><li><p>Comprobar si la contraseña en blanco está prohibida.</p></li><li><p>Evite utilizar el identificador de usuario (o cualquier subconjunto del mismo) como contraseña.</p></li><li><p>Forzar periódicamente el cambio.</p></li><li><p>Impida que los usuarios utilicen contraseñas anteriores.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/263.html"
                ],
                "locale": "es",
                "title": "Sin política de rotación de contraseñas",
                "vulnType": "OWASP WSTG",
                "description": "<p>Algunas políticas exigen que los usuarios cambien las contraseñas periódicamente, a menudo cada 90 o 180 días.</p><p>Sin embargo, el beneficio de la caducidad de las contraseñas es discutible. Los sistemas que aplican este tipo de políticas a veces impiden a los usuarios elegir una contraseña demasiado parecida a una selección anterior.</p><p>Esta política puede resultar contraproducente. A algunos usuarios les resulta difícil idear \"buenas\" contraseñas que también sean fáciles de recordar, por lo que si se exige a la gente que elija muchas contraseñas porque tienen que cambiarlas a menudo, acaban utilizando contraseñas mucho más débiles; la política también anima a los usuarios a escribir las contraseñas. Además, si la política impide que un usuario repita una contraseña reciente, esto requiere que exista una base de datos con las contraseñas recientes de todos (o sus hashes) en lugar de tener las antiguas borradas de la memoria. Por último, los usuarios pueden cambiar su contraseña repetidamente en pocos minutos, y luego volver a cambiar a la que realmente quieren usar, eludiendo por completo la política de cambio de contraseña.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: A medida que las contraseñas envejecen, aumenta la probabilidad de que se vean comprometidas.</p></li></ul>",
                "remediation": "<p>Sólo cuando la seguridad de la contraseña impuesta por la aplicación ya no sea lo suficientemente fuerte como para resistir ataques de fuerza bruta debido a un aumento de la potencia de cálculo, se podrá obligar a los usuarios a actualizar sus contraseñas.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/620.html"
                ],
                "locale": "es",
                "title": "Permitir el cambio de contraseña",
                "vulnType": "OWASP WSTG",
                "description": "<p>Los usuarios deben tener la opción de cambiar su contraseña siempre que sea necesario. Pensemos, por ejemplo, en una situación en la que utilicen con frecuencia la misma contraseña en distintas aplicaciones. Los usuarios deben actualizar inmediatamente su información de acceso en cada aplicación en la que se hayan registrado si su contraseña se ve comprometida. Por lo tanto, existe la posibilidad de que la cuenta de un usuario se vea comprometida si la aplicación no le da acceso a una función de actualización de contraseñas.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: A medida que las contraseñas envejecen, aumenta la probabilidad de que se vean comprometidas.</p></li></ul>",
                "remediation": "<p>Las aplicaciones deben ofrecer una función que permita al usuario modificar su propia contraseña.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/521.html"
                ],
                "locale": "es",
                "title": "Verificar las contraseñas violadas",
                "vulnType": "OWASP WSTG",
                "description": "<p>A lo largo de los años, las filtraciones han dado lugar a la publicación de numerosas bases de datos que contienen credenciales robadas. Los usuarios son objeto de ataques de diccionario si seleccionan contraseñas comprometidas.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Un atacante podría adivinar fácilmente las contraseñas de los usuarios y acceder a sus cuentas.</p></li></ul>",
                "remediation": "<p>Compruebe que las contraseñas introducidas durante la creación de cuentas, el inicio de sesión y los cambios de contraseña se comparan con una lista de contraseñas que han estado en peligro. La aplicación debe exigir al usuario que vuelva a introducir una contraseña que no haya sido comprometida si la contraseña que eligió ya lo ha sido.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/330.html"
                ],
                "locale": "es",
                "title": "Los secretos deben ser seguros y generados aleatoriamente",
                "vulnType": "OWASP WSTG",
                "description": "<p>Las contraseñas, los tokens API y las claves secretas deben generarse dinámicamente. Estos tokens pueden volverse predecibles y ser utilizados por atacantes para comprometer cuentas de usuario siempre que no se generen dinámicamente.</p>",
                "observation": "<ul><li><p>Otro: Otros: Cuando un mecanismo de protección se basa en valores aleatorios para restringir el acceso a un recurso sensible, como un identificador de sesión o una semilla para generar una clave criptográfica, se podría acceder al recurso protegido adivinando el identificador o la clave.</p></li><li><p>Otro: Otros: Si el software se basa en identificadores únicos e indescifrables para identificar un recurso, un atacante podría ser capaz de adivinar el identificador de un recurso que pertenece a otro usuario. El atacante podría entonces leer el recurso, o crear previamente un recurso con el mismo ID para impedir que el programa legítimo envíe correctamente el recurso al usuario previsto. Por ejemplo, un producto podría mantener la información de sesión en un archivo cuyo nombre se basa en un nombre de usuario. Un atacante podría pre-crear este archivo para un usuario víctima, y luego establecer los permisos para que la aplicación no pueda generar la sesión para la víctima, impidiendo que la víctima utilice la aplicación.</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Cuando un mecanismo de autorización o autenticación se basa en valores aleatorios para restringir el acceso a funcionalidades restringidas, como un ID de sesión o una semilla para generar una clave criptográfica, entonces un atacante puede acceder a la funcionalidad restringida adivinando el ID o la clave.</p></li></ul>",
                "remediation": "<p>Estos valores deben generarse dinámicamente y sólo deben ser válidos una vez cuando se trate de tokens API y claves secretas.El token secreto debe ser criptográficamente \"seguro al azar\", tener al menos 120 bits de entropía efectiva, estar salado con un valor especial y generado aleatoriamente de 32 bits, y hasheado utilizando una función hashing reconocida (unidireccional).</p><p>En lugar de dar a un usuario una contraseña generada dinámicamente, las contraseñas deben ser creadas por el propio usuario. Para activar su cuenta y crear una contraseña propia, el usuario debe recibir por correo electrónico o SMS un enlace de un solo uso con un token criptográficamente aleatorio.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism",
                    "https://cwe.mitre.org/data/definitions/804.html",
                    "https://cwe.mitre.org/data/definitions/645.html",
                    "https://cwe.mitre.org/data/definitions/1216.html",
                    "https://cwe.mitre.org/data/definitions/307.html"
                ],
                "locale": "es",
                "title": "Debilidades en la protección contra ataques de fuerza bruta",
                "vulnType": "OWASP WSTG",
                "description": "<p>Una amenaza común a la que se enfrentan los desarrolladores web es un ataque de adivinación de contraseñas conocido como ataque de fuerza bruta. Un ataque de fuerza bruta es un intento de descubrir una contraseña probando sistemáticamente todas las combinaciones posibles de letras, números y símbolos hasta descubrir la única combinación correcta que funciona. Si su sitio web requiere autenticación de usuario, es un buen objetivo para un ataque de fuerza bruta.</p><p>Un atacante siempre puede descubrir una contraseña mediante un ataque de fuerza bruta, pero el inconveniente es que podría tardar años en encontrarla. Dependiendo de la longitud y complejidad de la contraseña, podría haber billones de combinaciones posibles. Para acelerar un poco las cosas, un ataque de fuerza bruta podría comenzar con palabras del diccionario o palabras del diccionario ligeramente modificadas, ya que la mayoría de la gente las utilizará en lugar de una contraseña completamente aleatoria. Estos ataques se denominan ataques de diccionario o ataques híbridos de fuerza bruta. Los ataques de fuerza bruta ponen en peligro las cuentas de los usuarios e inundan su sitio con tráfico innecesario.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Cuando la autorización, autenticación u otro mecanismo de protección se basa en entidades CAPTCHA para garantizar que sólo los actores humanos pueden acceder a cierta funcionalidad, entonces un atacante automatizado como un bot puede acceder a la funcionalidad restringida adivinando el CAPTCHA.</p></li><li><p>Disponibilidad: DoS: Consumo de recursos (Otros): Los usuarios podrían ser bloqueados de sus cuentas.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Un atacante podría realizar un número arbitrario de intentos de autenticación utilizando diferentes contraseñas, y finalmente obtener acceso a la cuenta objetivo.</p></li></ul>",
                "remediation": "<p>Crear un sistema de defensa suficiente para detener los ataques. Compruebe que la combinación de números y letras en un sistema captcha es difícil de predecir, y no proporcione la respuesta en ninguna de las respuestas que se envían al navegador del usuario.</p><p>Utilice procedimientos de desbloqueo de cuentas acordes con el nivel de riesgo. Del más arriesgado al más seguro:</p><ul><li><p>Bloqueo y desbloqueo en función del tiempo.</p></li><li><p>Desbloqueo mediante autoservicio (envío de correo electrónico de desbloqueo a la dirección de correo electrónico registrada).</p></li><li><p>Desbloqueo manual del administrador.</p></li><li><p>Identificación positiva del usuario para el desbloqueo manual del administrador.</p></li><li><p>Utilización de un mecanismo de autoservicio: Como se ha mencionado anteriormente, este mecanismo de autoservicio debe ser lo suficientemente seguro para evitar que el atacante pueda desbloquear las cuentas por su cuenta.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism",
                    "https://cwe.mitre.org/data/definitions/693.html"
                ],
                "locale": "es",
                "title": "Debilidad en el mecanismo de autenticación de segundo factor (2FA).",
                "vulnType": "OWASP WSTG",
                "description": "<p>El mecanismo de autenticación de dos factores (2FA) de un modelo de seguridad de confianza cero es un componente clave. Hay que confirmar que los usuarios que intentan acceder a datos sensibles son quienes dicen ser para protegerlos. Las amenazas a la seguridad como el phishing, los ataques de fuerza bruta, la explotación de credenciales, etc., que tienen como objetivo las contraseñas y cuentas de los usuarios, pueden defenderse con éxito con 2FA.</p><p>Digamos que usted completa la autenticación primaria en una aplicación con un nombre de usuario y una contraseña. Se utiliza Internet para transmitir esa información (red primaria). Sería preferible terminar la autenticación de dos factores utilizando un canal diferente (fuera de banda). La autenticación fuera de banda incluye cosas como aprobar una notificación push enviada a través de tu red móvil.</p><p>A pesar de ser muy recomendable, este enfoque puede ser perjudicial si no se utiliza correctamente.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: La aplicación no utiliza o utiliza incorrectamente un mecanismo de protección que proporciona defensa suficiente contra ataques dirigidos contra el producto.</p></li></ul>",
                "remediation": "<p>Aunque es mejor omitir el SMS como única opción 2FA, esto no aborda la razón para añadir 2FA en primer lugar. Para evitar la fuerza bruta y otros ataques dirigidos a la autenticación de contraseñas, se necesita alguna forma de 2FA. Algunas de las alternativas a 2FA SMS:</p><ul><li><p>Autenticación por hardware. La autenticación por hardware se basa en un dispositivo físico dedicado para conceder el acceso. Además de la contraseña, los usuarios tienen que introducir un código aleatorio generado por el dispositivo. Si no se introduce el código, no se puede iniciar sesión. Entre los proveedores de autenticación por hardware figuran RSA SecurID y Thales SafeNet.</p></li><li><p>Autenticación por software. La autenticación por software sigue esencialmente el mismo principio que la autenticación por hardware. Pero en lugar de requerir un dispositivo físico, los códigos token se generan con una aplicación móvil. La aplicación de autenticación más popular es Google Authenticator, pero hay muchas opciones. Por ejemplo, RSA ofrece ahora su autenticador SecurID como aplicación.</p></li><li><p>Autenticación basada en IP. Este método comprueba la dirección IP del usuario al iniciar sesión. Puedes bloquear el acceso a direcciones IP específicas sospechosas de ser maliciosas, o simplemente permitir sólo los inicios de sesión desde direcciones IP y rangos conocidos. La autenticación basada en IP puede utilizarse junto con otros métodos para añadir otra capa de protección.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/01-Test_Network_Infrastructure_Configuration",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials",
                    "https://cwe.mitre.org/data/definitions/521.html"
                ],
                "locale": "es",
                "title": "Nombres de usuario y contraseñas por defecto",
                "vulnType": "OWASP WSTG",
                "description": "<p>La cuenta administrativa integrada tiene contraseñas por defecto en una gran cantidad de hardware y aplicaciones web. Aunque en ocasiones pueden generarse al azar, suelen ser estáticas, por lo que a un atacante le resultaría sencillo adivinarlas u obtenerlas.</p><p>Además, se pueden asignar contraseñas predefinidas a los nuevos usuarios cuando se crean en las aplicaciones. Éstas pueden ser generadas automáticamente por la aplicación o manualmente por el personal. Las contraseñas en ambas situaciones son susceptibles de ataques de adivinación si no se generan de forma segura.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Un atacante podría adivinar fácilmente las contraseñas de los usuarios y acceder a sus cuentas.</p></li></ul>",
                "remediation": "<p>El diseño de un producto debe exigir el cumplimiento de una política de contraseñas adecuada. Los requisitos específicos para las contraseñas dependen en gran medida de factores contextuales, pero se recomienda que contengan los siguientes atributos:</p><ol><li><p>Aplicación de una longitud mínima y máxima</p></li><li><p>Restricciones contra la reutilización de contraseñas.</p></li><li><p>Restricciones contra el uso de contraseñas comunes.</p></li><li><p>Restricciones contra el uso de cadenas contextuales en la contraseña (por ejemplo, ID de usuario, nombre de la aplicación).</p></li></ol><p>Dependiendo del modelo de amenazas, la política de contraseñas puede incluir varios atributos adicionales.</p><p>Contraseñas complejas que requieren conjuntos de caracteres mixtos (alfabéticos, numéricos, especiales, mayúsculas y minúsculas):</p><ul><li><p>Aumentar el rango de caracteres hace que la contraseña sea más difícil de descifrar y puede ser apropiado para sistemas que dependen de la autenticación de un solo factor.</p></li><li><p>Por desgracia, una contraseña compleja puede ser difícil de memorizar, lo que incita al usuario a seleccionar una contraseña corta o a manejar mal la contraseña (escribirla).</p></li><li><p>Otra desventaja de este enfoque es que a menudo no se traduce en un aumento significativo de la complejidad general de las contraseñas debido al uso predecible de varios símbolos por parte de la gente.</p></li></ul><p>Longitud mínima extensa:</p><ol><li><p>Aumentar el número de caracteres hace que la contraseña sea más difícil de descifrar y puede ser apropiado para sistemas que dependen de la autenticación de un solo factor.</p></li><li><p>Una desventaja de este enfoque es que la selección de una buena frase de contraseña no es fácil y aún pueden generarse contraseñas deficientes. Es posible que se necesiten algunas indicaciones para fomentar las contraseñas largas e impredecibles.</p></li></ol><p>Contraseñas generadas aleatoriamente:</p><ol><li><p>Generar una contraseña para el usuario puede ayudar a garantizar que se cumplen los requisitos de longitud y complejidad, y puede dar lugar a que se utilicen contraseñas seguras.</p></li><li><p>Una desventaja de este enfoque es que la contraseña o clave resultante puede ser demasiado difícil de memorizar, lo que anima a escribirlas.</p></li></ol><p>Caducidad de la contraseña:</p><ol><li><p>Exigir un cambio periódico de contraseña puede reducir la ventana de tiempo que tiene un atacante para descifrar una contraseña, al tiempo que limita el daño causado por la exposición de la contraseña en otro lugar.</p></li><li><p>La caducidad de la contraseña puede ser una buena técnica de mitigación cuando no se desean contraseñas largas y complejas.</p></li></ol>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Bypassing_Authentication_Schema",
                    "https://cwe.mitre.org/data/definitions/288.html"
                ],
                "locale": "es",
                "title": "Anulación de la función de inicio de sesión",
                "vulnType": "OWASP WSTG",
                "description": "<p>En seguridad informática, la autenticación es el proceso de intentar verificar la identidad digital del remitente de una comunicación. Un ejemplo común de esto es el proceso de inicio de sesión. Probar el esquema de autenticación significa comprender cómo funciona el proceso de autenticación y utilizar esa información para burlar el mecanismo de autenticación.</p><p>Aunque la mayoría de las aplicaciones requieren autenticación para acceder a información privada o ejecutar tareas, no todos los métodos de autenticación son capaces de proporcionar la seguridad adecuada. La negligencia, la ignorancia o la simple subestimación de las amenazas a la seguridad suelen dar lugar a esquemas de autenticación que pueden eludirse simplemente saltándose la página de inicio de sesión y llamando directamente a una página interna a la que se supone que sólo se puede acceder una vez realizada la autenticación.</p><p>Además, a menudo es posible eludir las medidas de autenticación manipulando las solicitudes y engañando a la aplicación para que piense que el usuario ya está autenticado. Esto puede lograrse modificando el parámetro de URL dado, manipulando el formulario o falseando las sesiones.</p><p>Los problemas relacionados con el esquema de autenticación pueden encontrarse en distintas fases del ciclo de vida de desarrollo del software (SDLC), como las fases de diseño, desarrollo e implantación:</p><ul><li><p>En la fase de diseño los errores pueden incluir una definición incorrecta de las secciones de la aplicación a proteger, elegir no aplicar protocolos de encriptación fuertes para asegurar la transmisión de credenciales, y muchos más.</p></li><li><p>En la fase de desarrollo, los errores pueden incluir una implementación incorrecta de la funcionalidad de validación de entrada o no seguir las mejores prácticas de seguridad para el lenguaje específico.</p></li><li><p>En la fase de despliegue de la aplicación, puede haber problemas durante la configuración de la aplicación (actividades de instalación y configuración) debido a la falta de los conocimientos técnicos necesarios o a la falta de una buena documentación.</p></li></ul>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: El atacante puede utilizar una ruta o canal alternativo que no requiera autenticación.</p></li></ul>",
                "remediation": "<p>Sólo los usuarios autentificados pueden ver las páginas privadas de la aplicación.</p><p>Explique detalladamente las modificaciones necesarias para solucionar la vulnerabilidad en caso de eludir la funcionalidad de autenticación.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/04-Authentication_Testing/06-Testing_for_Browser_Cache_Weaknesses",
                    "https://cwe.mitre.org/data/definitions/525.html"
                ],
                "locale": "es",
                "title": "Información confidencial almacenada en el navegador",
                "vulnType": "OWASP WSTG",
                "description": "<p>La aplicación web carece de una política de caché adecuada que establezca el nivel de caché que debe realizarse para cada página web y los campos de formulario asociados.</p><p>Los navegadores pueden almacenar información con fines de historial y caché. Para mejorar el rendimiento, el almacenamiento en caché se utiliza para que los datos descargados previamente no tengan que descargarse de nuevo. Para comodidad del usuario, se utilizan mecanismos de historial para que pueda ver exactamente lo que vio cuando recuperó el recurso. Cuando se muestran al usuario datos sensibles (como su dirección, número de tarjeta de crédito, número de la Seguridad Social o nombre de usuario), estos datos pueden almacenarse en caché o guardarse con fines de historial y, por tanto, pueden recuperarse consultando la caché del navegador o simplemente pulsando el botón de retroceso del navegador.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Utilice una política restrictiva de almacenamiento en caché para formularios y páginas web que contengan potencialmente información sensible. No almacene información sensible innecesaria en la caché. Considere el uso de cifrado en la caché. Dependiendo de si esta información se almacena en el historial o en la caché, se pueden tomar las siguientes medidas para mitigar la vulnerabilidad:</p><p>Se puede evitar que el botón atrás muestre datos sensibles. Esto se puede hacer mediante:</p><p>Enviando la página sobre HTTPS.</p><p>Estableciendo Cache-Control: must-revalidate</p><p>Para evitar que las páginas que contienen información sensible se almacenen en caché es necesario hacer una de las dos cosas siguientes:</p><p>Establecer la directiva \"Cache-Control: no-cache, no-store\" o \"Pragma: no-cache\" en las cabeceras de respuesta de dichas páginas. Ej:</p><p>HTTP/1.1:</p><p>Cache-Control: no-cache, no-store.</p><p>HTTP/1.0:</p><p>Pragma: no-cache (o Cache-Control: no-cache).</p><p>Expires: <fecha pasada o un valor ilegal (ej: 0)></p><p>Incluya en cada página HTML que contenga información sensible el siguiente código:</p><p>HTTP/1.1:</p><p><META HTTP-EQUIV=\"Cache-Control\" CONTENT=\"no-cache, no-store\"></p><p>HTTP/1.0:</p><p><META HTTP-EQUIV=\"Pragma\" CONTENT=\"no-cache\"></p><p><META HTTP-EQUIV=\"Expires\" CONTENT=\"Sat, 01-Jan-2000 00:00:00GMT\"></p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities",
                    "https://cwe.mitre.org/data/definitions/640.html"
                ],
                "locale": "es",
                "title": "Debilidades en la funcionalidad de cambio/restablecimiento de contraseñas",
                "vulnType": "OWASP WSTG",
                "description": "<p>En las aplicaciones suele haber un mecanismo que permite a un usuario acceder a su cuenta en caso de que olvide su contraseña. El mecanismo de recuperación de contraseñas suele ser poco fiable, lo que aumenta la probabilidad de que alguien que no sea el usuario legítimo del sistema pueda acceder a la cuenta de ese usuario. Un esquema de autenticación de contraseñas fuerte queda completamente destruido por procedimientos de recuperación de contraseñas débiles.</p><p>Esta debilidad puede existir debido a que la pregunta de seguridad es demasiado fácil de adivinar (por ejemplo, porque la pregunta es demasiado común o las respuestas se pueden encontrar utilizando las redes sociales). También puede existir una debilidad de implementación en el código del mecanismo de recuperación de contraseñas que pueda, por ejemplo, engañar al sistema para que envíe por correo electrónico la nueva contraseña a una cuenta de correo electrónico distinta de la cuenta de correo electrónico del usuario. La tasa de restablecimiento de contraseñas puede no estar regulada, por lo que se puede denegar el servicio a un usuario legítimo si un atacante intenta recuperar su contraseña en rápida sucesión. El sistema puede enviar la contraseña original al usuario en lugar de generar una nueva contraseña temporal. En resumen, la funcionalidad de recuperación de contraseñas, si no se diseña e implementa cuidadosamente, puede convertirse a menudo en el eslabón más débil del sistema que puede ser mal utilizado de forma que permita a un atacante obtener acceso no autorizado al sistema.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Un atacante podría obtener acceso no autorizado al sistema recuperando las credenciales de autenticación de un usuario legítimo.</p></li><li><p>Disponibilidad: DoS: Consumo de recursos: Un atacante podría denegar el servicio a usuarios legítimos del sistema lanzando un ataque de fuerza bruta contra el mecanismo de recuperación de contraseñas utilizando identificadores de usuario de usuarios legítimos.</p></li><li><p>Otro: Otros: El atacante vuelve en su contra la funcionalidad de seguridad del sistema.</p></li></ul>",
                "remediation": "<p>Asegúrese de que el mecanismo de recuperación de contraseñas ha filtrado y validado minuciosamente todos los datos que proporciona el usuario.</p><ul><li><p>Utiliza varias preguntas de seguridad en lugar de las habituales preguntas de seguridad débiles.</p></li><li><p>Asegúrate de que no haya demasiadas respuestas incorrectas a una pregunta de seguridad. Después de un cierto número (pequeño) de respuestas incorrectas, desactive la función de recuperación de contraseña.</p></li><li><p>Exige a los usuarios que respondan correctamente a la pregunta de seguridad antes de permitirles restablecer su contraseña y recibir la nueva contraseña en la dirección de correo electrónico que tengan registrada.</p></li><li><p>En el mecanismo de recuperación de contraseña, nunca deje que el usuario elija la dirección de correo electrónico a la que se enviará la nueva contraseña.</p></li><li><p>Proporcione una nueva contraseña temporal en lugar de compartir la antigua.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities",
                    "https://cwe.mitre.org/data/definitions/319.html",
                    "https://cwe.mitre.org/data/definitions/311.html"
                ],
                "locale": "es",
                "title": "Credenciales enviadas en texto claro por correo electrónico",
                "vulnType": "OWASP WSTG",
                "description": "<p>Este fallo implica que, después de que el usuario haya verificado su identidad, la funcionalidad de registro o recuperación de contraseña le envía la contraseña por correo electrónico. Hay dos razones principales por las que esto se considera menos seguro:</p><p>El usuario recibe la contraseña sin cifrar.</p><p>El usuario no puede acceder a su cuenta hasta que recibe el correo electrónico porque la contraseña de la cuenta se cambia en el momento de la solicitud. Es posible impedir que un usuario acceda a su cuenta enviando numerosas solicitudes.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: Un atacante puede ser capaz de descifrar los datos utilizando ataques de fuerza bruta.</p></li></ul>",
                "remediation": "<p>Al enviar contraseñas por correo electrónico, deben revisarse las siguientes áreas:</p><ul><li><p>¿Se obliga al usuario a cambiar la contraseña la primera vez que se conecta? La nueva contraseña se envía por correo electrónico no cifrado y puede permanecer indefinidamente en la bandeja de entrada del usuario si éste no borra el mensaje. Por lo tanto, se debe exigir al usuario que cambie la contraseña la primera vez que se conecte.</p></li><li><p>¿Se genera la contraseña de forma segura? La contraseña debe generarse utilizando un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG), y debe ser lo suficientemente larga como para evitar que se adivine la contraseña o que se produzcan ataques de fuerza bruta. Para que la experiencia del usuario sea segura, debe generarse utilizando una frase de contraseña segura (es decir, combinando varias palabras), en lugar de una cadena aleatoria de caracteres.</p></li><li><p>¿Se envía la contraseña actual del usuario? En lugar de generar una nueva contraseña para el usuario, algunas aplicaciones envían a los usuarios su contraseña actual. Se trata de un método muy inseguro, ya que expone la contraseña actual a través de un correo electrónico no cifrado. Además, si el sitio es capaz de recuperar la contraseña existente, esto implica que las contraseñas se almacenan utilizando un cifrado reversible, o (lo que es más probable) en texto plano sin cifrar, lo que representa una grave debilidad de seguridad.</p></li><li><p>¿Se envían los correos electrónicos desde un dominio con protección anti-spoofing? El dominio debe implementar SPF, DKIM y DMARC para evitar que los atacantes falsifiquen los correos electrónicos procedentes de él, lo que podría utilizarse como parte de un ataque de ingeniería social.</p></li><li><p>¿Se considera el correo electrónico suficientemente seguro? Los correos electrónicos suelen enviarse sin cifrar y, en muchos casos, la cuenta de correo electrónico del usuario no estará protegida por la AMF. Además, puede compartirse entre varias personas, especialmente en un entorno corporativo.</p></li></ul><p>Considere si la funcionalidad de restablecimiento de contraseña por correo electrónico es adecuada en función del contexto de la aplicación que se está probando.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/287.html"
                ],
                "locale": "es",
                "title": "Autenticación incorrecta",
                "vulnType": "OWASP WSTG",
                "description": "<p>La solicitud no prueba o no prueba suficientemente que la afirmación de un actor de poseer una identidad determinada sea cierta.</p>",
                "observation": "<ul><li><p>Control de acceso: Ejecución no autorizada de código o comandos: Esta debilidad puede llevar a la exposición de recursos o funcionalidades a actores no intencionados, posiblemente proporcionando a los atacantes información sensible o incluso ejecutar código arbitrario.</p></li></ul>",
                "remediation": "<p>Utilizar un marco o biblioteca para la autenticación, como la función OWASP ESAPI Authentication.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/285.html"
                ],
                "locale": "es",
                "title": "Todos los controles de autenticación deben fallar de forma segura",
                "vulnType": "OWASP WSTG",
                "description": "<p>La gestión segura de errores es un componente crucial de la codificación segura.Dos errores en particular requieren una atención especial. La primera categoría son las excepciones que surgen durante el procesamiento de un control de seguridad. Es crucial que estas excepciones no permitan acciones que la contramedida normalmente prohibiría.Como desarrollador, debes tener en cuenta que un mecanismo de seguridad suele tener tres resultados posibles:</p><ul><li><p>Permitir el procedimiento.</p></li><li><p>No permitir la operación.</p></li><li><p>Una excepción En general, tu mecanismo de seguridad debe construirse de forma que un fallo tenga el mismo efecto que desactivar la operación.</p></li></ul>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de ficheros o directorios: Un atacante podría leer datos sensibles, ya sea leyendo los datos directamente desde un almacén de datos que no esté debidamente restringido, o accediendo a una funcionalidad privilegiada insuficientemente protegida para leer los datos.</p></li><li><p>Integridad: Modificación de ficheros o directorios: Un atacante podría modificar datos sensibles, ya sea escribiendo los datos directamente en un almacén de datos que no esté debidamente restringido, o accediendo a una funcionalidad privilegiada insuficientemente protegida para escribir los datos.</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Un atacante podría obtener privilegios modificando o leyendo datos críticos directamente, o accediendo a funcionalidades privilegiadas insuficientemente protegidas.</p></li></ul>",
                "remediation": "<p>Antes de utilizar cualquier sistema de control de acceso en su aplicación, asegúrese de que todos ellos han sido sometidos a exhaustivas pruebas de seguridad. Con frecuencia se realizan pruebas unitarias completas específicamente para este fin.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/310.html"
                ],
                "locale": "es",
                "title": "Los módulos criptográficos deben fallar de forma segura - Ataque Padding Oracle",
                "vulnType": "OWASP WSTG",
                "description": "<p>Cuando un módulo criptográfico falla de forma insegura, el dispositivo debe ponerse en estado de error para que deje de ser funcional.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante puede ser capaz de leer información sensible</p></li></ul>",
                "remediation": "<p>Aconsejamos someter el módulo criptográfico a sus propias pruebas utilizando la norma del Instituto Nacional de Normas y Tecnología (NIST) para comprobar si falla de forma segura.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/01-Testing_Directory_Traversal_File_Include",
                    "https://cwe.mitre.org/data/definitions/22.html"
                ],
                "locale": "es",
                "title": "Travesía de la ruta",
                "vulnType": "OWASP WSTG",
                "description": "<p>La vulnerabilidad \"Path Traversal\" permite a los usuarios acceder a archivos o directorios ubicados en otro lugar del sistema escapando de la zona restringida. Es posible acceder a cualquier archivo y directorio almacenado en el sistema de archivos mediante el ajuste de variables que hagan referencia a archivos con secuencias \"punto-barra (../)\" y sus variaciones.</p>",
                "observation": "<ul><li><p>Integridad: Ejecución no autorizada de código o comandos: El atacante puede ser capaz de crear o sobrescribir archivos críticos que se utilizan para ejecutar código, como programas o bibliotecas.</p></li><li><p>Confidencialidad: Ejecución no autorizada de código o comandos: El atacante puede ser capaz de crear o sobrescribir archivos críticos que se utilizan para ejecutar código, como programas o bibliotecas.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: El atacante puede ser capaz de crear o sobrescribir archivos críticos que se utilizan para ejecutar código, como programas o bibliotecas.</p></li><li><p>Integridad: Modificación de ficheros o directorios: El atacante puede ser capaz de sobrescribir o crear archivos críticos, como programas, bibliotecas o datos importantes. Si el archivo objetivo se utiliza para un mecanismo de seguridad, entonces el atacante puede ser capaz de eludir ese mecanismo. Por ejemplo, añadir una nueva cuenta al final de un archivo de contraseñas puede permitir a un atacante saltarse la autenticación.</p></li><li><p>Confidencialidad: Lectura de ficheros o directorios: El atacante puede ser capaz de leer el contenido de archivos inesperados y exponer datos sensibles. Si el archivo objetivo se utiliza para un mecanismo de seguridad, entonces el atacante podría ser capaz de saltarse ese mecanismo. Por ejemplo, al leer un archivo de contraseñas, el atacante podría realizar ataques de fuerza bruta para adivinar contraseñas con el fin de entrar en una cuenta del sistema.</p></li><li><p>Disponibilidad: DoS: Crash, salida, o reinicio: El atacante puede sobrescribir, borrar o corromper archivos críticos inesperados como programas, bibliotecas o datos importantes. Esto puede impedir que el software funcione en absoluto y, en el caso de un mecanismo de protección como la autenticación, tiene el potencial de bloquear a todos los usuarios del software.</p></li></ul>",
                "remediation": "<p>Utilice una estrategia de validación de entradas de datos, o una lista de entradas que cumplan estrictamente los requisitos, y rechace cualquier entrada que no los cumpla.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References",
                    "https://cwe.mitre.org/data/definitions/706.html",
                    "https://cwe.mitre.org/data/definitions/813.html"
                ],
                "locale": "es",
                "title": "IDOR (Referencias Directas a Objetos Inseguras)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Cuando una aplicación concede acceso directo a objetos basándose en una entrada del usuario, esto se conoce como \"referencia directa insegura a objetos\" (IDOR). Esta vulnerabilidad permite a los atacantes eludir la autenticación y obtener acceso directo a los recursos del sistema, como archivos o registros de bases de datos. Cambiando el valor de un parámetro utilizado para apuntar directamente a un objeto, un atacante puede saltarse la autenticación y obtener acceso sin restricciones a los recursos. Estos recursos pueden incluir archivos del sistema, entradas de bases de datos de otros usuarios, etc. Esto sucede porque la aplicación utiliza la entrada proporcionada por el usuario para recuperar un objeto sin realizar suficientes comprobaciones de autorización.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Un atacante podría realizar un número arbitrario de intentos de autenticación utilizando diferentes contraseñas, y finalmente obtener acceso a la cuenta objetivo.</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Es posible la escalada horizontal de privilegios (un usuario puede ver/modificar información de otro usuario).</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: La escalada vertical de privilegios es posible si la clave controlada por el usuario es en realidad una bandera que indica el estado de administrador, lo que permite al atacante obtener acceso administrativo.</p></li></ul>",
                "remediation": "<p>Evita mostrar referencias a elementos secretos como nombres de archivos o claves.</p><p>El servidor debe implementar correctamente la validación de parámetros y la verificación de objetos para todas las referencias.</p><p>Los tokens deben crearse de forma que se restrinja su asignación al usuario y se evite que se compartan con el público.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/306.html"
                ],
                "locale": "es",
                "title": "Principio del menor privilegio",
                "vulnType": "OWASP WSTG",
                "description": "<p>Según el principio del menor privilegio, las cuentas deben tener el menor número de privilegios necesarios para llevar a cabo sus operaciones. Esto incluye los derechos de usuario, así como los permisos de red, sistema de archivos y recursos, como los límites de CPU y memoria.</p>",
                "observation": "<ul><li><p>Otro: Otros: Exponer una funcionalidad crítica proporciona esencialmente a un atacante el nivel de privilegio de esa funcionalidad. Las consecuencias dependerán de la funcionalidad asociada, pero pueden ir desde la lectura o modificación de datos sensibles, el acceso a funcionalidades administrativas u otras privilegiadas, o posiblemente incluso la ejecución de código arbitrario.</p></li></ul>",
                "remediation": "<ul><li><p>Este principio consiste en conceder a una cuenta de usuario únicamente los privilegios esenciales para su trabajo. Por ejemplo, un usuario de copia de seguridad no necesita instalar software: por lo tanto, el usuario de copia de seguridad sólo tiene derechos para ejecutar la copia de seguridad y las aplicaciones relacionadas con la copia de seguridad. Cualquier otro privilegio, como la instalación de nuevo software, está bloqueado.</p></li><li><p>El principio también se aplica a un usuario de ordenador personal que suele trabajar con una cuenta de usuario normal y abre una cuenta privilegiada protegida por contraseña (es decir, un superusuario) sólo cuando la situación lo exige absolutamente.</p></li><li><p>Este principio también puede aplicarse a tus aplicaciones web. En lugar de depender únicamente de métodos de autenticación basados en roles mediante sesiones, lo que queremos es asignar privilegios a los usuarios mediante un sistema de autenticación basado en bases de datos.</p></li></ul><p>Seguimos utilizando sesiones para identificar si el usuario ha iniciado sesión correctamente, sólo que ahora en lugar de asignar a ese usuario un rol específico le asignamos privilegios para verificar qué acciones tiene privilegio de realizar en el sistema.Además, un gran pro de este método es, que cada vez que a un usuario se le tengan que asignar menos privilegios sus cambios se aplicarán sobre la marcha ya que la asignación no depende de la sesión que de otra forma tendría que expirar primero.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/285.html"
                ],
                "locale": "es",
                "title": "Autorización indebida",
                "vulnType": "OWASP WSTG",
                "description": "<p>Cuando un actor intenta acceder a un recurso o llevar a cabo una acción, el software no realiza o realiza incorrectamente una comprobación de autorización.Basándose en los privilegios del usuario y en cualquier permiso u otros requisitos de control de acceso que se apliquen al recurso, la autorización es el proceso de determinar si un usuario con una identidad dada puede acceder a un recurso específico.</p><p>Los usuarios pueden acceder a datos o realizar acciones que no deberían poder llevar a cabo cuando las comprobaciones de control de acceso no se aplican de forma coherente, o no se aplican en absoluto. Esto puede dar lugar a numerosos problemas, como la exposición de información, ataques de denegación de servicio y ejecución de código arbitrario.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de ficheros o directorios: Un atacante podría leer datos sensibles, ya sea leyendo los datos directamente desde un almacén de datos que no esté debidamente restringido, o accediendo a una funcionalidad privilegiada insuficientemente protegida para leer los datos.</p></li><li><p>Integridad: Modificación de ficheros o directorios: Un atacante podría modificar datos sensibles, ya sea escribiendo los datos directamente en un almacén de datos que no esté debidamente restringido, o accediendo a una funcionalidad privilegiada insuficientemente protegida para escribir los datos.</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: Un atacante podría obtener privilegios modificando o leyendo datos críticos directamente, o accediendo a funcionalidades privilegiadas insuficientemente protegidas.</p></li></ul>",
                "remediation": "<p>Arquitectura y diseño</p><ul><li><p>Divida el software en áreas anónimas, normales, privilegiadas y administrativas. Reduzca la superficie de ataque asignando cuidadosamente las funciones a los datos y la funcionalidad. Utilice el control de acceso basado en roles (RBAC) para reforzar los roles en los límites apropiados.</p></li></ul><p>Tenga en cuenta que este enfoque puede no proteger contra la autorización horizontal, es decir, no protegerá a un usuario de atacar a otros con el mismo rol.</p><ul><li><p>Asegúrese de realizar comprobaciones de control de acceso relacionadas con su lógica empresarial. Estas comprobaciones pueden ser diferentes de las comprobaciones de control de acceso que aplicas a recursos más genéricos como archivos, conexiones, procesos, memoria y registros de bases de datos. Por ejemplo, una base de datos puede restringir el acceso a los historiales médicos a un usuario específico de la base de datos, pero puede que cada historial sólo sea accesible para el paciente y su médico.</p></li><li><p>Utilice una biblioteca o marco de trabajo que no permita que se produzca esta debilidad o que proporcione construcciones que faciliten evitarla.</p></li><li><p>Por ejemplo, considere el uso de marcos de autorización como JAAS Authorization Framework REF-233 y OWASP ESAPI Access Control feature REF-45.</p></li><li><p>Para aplicaciones web, asegúrese de que el mecanismo de control de acceso se aplica correctamente en el lado del servidor en cada página. Los usuarios no deberían poder acceder a ninguna funcionalidad o información no autorizada simplemente solicitando acceso directo a esa página.</p></li><li><p>Una forma de hacerlo es asegurarse de que todas las páginas que contengan información sensible no se almacenen en caché, y que todas esas páginas restrinjan el acceso a las solicitudes que vayan acompañadas de un token de sesión activo y autenticado asociado a un usuario que tenga los permisos necesarios para acceder a esa página.</p></li></ul><p>Configuración del sistema: Instalación</p><ul><li><p>Utilice las capacidades de control de acceso de su sistema operativo y entorno de servidor y defina sus listas de control de acceso en consecuencia. Utilice una política de \"denegación por defecto\" al definir estas ACL.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/01-Testing_for_Session_Management_Schema",
                    "https://cwe.mitre.org/data/definitions/1018.html",
                    "https://owasp.org/www-community/attacks/Session_Prediction"
                ],
                "locale": "es",
                "title": "ID de sesión predecible",
                "vulnType": "OWASP WSTG",
                "description": "<p>El objetivo principal del ataque de predicción de sesión es prever valores de ID de sesión que permitan a un atacante eludir el proceso de autenticación de una aplicación. Un atacante puede predecir un valor de ID de sesión válido y obtener acceso a la aplicación investigando y comprendiendo el proceso de generación del ID de sesión.</p><p>En primer lugar, el atacante necesita recopilar algunos valores de ID de sesión válidos que se utilizan para identificar a los usuarios autenticados. A continuación, necesita entender la estructura del identificador de sesión, la información utilizada para crearlo y el algoritmo de cifrado o hash utilizado por la aplicación para protegerlo. Algunas malas implementaciones utilizan identificadores de sesión compuestos por el nombre de usuario u otra información predecible, como la marca de tiempo o la dirección IP del cliente. En el peor de los casos, esta información se utiliza en texto claro o se codifica utilizando algún algoritmo débil como la codificación base64.</p><p>Además, el atacante puede implementar una técnica de fuerza bruta para generar y probar diferentes valores del identificador de sesión hasta que consiga acceder a la aplicación.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Un atacante podría permanecer registrado durante mucho tiempo, lo que podría reutilizar ID antiguos o eliminados y referencias directas.</p></li></ul>",
                "remediation": "<p>Utilizando hashes y variables no repetibles como las marcas de tiempo, se debería generar una sesión no predecible.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/614.html https://cwe.mitre.org/data/definitions/1004.html",
                    "https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies",
                    "https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html"
                ],
                "locale": "es",
                "title": "Falta el atributo Secure en las cookies",
                "vulnType": "OWASP WSTG",
                "description": "<p>El atributo Secure y el atributo HttpOnly se utilizan para asegurarse de que las cookies se envían de forma segura y no pueden ser accedidas por scripts o partes no deseadas. Una cookie con el atributo Secure sólo se envía al servidor junto con una solicitud HTTPS cifrada. La API de JavaScript no puede acceder a una cookie con el atributo HttpOnly; en su lugar, la recibe el servidor.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: Un atacante que realice con éxito un ataque cross-site scripting o man-in-the-middle podrá leer el contenido de la cookie y exfiltrar la información obtenida.</p></li></ul>",
                "remediation": "<p>Para mitigar esta vulnerabilidad, el servidor debe utilizar los atributos HttpOnly y Secure al configurar las cookies. A continuación se proporciona una ilustración:</p><p>Set-Cookie: cookie1=info1; Secure; HttpOnly</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/614.html https://cwe.mitre.org/data/definitions/1004.html",
                    "https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies",
                    "https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html"
                ],
                "locale": "es",
                "title": "Falta el atributo HTTP Only en las cookies",
                "vulnType": "OWASP WSTG",
                "description": "<p>El atributo Secure y el atributo HttpOnly se emplean para garantizar que las cookies se envían de forma segura y que no pueden acceder a ellas personas o scripts no autorizados. Sólo las solicitudes cifradas realizadas mediante el protocolo HTTPS y nunca HTTP no seguro pueden enviar cookies con el atributo Secure al servidor. La API de JavaScript no puede acceder a una cookie con el atributo HttpOnly porque sólo se envía al servidor.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: Si el indicador HttpOnly no está activado, la información confidencial almacenada en la cookie puede quedar expuesta a terceros no deseados.</p></li><li><p>Integridad: Obtención de privilegios o suplantación de identidad: Si la cookie en cuestión es una cookie de autenticación, entonces no establecer la bandera HttpOnly puede permitir a un adversario robar datos de autenticación (por ejemplo, un ID de sesión) y asumir la identidad del usuario.</p></li></ul>",
                "remediation": "<p>Para mitigar esta vulnerabilidad, el servidor debe utilizar los atributos HttpOnly y Secure al configurar las cookies. A continuación se proporciona una ilustración:</p><p>Set-Cookie: cookie1=info1; Secure; HttpOnly</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/02-Testing_for_Cookies_Attributes",
                    "https://cwe.mitre.org/data/definitions/1275.html",
                    "https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html",
                    "https://cwe.mitre.org/data/definitions/1275.html"
                ],
                "locale": "es",
                "title": "Falta el atributo SameSite en las cookies",
                "vulnType": "OWASP WSTG",
                "description": "<p>Se ha descubierto que las cookies creadas por la aplicación no hacen uso del mecanismo de protección SameSite en el momento del acceso al sitio web. Esta salvaguarda evita posibles ataques de falsificación de petición entre sitios (CSRF) regulando cómo se envían las cookies en las peticiones a otros dominios.</p>",
                "observation": "<ul><li><p>Confidencialidad: Modificación de datos de aplicación: Si el sitio web no impone una defensa adicional contra ataques CSRF, no utilizar los valores 'Lax' o 'Strict' podría aumentar el riesgo de exposición a ataques CSRF. La probabilidad de violación de la integridad es baja porque un ataque con éxito no depende únicamente de un atributo SameSite inseguro. Para realizar un ataque CSRF se deben cumplir muchas condiciones, como la falta de tokens CSRF, la ausencia de confirmaciones para acciones sensibles en el sitio web, una cabecera \"simple\" \"Content-Type\" en la petición HTTP y muchas más.</p></li></ul>",
                "remediation": "<p>Siempre que sea posible, se recomienda crear cookies con el atributo \"SameSite\" en el valor \"Strict\".</p><p>Set-Cookie: <Cookie>=<Value>; Path=/; Expires=<Date>; Domain=<Domain>; Secure; HttpOnly; SameSite=Strict</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/02-Testing_for_Cookies_Attributes",
                    "https://cwe.mitre.org/data/definitions/613.html"
                ],
                "locale": "es",
                "title": "Las cookies de aplicación tienen una caducidad excesiva o indefinida.",
                "vulnType": "OWASP WSTG",
                "description": "<p>El atributo Expires se utiliza para:</p><ul><li><p>Establecer cookies persistentes.</p></li><li><p>Limitar el tiempo de vida si una sesión dura demasiado.</p></li><li><p>Eliminar forzosamente una cookie estableciendo una fecha en el pasado.</p></li></ul><p>A diferencia de las cookies de sesión, las cookies persistentes serán utilizadas por el navegador hasta que la cookie expire. Una vez pasada la fecha de caducidad, el navegador borrará la cookie.</p><p>La falta de caducidad adecuada de la sesión puede aumentar la probabilidad de éxito de ciertos ataques. Por ejemplo, un atacante puede interceptar un identificador de sesión, posiblemente a través de un sniffer de red o un ataque Cross-site Scripting. Aunque los tiempos de expiración de sesión cortos no ayudan si un token robado se utiliza inmediatamente, protegerán contra la repetición continua del ID de sesión. En otro escenario, un usuario podría acceder a un sitio web desde un ordenador compartido (como en una biblioteca, un cibercafé o un entorno de trabajo abierto). Una caducidad de sesión insuficiente podría permitir a un atacante utilizar el botón de retroceso del navegador para acceder a páginas web a las que la víctima haya accedido previamente.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Un atacante podría permanecer registrado durante mucho tiempo, lo que podría reutilizar ID antiguos o eliminados y referencias directas.</p></li></ul>",
                "remediation": "<p>Sólo las cookies persistentes se establecen utilizando el propio atributo. Sin embargo, es crucial comprobar que no hay datos sensibles en la cookie persistente. Por ejemplo, si una cookie persistente se utiliza para almacenar información necesaria para la autenticación del usuario, un atacante con acceso a la cookie podría utilizarla para demostrar su identidad a la aplicación.</p><p>Por lo tanto, debemos asegurarnos de que una cookie que contenga información sensible no tenga el atributo 'Expires' establecido.</p><p>Por otro lado, es aconsejable establecer tiempos de expiración breves para disminuir la probabilidad de que un potencial atacante las reutilice.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-community/Session_Timeout"
                ],
                "locale": "es",
                "title": "Expiración de sesión insuficiente",
                "vulnType": "OWASP WSTG",
                "description": "<p>Las cookies de sesión únicas de los usuarios autenticados, que suelen utilizar las aplicaciones web, deben configurarse con un tiempo de vida para que caduquen después de un tiempo máximo establecido. Debido a esto, si un usuario inicia sesión en otro ordenador sin finalizar manualmente su sesión, cualquier otro usuario que inicie sesión en ese ordenador y acceda a la aplicación seguirá estando en la sesión del usuario autenticado anterior.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Un atacante podría permanecer registrado durante mucho tiempo, lo que podría reutilizar ID antiguos o eliminados y referencias directas.</p></li></ul>",
                "remediation": "<p>Reducir los tiempos de expiración de la sesión.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/03-Testing_for_Session_Fixation",
                    "https://cwe.mitre.org/data/definitions/384.html"
                ],
                "locale": "es",
                "title": "Fijación de la sesión",
                "vulnType": "OWASP WSTG",
                "description": "<p>Autenticar a un usuario, o establecer una nueva sesión de usuario, sin invalidar ningún identificador de sesión existente, da a un atacante la oportunidad de robar sesiones autenticadas.</p><p>Este escenario se observa comúnmente cuando:</p><ol><li><p>Una aplicación web autentica a un usuario sin invalidar primero la sesión existente, continuando así la sesión ya asociada al usuario.</p></li><li><p>Un atacante es capaz de forzar un identificador de sesión conocido en un usuario para que, una vez que el usuario se autentique, el atacante tenga acceso a la sesión autenticada.</p></li><li><p>La aplicación o contenedor utiliza identificadores de sesión predecibles. En el exploit genérico de vulnerabilidades de fijación de sesión, un atacante crea una nueva sesión en una aplicación web y registra el identificador de sesión asociado. A continuación, el atacante hace que la víctima se asocie, y posiblemente se autentique, contra el servidor utilizando ese identificador de sesión, dando al atacante acceso a la cuenta del usuario a través de la sesión activa.</p></li></ol>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Un atacante podría permanecer registrado durante mucho tiempo, lo que podría reutilizar ID antiguos o eliminados y referencias directas.</p></li></ul>",
                "remediation": "<p>La contramedida para una vulnerabilidad de fijación de sesión es codificar la aplicación de tal manera que impida que la aplicación acepte un token que ha sido forzado en la sesión de la víctima.</p><p>Los siguientes pasos proporcionan una forma robusta de asegurar una aplicación web contra estos ataques:</p><ul><li><p>No aceptar identificadores de sesión en parámetros GET o POST. Esto lo hace mucho más difícil de explotar para un atacante, ya que es más fácil engañar a una víctima para que haga la petición sin vulnerabilidades en el navegador. Además, todos los identificadores de sesión deben ser generados por el servidor; no debería ser necesario que el cliente proponga un nuevo identificador de sesión para la solicitud.</p></li><li><p>Cambiar el ID de sesión después del inicio de sesión. El servidor debe generar un nuevo ID de sesión y establecerlo como cookie después de que el usuario haya iniciado sesión. Cualquier sesión existente para el usuario debe ser destruida en el servidor.</p></li><li><p>Proporcionar una función de cierre de sesión y expirar las sesiones antiguas. El usuario debería poder elegir cuándo finalizar su sesión con la aplicación, lo que debería terminar inmediatamente cualquier sesión actual en el servidor y no simplemente borrar la cookie del navegador. Los datos de la sesión también deberían expirar automáticamente después de un cierto periodo, para reducir el tiempo que un atacante puede hacer uso de una sesión comprometida.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery",
                    "https://cwe.mitre.org/data/definitions/352.html"
                ],
                "locale": "es",
                "title": "Falsificación de petición en sitios cruzados (CSRF)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Un ataque CSRF tiene como objetivo engañar a un usuario para que ejecute involuntariamente una funcionalidad en una aplicación web vulnerable que beneficiará al atacante y perjudicará al usuario afectado.</p><p>Concretamente, el ataque se lleva a cabo forzando al navegador de un usuario desprevenido a realizar una petición al sitio web vulnerable, petición que el usuario llevará a cabo sin darse cuenta, y teniendo éxito siempre y cuando el usuario esté logueado en el sitio web ya que se utilizarán automáticamente las credenciales ya establecidas (ID de sesión, cookies,...).</p><p>A diferencia de los ataques XSS, que explotan la confianza que un usuario tiene en un sitio en particular, la Falsificación de Petición de Sitio Cruzado explota la confianza que un sitio tiene en un usuario en particular. Se trata de una vulnerabilidad de autenticación insuficiente en la que la aplicación no valida correctamente el origen de la solicitud.</p>",
                "observation": "<ul><li><p>Control de acceso: DoS: Crash, salida, o reinicio: Las consecuencias variarán en función de la naturaleza de la funcionalidad vulnerable a CSRF. Un atacante podría efectivamente realizar cualquier operación como la víctima. Si la víctima es un administrador o un usuario con privilegios, las consecuencias pueden incluir la obtención del control total de la aplicación web: borrar o robar datos, desinstalar el producto o utilizarlo para lanzar otros ataques contra todos los usuarios del producto. Dado que el atacante tiene la identidad de la víctima, el alcance de CSRF está limitado únicamente por los privilegios de la víctima.</p></li></ul>",
                "remediation": "<p>Para evitar los ataques Cross-Site Request Forgery, es necesario que cada petición realizada al sitio web contenga un identificador único (un token sincronizador), que debe ser un parámetro que el atacante no pueda averiguar.</p><p>Por ejemplo, se sugiere enviar en un parámetro el identificador de sesión del usuario legítimo. El servidor debe comprobar este parámetro como forma de validar que es efectivamente el usuario actual quien solicita la operación en curso.</p><p>Además, se puede solicitar la interacción del usuario para operaciones sensibles como forma de doble autenticación o respondiendo a un CAPTCHA.</p><p>También debe comprobarse la cabecera REFERER en la solicitud del cliente para asegurarse de que cada solicitud procede del sitio original y no de una fuente externa. Esta mitigación, aunque necesaria, puede ser eludida por un atacante que utilice otros tipos de vulnerabilidades como XSS.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery",
                    "https://cwe.mitre.org/data/definitions/352.html"
                ],
                "locale": "es",
                "title": "Ausencia de anti-CSRF simbólico",
                "vulnType": "OWASP WSTG",
                "description": "<p>Un ataque CSRF tiene como objetivo engañar a un usuario para que ejecute involuntariamente una funcionalidad en una aplicación web vulnerable que beneficiará al atacante y perjudicará al usuario afectado.</p><p>Concretamente, el ataque se lleva a cabo forzando al navegador de un usuario desprevenido a realizar una petición al sitio web vulnerable, petición que el usuario llevará a cabo sin darse cuenta, y teniendo éxito siempre y cuando el usuario esté logueado en el sitio web ya que se utilizarán automáticamente las credenciales ya establecidas (ID de sesión, cookies,...).</p><p>A diferencia de los ataques XSS, que explotan la confianza que un usuario tiene en un sitio en particular, la Falsificación de Petición de Sitio Cruzado explota la confianza que un sitio tiene en un usuario en particular. Se trata de una vulnerabilidad de autenticación insuficiente en la que la aplicación no valida correctamente el origen de la solicitud.</p>",
                "observation": "<ul><li><p>Control de acceso: DoS: Crash, salida, o reinicio: Las consecuencias variarán en función de la naturaleza de la funcionalidad vulnerable a CSRF. Un atacante podría efectivamente realizar cualquier operación como la víctima. Si la víctima es un administrador o un usuario con privilegios, las consecuencias pueden incluir la obtención del control total de la aplicación web: borrar o robar datos, desinstalar el producto o utilizarlo para lanzar otros ataques contra todos los usuarios del producto. Dado que el atacante tiene la identidad de la víctima, el alcance de CSRF está limitado únicamente por los privilegios de la víctima.</p></li></ul>",
                "remediation": "<p>La aplicación debe actualizarse para incluir soporte de token anti-CSRF para cualquier formulario sensible que sea accesible durante una sesión autenticada.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/06-Testing_for_Logout_Functionality",
                    "https://cwe.mitre.org/data/definitions/287.html"
                ],
                "locale": "es",
                "title": "Debilidades en el proceso de cierre de sesión.",
                "vulnType": "OWASP WSTG",
                "description": "<p>El mecanismo de cierre de sesión de los usuarios de las aplicaciones está mal implementado.</p><p>Un usuario puede volver a interactuar con la aplicación sin tener que volver a introducir sus datos de acceso porque la sesión no se invalida correctamente.</p>",
                "observation": "<ul><li><p>Control de acceso: Ejecución no autorizada de código o comandos: Esta debilidad puede llevar a la exposición de recursos o funcionalidades a actores no intencionados, posiblemente proporcionando a los atacantes información sensible o incluso ejecutar código arbitrario.</p></li></ul>",
                "remediation": "<p>Se aconseja que el botón de cierre de sesión esté presente en todas las páginas de la aplicación, que invalide la sesión tanto en el cliente como en el servidor, y que el servidor rechace cualquier otra conexión realizada con el mismo token.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/07-Testing_Session_Timeout",
                    "https://cwe.mitre.org/data/definitions/1018.html"
                ],
                "locale": "es",
                "title": "Debilidades en el proceso de cierre de sesión por inactividad.",
                "vulnType": "OWASP WSTG",
                "description": "<p>Todas las aplicaciones deben implementar un tiempo de espera de inactividad para las sesiones. Este tiempo de espera define la cantidad de tiempo que una sesión permanecerá activa en caso de que no haya actividad por parte del usuario, cerrando e invalidando la sesión tras el periodo de inactividad definido desde la última petición HTTP recibida por la aplicación web para un ID de sesión determinado. El tiempo de espera más apropiado debe ser un equilibrio entre seguridad (tiempo de espera más corto) y usabilidad (tiempo de espera más largo) y depende en gran medida del nivel de sensibilidad de los datos manejados por la aplicación. Por ejemplo, un tiempo de cierre de sesión de 60 minutos para un foro público puede ser aceptable, pero un tiempo tan largo sería excesivo en una aplicación de banca doméstica (donde se recomienda un tiempo máximo de 15 minutos). En cualquier caso, cualquier aplicación que no imponga un cierre de sesión basado en el tiempo de espera debe considerarse insegura, a menos que tal comportamiento sea exigido por un requisito funcional específico.</p><p>El tiempo de espera limita las posibilidades de que un atacante adivine y utilice un identificador de sesión válido de otro usuario y, en determinadas circunstancias, podría proteger los ordenadores públicos de la reutilización de sesiones. Sin embargo, si el atacante es capaz de secuestrar una sesión determinada, el tiempo de espera de inactividad no limita las acciones del atacante, ya que puede generar actividad en la sesión periódicamente para mantener la sesión activa durante más tiempo.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Un atacante podría permanecer registrado durante mucho tiempo, lo que podría reutilizar ID antiguos o eliminados y referencias directas.</p></li></ul>",
                "remediation": "<p>El lado del servidor debe implementar la gestión del tiempo de espera y expiración de la sesión. Un atacante podría manipular los datos controlados por el cliente que se utilizan para hacer cumplir el tiempo de espera de la sesión, como los valores de las cookies u otros parámetros del cliente que hacen un seguimiento de las referencias temporales (como el número de minutos transcurridos desde la hora de inicio de sesión), con el fin de alargar la sesión. Como resultado, la aplicación debe controlar el tiempo de inactividad del lado del servidor y, una vez transcurrido el tiempo de espera, invalidar automáticamente la sesión del usuario actual y borrar todos los datos del lado del cliente.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/09-Testing_for_Session_Hijacking",
                    "https://capec.mitre.org/data/definitions/593.html"
                ],
                "locale": "es",
                "title": "Secuestro de sesión",
                "vulnType": "OWASP WSTG",
                "description": "<p>El ataque de secuestro de sesión consiste en explotar el mecanismo de control de sesión web, que normalmente se gestiona mediante un testigo de sesión.</p><p>Dado que la comunicación http utiliza muchas conexiones TCP diferentes, el servidor web necesita un método para reconocer las conexiones de cada usuario. El método más útil se basa en un token que el servidor web envía al navegador del cliente una vez que éste se ha autenticado correctamente. Un token de sesión se compone normalmente de una cadena de anchura variable y puede utilizarse de diversas formas, como en la URL, en la cabecera de la petición HTTP como cookie, en otras partes de la cabecera de la petición HTTP o incluso en el cuerpo de la petición HTTP.</p><p>El ataque de secuestro de sesión compromete el testigo de sesión robando o prediciendo un testigo de sesión válido para obtener acceso no autorizado al servidor web.</p><p>El testigo de sesión puede ser comprometido de diferentes maneras; las más comunes son:- Predicción del testigo de sesión.- Escaneo de sesión.- Ataques del lado del cliente (XSS, código JavaScript malicioso, troyanos, etc.).- Ataque Man-in-the-middle.- Ataque Man-in-the-browser.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Un atacante podría permanecer registrado durante mucho tiempo, lo que podría reutilizar ID antiguos o eliminados y referencias directas.</p></li></ul>",
                "remediation": "<p>Utiliza procesos de generación de claves de sesión estándar del sector que generen claves de sesión utilizando mucha entropía, y cifra y firma adecuadamente los tokens de identidad en tránsito. Puedes confiar en que muchos servidores web y de aplicaciones comunes se encarguen de esta tarea. Para cada sesión, utiliza un tiempo de espera de sesión. Después de este periodo de tiempo, finaliza la sesión del usuario si no se ha desconectado explícitamente. Si el usuario vuelve a conectarse, deberá generarse una nueva clave de sesión.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-community/attacks/Session_hijacking_attack"
                ],
                "locale": "es",
                "title": "No se controlan adecuadamente los inicios de sesión simultáneos.",
                "vulnType": "OWASP WSTG",
                "description": "<p>Las aplicaciones que requieren autenticación sólo deben permitir una sesión activa por usuario y no deben permitir múltiples sesiones de usuario autenticado a través de varios navegadores u ordenadores.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Un atacante podría permanecer registrado durante mucho tiempo, lo que podría reutilizar ID antiguos o eliminados y referencias directas.</p></li></ul>",
                "remediation": "<p>Se aconseja que las sesiones de un mismo usuario no se ejecuten simultáneamente y que siempre reciban una notificación cuando una sesión antigua siga activa.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/159.html"
                ],
                "locale": "es",
                "title": "(genérico) No sanitizar la entrada",
                "vulnType": "OWASP WSTG",
                "description": "<p>El uso incorrecto de elementos especiales en la entrada controlada por el usuario no es filtrado, eliminado, citado o gestionado de otro modo por el producto, lo que podría tener un impacto negativo en su comportamiento e integridad.</p>",
                "observation": "<ul><li><p>Disponibilidad: DoS: Crash, salida, o reinicio: Las comprobaciones de validación del lado del cliente pueden eludirse fácilmente, permitiendo que una entrada malformada o inesperada pase a la aplicación, potencialmente como datos de confianza. Esto puede dar lugar a estados y comportamientos inesperados y, posiblemente, a un bloqueo.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: Un atacante podría utilizar una entrada maliciosa para modificar datos o posiblemente alterar el flujo de control de formas inesperadas, incluida la ejecución arbitraria de comandos.</p></li></ul>",
                "remediation": "<p>Los desarrolladores deben prever que se inyectarán/eliminarán/manipularán elementos especiales en los vectores de entrada de su sistema de software. Utilizar una combinación adecuada de listas negras y listas blancas para garantizar que el sistema sólo procesa entradas válidas, esperadas y apropiadas.Aplicación</p><ul><li><p>Asumir que todas las entradas son maliciosas. Utilizar una estrategia de validación de entradas \"\"aceptar lo bueno conocido\"\", es decir, utilizar una lista de entradas aceptables que se ajusten estrictamente a las especificaciones. Rechace cualquier entrada que no se ajuste estrictamente a las especificaciones o transfórmela en algo que sí lo haga. A la hora de validar las entradas, hay que tener en cuenta todas las propiedades potencialmente relevantes, como la longitud, el tipo de entrada, la gama completa de valores aceptables, las entradas que faltan o sobran, la sintaxis, la coherencia entre campos relacionados y la conformidad con las reglas de negocio. Como ejemplo de lógica de reglas de negocio, \"\"barco\"\" puede ser sintácticamente válido porque sólo contiene caracteres alfanuméricos, pero no es válido si sólo se espera que la entrada contenga colores como \"rojo\" o \"azul\". No confíe exclusivamente en la búsqueda de entradas maliciosas o malformadas. Es probable que se pase por alto al menos una entrada no deseada, sobre todo si cambia el entorno del código. Esto puede dar a los atacantes suficiente margen para eludir la validación prevista. Sin embargo, las listas negras pueden ser útiles para detectar posibles ataques o determinar qué entradas están tan malformadas que deberían rechazarse directamente.</p></li><li><p>Aunque es arriesgado utilizar cadenas de consulta generadas dinámicamente, código o comandos que mezclen control y datos, a veces puede ser inevitable. Entrecomille correctamente los argumentos y escape los caracteres especiales que contengan. El enfoque más conservador es escapar o filtrar todos los caracteres que no pasen una lista blanca extremadamente estricta (como todo lo que no sea alfanumérico o espacio en blanco). Si todavía se necesitan algunos caracteres especiales, como espacios en blanco, encierre cada argumento entre comillas después del paso de escape/filtrado. Tenga cuidado con la inyección de argumentos (88).</p></li><li><p>Las entradas deben ser decodificadas y canonicalizadas a la representación interna actual de la aplicación antes de ser validadas (180). Asegúrate de que la aplicación no decodifica la misma entrada dos veces (174). Tales errores podrían utilizarse para eludir los esquemas de validación de listas blancas introduciendo entradas peligrosas después de haber sido comprobadas.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting",
                    "https://owasp.org/www-community/attacks/xss/",
                    "https://cwe.mitre.org/data/definitions/79.html"
                ],
                "locale": "es",
                "title": "(genérico) Secuencias de comandos en sitios cruzados (XSS)",
                "vulnType": "OWASP WSTG",
                "description": "<p>La vulnerabilidad \"Cross-Site Scripting (XSS)\" permite a terceros inyectar código Java Script o HTML en páginas web de aplicaciones específicas. De este modo, es posible robar sesiones de usuario, comprometer la seguridad del sistema y obtener información confidencial o privada de la aplicación.</p><p>Esta vulnerabilidad suele producirse porque una aplicación no valida los parámetros de entrada y salida, lo que ocurre con frecuencia con los formularios.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El ataque más común realizado con cross-site scripting implica la divulgación de información almacenada en las cookies del usuario. Normalmente, un usuario malintencionado elabora un script del lado del cliente que, cuando es analizado por un navegador web, realiza alguna actividad (como enviar todas las cookies del sitio a una dirección de correo electrónico determinada). Este script será cargado y ejecutado por cada usuario que visite el sitio web. Dado que el sitio que solicita ejecutar el script tiene acceso a las cookies en cuestión, el script malicioso también lo tiene.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: En algunas circunstancias puede ser posible ejecutar código arbitrario en el ordenador de una víctima cuando el cross-site scripting se combina con otros fallos.</p></li><li><p>Control de acceso: Lectura de datos de aplicación: La consecuencia de un ataque XSS es la misma independientemente de si se almacena o se refleja. La diferencia está en cómo llega la carga útil al servidor. XSS puede causar una variedad de problemas para el usuario final que varían en gravedad desde una molestia hasta el compromiso completo de la cuenta. Algunas vulnerabilidades de cross-site scripting pueden ser explotadas para manipular o robar cookies, crear peticiones que pueden ser confundidas con las de un usuario válido, comprometer información confidencial, o ejecutar código malicioso en los sistemas del usuario final para una variedad de propósitos nefastos. Otros ataques dañinos incluyen la divulgación de archivos del usuario final, la instalación de programas troyanos, la redirección del usuario a otra página o sitio, la ejecución de controles \"Active X\" (bajo Microsoft Internet Explorer) desde sitios que el usuario percibe como fiables y la modificación de la presentación del contenido.</p></li></ul>",
                "remediation": "<p>Cada parámetro que gestiona la aplicación necesita ser validado, especialmente cuando se trata de datos de entrada proporcionados por el usuario. Esta validación se realiza siempre en el lado del servidor y NUNCA se basa en validaciones realizadas en el lado del cliente.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting",
                    "https://owasp.org/www-community/attacks/xss/",
                    "https://cwe.mitre.org/data/definitions/79.html"
                ],
                "locale": "es",
                "title": "Secuencias de comandos en sitios cruzados reflejadas (XSS reflejadas)",
                "vulnType": "OWASP WSTG",
                "description": "<p>A través de un ataque Cross-Site Scripting (XSS), un atacante puede insertar código malicioso que se ejecuta en el navegador de la víctima, tomar el control del navegador y utilizarlo para acceder a credenciales, datos sensibles o datos de sesión de la aplicación afectada.</p><p>Para que Reflected Cross-Site Scripting funcione, el atacante debe estar en contacto directo con la víctima para enviar el código malicioso que se ejecutará en el navegador de la víctima como parte de la aplicación.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El ataque más común realizado con cross-site scripting implica la divulgación de información almacenada en las cookies del usuario. Normalmente, un usuario malintencionado elabora un script del lado del cliente que, cuando es analizado por un navegador web, realiza alguna actividad (como enviar todas las cookies del sitio a una dirección de correo electrónico determinada). Este script será cargado y ejecutado por cada usuario que visite el sitio web. Dado que el sitio que solicita ejecutar el script tiene acceso a las cookies en cuestión, el script malicioso también lo tiene.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: En algunas circunstancias puede ser posible ejecutar código arbitrario en el ordenador de una víctima cuando el cross-site scripting se combina con otros fallos.</p></li><li><p>Control de acceso: Lectura de datos de aplicación: La consecuencia de un ataque XSS es la misma independientemente de si se almacena o se refleja. La diferencia está en cómo llega la carga útil al servidor. XSS puede causar una variedad de problemas para el usuario final que varían en gravedad desde una molestia hasta el compromiso completo de la cuenta. Algunas vulnerabilidades de cross-site scripting pueden ser explotadas para manipular o robar cookies, crear peticiones que pueden ser confundidas con las de un usuario válido, comprometer información confidencial, o ejecutar código malicioso en los sistemas del usuario final para una variedad de propósitos nefastos. Otros ataques dañinos incluyen la divulgación de archivos del usuario final, la instalación de programas troyanos, la redirección del usuario a otra página o sitio, la ejecución de controles \"Active X\" (bajo Microsoft Internet Explorer) desde sitios que el usuario percibe como fiables y la modificación de la presentación del contenido.</p></li></ul>",
                "remediation": "<p>Prevenir los ataques de Cross-site Scripting (XSS) no es trivial dependiendo de la complejidad de la aplicación y de cómo maneja los datos controlables por el usuario y del tipo de vulnerabilidad de Cross-site Scripting (XSS).</p><p>Sin embargo, existen ciertos principios generales que las siguientes medidas deberían aplicar:</p><ul><li><p>Filtrar la entrada de datos: Tratar toda la entrada de datos del usuario como no fiable, filtrar lo más estrictamente posible en función de lo que se espera o es una entrada válida.</p></li><li><p>Utilizar el cifrado: Con el uso de una técnica de cifrado adecuada evitar que se interprete como contenido legítimo.</p></li><li><p>Utilice cabeceras de respuesta seguras: Los navegadores aceptan diferentes tipos de cabeceras para prevenir ataques de Cross-site Scripting (XSS), como una Política de Seguridad de Contenidos (CSP) y 'X-XSS-Protection'.</p></li><li><p>Proteger las cookies: Es necesario mitigar el posible acceso a las cookies de sesión con la bandera 'HttpOnly'. Esta bandera desactiva el acceso a las cookies a través de JavaScript del lado del cliente.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-community/attacks/Server_Side_Request_Forgery https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_SS heet.html"
                ],
                "locale": "es",
                "title": "Secuencias de comandos en sitios cruzados almacenadas (XSS almacenadas)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Los ataques Cross-Site Scripting (XSS) son un tipo de inyección, en la que se inyectan scripts maliciosos en sitios web por lo demás benignos y de confianza. Los ataques XSS se producen cuando un atacante utiliza una aplicación web para enviar código malicioso, generalmente en forma de script del lado del navegador, a otro usuario final. Los fallos que permiten que estos ataques tengan éxito están bastante extendidos y se producen en cualquier lugar en el que una aplicación web utiliza la entrada de un usuario dentro de la salida que genera sin validarla ni codificarla. Los ataques almacenados son aquellos en los que el script inyectado se almacena permanentemente en los servidores objetivo, como en una base de datos, en un foro de mensajes, registro de visitantes, campo de comentarios, etc. La víctima recupera entonces el script malicioso del servidor cuando solicita la información almacenada. El XSS almacenado también se denomina a veces XSS persistente o de tipo I.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El ataque más común realizado con cross-site scripting implica la divulgación de información almacenada en las cookies del usuario. Normalmente, un usuario malintencionado elabora un script del lado del cliente que, cuando es analizado por un navegador web, realiza alguna actividad (como enviar todas las cookies del sitio a una dirección de correo electrónico determinada). Este script será cargado y ejecutado por cada usuario que visite el sitio web. Dado que el sitio que solicita ejecutar el script tiene acceso a las cookies en cuestión, el script malicioso también lo tiene.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: En algunas circunstancias puede ser posible ejecutar código arbitrario en el ordenador de una víctima cuando el cross-site scripting se combina con otros fallos.</p></li><li><p>Control de acceso: Lectura de datos de aplicación: La consecuencia de un ataque XSS es la misma independientemente de si se almacena o se refleja. La diferencia está en cómo llega la carga útil al servidor. XSS puede causar una variedad de problemas para el usuario final que varían en gravedad desde una molestia hasta el compromiso completo de la cuenta. Algunas vulnerabilidades de cross-site scripting pueden ser explotadas para manipular o robar cookies, crear peticiones que pueden ser confundidas con las de un usuario válido, comprometer información confidencial, o ejecutar código malicioso en los sistemas del usuario final para una variedad de propósitos nefastos. Otros ataques dañinos incluyen la divulgación de archivos del usuario final, la instalación de programas troyanos, la redirección del usuario a otra página o sitio, la ejecución de controles \"Active X\" (bajo Microsoft Internet Explorer) desde sitios que el usuario percibe como fiables y la modificación de la presentación del contenido.</p></li></ul>",
                "remediation": "<p>Es necesario sanitizar toda la entrada del lado del servidor para reducir el riesgo de XSS almacenado. Para servir todos los datos al lado del cliente, cree un filtro de caja blanca con los caracteres permitidos y utilice codificación html.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution",
                    "https://cwe.mitre.org/data/definitions/235.html",
                    "https://capec.mitre.org/data/definitions/460.html"
                ],
                "locale": "es",
                "title": "Contaminación de parámetros HTTP (HPP)",
                "vulnType": "OWASP WSTG",
                "description": "<p>La Contaminación de Parámetros HTTP se aprovecha del comportamiento incorrecto de la aplicación cuando responde a peticiones HTTP que tienen el mismo parámetro definido en el servidor pero que fueron enviadas con valores diferentes. La Contaminación de Parámetros HTTP se aprovecha del comportamiento incorrecto de la aplicación al responder a peticiones HTTP que tienen el mismo parámetro definido en el servidor pero que fueron enviadas con valores diferentes.</p>",
                "observation": "<ul><li><p>Integridad: Estado inesperado: Un atacante podría manipular parámetros en la aplicación</p></li></ul>",
                "remediation": "<p>Este tipo de ataque podría evitarse saneando adecuadamente los datos de entrada, verificando el número de instancias de parámetros individuales en una petición y buscando peticiones con asignaciones duplicadas.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://www.owasp.org/index.php/SQL_Injection"
                ],
                "locale": "es",
                "title": "Inyección SQL (genérica)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Mediante el uso de la inyección de código SQL (SQLi), es posible cambiar la lógica de las sentencias SQL y permitir la ejecución de diferentes tipos de consultas a la base de datos. Además de añadir nuevos registros o borrar/modificar los existentes, es posible obtener datos de la base de datos que, en teoría, no deberían ser accesibles, como usuarios, contraseñas, detalles sobre la propia aplicación, etc. Si el usuario de la base de datos tiene más derechos de los necesarios, es posible que pueda acceder a otras bases de datos o incluso ejecutar comandos del sistema. La causa principal de la inyección de código SQL (SQLi) es la validación incorrecta de los parámetros de entrada de la aplicación.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: Dado que las bases de datos SQL suelen contener datos sensibles, la pérdida de confidencialidad es un problema frecuente con las vulnerabilidades de inyección SQL.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si se utilizan comandos SQL deficientes para comprobar los nombres de usuario y las contraseñas, puede ser posible conectarse a un sistema como otro usuario sin conocer previamente la contraseña.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si la información de autorización se mantiene en una base de datos SQL, puede ser posible cambiar esta información a través de la explotación exitosa de una vulnerabilidad de inyección SQL.</p></li><li><p>Integridad: Modificación de datos de aplicación: Al igual que es posible leer información sensible, también es posible realizar cambios o incluso borrar esta información con un ataque de inyección SQL.</p></li></ul>",
                "remediation": "<p>Validar los parámetros que gestiona la aplicación, especialmente cuando el usuario los envía como datos de entrada. Esta validación se realiza siempre en el lado del servidor y nunca depende de validaciones en el lado del cliente.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection",
                    "https://owasp.org/www-community/attacks/Blind_SQL_Injection",
                    "https://cwe.mitre.org/data/definitions/89.html"
                ],
                "locale": "es",
                "title": "Inyección SQL basada en Unión en banda",
                "vulnType": "OWASP WSTG",
                "description": "<p>El ataque de inyección SQL (SQLi) intenta obtener información o incluso ejecutar comandos a través de esta vulnerabilidad interactuando de forma inesperada con la base de datos. Dado que en este caso se trata de una inyección sql ciega, la respuesta no proporciona directamente información al respecto; en su lugar, un atacante debe descifrar los mensajes de respuesta del servidor para obtener la información.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: Dado que las bases de datos SQL suelen contener datos sensibles, la pérdida de confidencialidad es un problema frecuente con las vulnerabilidades de inyección SQL.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si se utilizan comandos SQL deficientes para comprobar los nombres de usuario y las contraseñas, puede ser posible conectarse a un sistema como otro usuario sin conocer previamente la contraseña.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si la información de autorización se mantiene en una base de datos SQL, puede ser posible cambiar esta información a través de la explotación exitosa de una vulnerabilidad de inyección SQL.</p></li><li><p>Integridad: Modificación de datos de aplicación: Al igual que es posible leer información sensible, también es posible realizar cambios o incluso borrar esta información con un ataque de inyección SQL.</p></li></ul>",
                "remediation": "<p>Se recomienda desinfectar los parámetros de entrada de la aplicación para solucionar este problema, ya que de este modo se evita que los atacantes introduzcan caracteres que podrían cambiar la consulta SQL y permitir la recuperación de información.</p><p>La principal sugerencia es establecer un sistema de \"Lista Blanca\" en el que sólo se acepten las palabras y caracteres definidos en la lista y se ignore cualquier otro valor antes de utilizarlo en la base de datos. Si esta opción no es factible, se puede confeccionar una \"\"Lista Negra\"\" que evite los caracteres definidos utilizando caracteres vulnerables a este tipo de ataque, como % #'\"\"\"\"'\"\"\"\" () +, ;, y palabras clave de consulta SQL como \"select\", \"where\", \"union\", \"join\" y \"update\". Además, debe buscar cualquier variación de codificación para estos caracteres, como codificación URL, unicode/UTF-8 y hexadecimal.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection",
                    "https://cwe.mitre.org/data/definitions/89.html"
                ],
                "locale": "es",
                "title": "Inyección SQL basada en errores en banda",
                "vulnType": "OWASP WSTG",
                "description": "<p>Una interacción inesperada con la base de datos conocida como ataque de inyección SQL (SQLi) intenta obtener información o incluso ejecutar comandos utilizando este fallo. Dado que en este caso se trata de una inyección sql basada en errores, la respuesta no proporciona directamente información al respecto; en su lugar, un atacante debe interpretar los mensajes de error que proporciona el servidor para obtener la información.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: Dado que las bases de datos SQL suelen contener datos sensibles, la pérdida de confidencialidad es un problema frecuente con las vulnerabilidades de inyección SQL.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si se utilizan comandos SQL deficientes para comprobar los nombres de usuario y las contraseñas, puede ser posible conectarse a un sistema como otro usuario sin conocer previamente la contraseña.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si la información de autorización se mantiene en una base de datos SQL, puede ser posible cambiar esta información a través de la explotación exitosa de una vulnerabilidad de inyección SQL.</p></li><li><p>Integridad: Modificación de datos de aplicación: Al igual que es posible leer información sensible, también es posible realizar cambios o incluso borrar esta información con un ataque de inyección SQL.</p></li></ul>",
                "remediation": "<p>Se recomienda desinfectar los parámetros de entrada de la aplicación para solucionar este problema, ya que de este modo se evita que los atacantes introduzcan caracteres que podrían cambiar la consulta SQL y permitir la recuperación de información.</p><p>La principal sugerencia es establecer un sistema de \"Lista Blanca\" en el que sólo se acepten las palabras y caracteres definidos en la lista y se ignore cualquier otro valor antes de utilizarlo en la base de datos. Si esta opción no es factible, se puede confeccionar una \"\"Lista Negra\"\" que evite los caracteres definidos utilizando caracteres vulnerables a este tipo de ataque, como % #'\"\"\"\"'\"\"\"\" () +, ;, y palabras clave de consulta SQL como \"select\", \"where\", \"union\", \"join\" y \"update\". Además, debe buscar cualquier variación de codificación para estos caracteres, como codificación URL, unicode/UTF-8 y hexadecimal.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection",
                    "https://cwe.mitre.org/data/definitions/89.html"
                ],
                "locale": "es",
                "title": "Inyección SQL ciega basada en el tiempo",
                "vulnType": "OWASP WSTG",
                "description": "<p>El ataque de inyección SQL (SQLi) intenta obtener información o incluso ejecutar comandos a través de esta vulnerabilidad interactuando de forma inesperada con la base de datos. Dado que en este caso se trata de una inyección sql basada en el tiempo, la respuesta no proporciona directamente información al respecto, sino que un atacante debe interpretar los tiempos de respuesta del servidor para obtener la información necesaria.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: Dado que las bases de datos SQL suelen contener datos sensibles, la pérdida de confidencialidad es un problema frecuente con las vulnerabilidades de inyección SQL.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si se utilizan comandos SQL deficientes para comprobar los nombres de usuario y las contraseñas, puede ser posible conectarse a un sistema como otro usuario sin conocer previamente la contraseña.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si la información de autorización se mantiene en una base de datos SQL, puede ser posible cambiar esta información a través de la explotación exitosa de una vulnerabilidad de inyección SQL.</p></li><li><p>Integridad: Modificación de datos de aplicación: Al igual que es posible leer información sensible, también es posible realizar cambios o incluso borrar esta información con un ataque de inyección SQL.</p></li></ul>",
                "remediation": "<p>Se recomienda desinfectar los parámetros de entrada de la aplicación para solucionar este problema, ya que de este modo se evita que los atacantes introduzcan caracteres que podrían cambiar la consulta SQL y permitir la recuperación de información.</p><p>La principal sugerencia es establecer un sistema de \"Lista Blanca\" en el que sólo se acepten las palabras y caracteres definidos en la lista y se ignore cualquier otro valor antes de utilizarlo en la base de datos. Si esta opción no es viable, se puede confeccionar una \"\"Lista Negra\"\" que evite los caracteres definidos utilizando caracteres vulnerables a este tipo de ataque, como % #'\"\"\"\"'\"\"\"\" () +, ;, y palabras clave de consulta SQL como \"select\", \"where\", \"union\", \"join\" y \"update\". Además, debe buscar cualquier variación de codificación para estos caracteres, como codificación URL, unicode/UTF-8 y hexadecimal.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection",
                    "https://cwe.mitre.org/data/definitions/89.html"
                ],
                "locale": "es",
                "title": "Inyección SQL ciega basada en booleanos",
                "vulnType": "OWASP WSTG",
                "description": "<p>El atacante utiliza inyección SQL basada en booleanos para enviar consultas SQL a la base de datos, forzando a la aplicación a devolver un resultado diferente dependiendo de si la consulta devuelve verdadero o falso. El contenido de la respuesta HTTP puede cambiar o permanecer igual dependiendo del resultado. Incluso si no se devuelve ningún dato de la base de datos, esto permite a un atacante determinar si el resultado es verdadero o falso.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: Dado que las bases de datos SQL suelen contener datos sensibles, la pérdida de confidencialidad es un problema frecuente con las vulnerabilidades de inyección SQL.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si se utilizan comandos SQL deficientes para comprobar los nombres de usuario y las contraseñas, puede ser posible conectarse a un sistema como otro usuario sin conocer previamente la contraseña.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si la información de autorización se mantiene en una base de datos SQL, puede ser posible cambiar esta información a través de la explotación exitosa de una vulnerabilidad de inyección SQL.</p></li><li><p>Integridad: Modificación de datos de aplicación: Al igual que es posible leer información sensible, también es posible realizar cambios o incluso borrar esta información con un ataque de inyección SQL.</p></li></ul>",
                "remediation": "<p>Se recomienda desinfectar los parámetros de entrada de la aplicación para solucionar este problema, ya que de este modo se evita que los atacantes introduzcan caracteres que podrían cambiar la consulta SQL y permitir la recuperación de información.</p><p>La principal sugerencia es establecer un sistema de \"Lista Blanca\" en el que sólo se acepten las palabras y caracteres definidos en la lista y se ignore cualquier otro valor antes de utilizarlo en la base de datos. Si esta opción no es factible, se puede confeccionar una \"\"Lista Negra\"\" que evite los caracteres definidos utilizando caracteres vulnerables a este tipo de ataque, como % #'\"\"\"\"'\"\"\"\" () +, ;, y palabras clave de consulta SQL como \"select\", \"where\", \"union\", \"join\" y \"update\". Además, debe buscar cualquier variación de codificación para estos caracteres, como codificación URL, unicode/UTF-8 y hexadecimal.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection",
                    "https://cwe.mitre.org/data/definitions/89.html"
                ],
                "locale": "es",
                "title": "Inyección SQL fuera de banda",
                "vulnType": "OWASP WSTG",
                "description": "<p>La inyección SQL fuera de banda exfiltra datos a través del canal de salida, que puede ser el protocolo DNS o HTTP, a diferencia de la inyección SQL dentro de banda y ciega. Dependiendo de la función disponible, un sistema de base de datos puede o no iniciar una petición HTTP o DNS saliente. La función puede establecer una conexión (por ejemplo, DBMS LDAP.INIT, UTL HTTP.request) u operar sobre archivos (por ejemplo, load file(), master..xp dirtree). Los servidores web y de bases de datos objetivo deben cumplir los siguientes requisitos para poder explotar la inyección SQL OOB:</p><ul><li><p>La falta de validación de entrada de la aplicación web.</p></li><li><p>Un entorno de red que prescinda de perímetros de seguridad y permita al servidor de base de datos objetivo iniciar peticiones salientes (a través de DNS o HTTP) al público en general</p></li><li><p>Derechos suficientes para ejecutar la función necesaria para enviar la solicitud de salida</p></li></ul>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: Dado que las bases de datos SQL suelen contener datos sensibles, la pérdida de confidencialidad es un problema frecuente con las vulnerabilidades de inyección SQL.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si se utilizan comandos SQL deficientes para comprobar los nombres de usuario y las contraseñas, puede ser posible conectarse a un sistema como otro usuario sin conocer previamente la contraseña.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: Si la información de autorización se mantiene en una base de datos SQL, puede ser posible cambiar esta información a través de la explotación exitosa de una vulnerabilidad de inyección SQL.</p></li><li><p>Integridad: Modificación de datos de aplicación: Al igual que es posible leer información sensible, también es posible realizar cambios o incluso borrar esta información con un ataque de inyección SQL.</p></li></ul>",
                "remediation": "<ul><li><p>Validación de las entradas, tanto en el lado del cliente como en el del servidor.</p></li><li><p>Tratamiento correcto de los errores para evitar que se muestre información detallada sobre ellos.</p></li><li><p>Examinar las arquitecturas para la red y la seguridad.</p></li><li><p>Utilizar el menor privilegio posible al asignar la cuenta de base de datos a la aplicación.</p></li><li><p>El uso de medidas de seguridad adicionales como sistemas de prevención de intrusiones (IPS) y cortafuegos de aplicaciones web (WAF).</p></li><li><p>Vigilar constantemente las anomalías y disponer de procedimientos eficaces de respuesta a incidentes como red de controles de seguridad.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/06-Testing_for_LDAP_Injection",
                    "https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html",
                    "https://cwe.mitre.org/data/definitions/90.html"
                ],
                "locale": "es",
                "title": "Inyección LDAP",
                "vulnType": "OWASP WSTG",
                "description": "<p>La información sobre usuarios, hosts y muchos otros objetos se almacena utilizando el Protocolo Ligero de Acceso a Directorios (LDAP). Una inyección LDAP es un ataque del lado del servidor que puede revelar, modificar o insertar datos sensibles sobre usuarios y hosts representados en una estructura LDAP. Para ello, se modifican los parámetros de entrada que posteriormente se pasan a las funciones internas de búsqueda, adición y modificación.</p><p>Para permitir a los usuarios autenticarse o buscar información de otros usuarios dentro de una estructura corporativa, una aplicación web puede utilizar LDAP. Los ataques de inyección LDAP tienen como objetivo insertar metacaracteres de filtro de búsqueda LDAP en una consulta de aplicación que será ejecutada.</p>",
                "observation": "<ul><li><p>Integridad: Modificación de datos de aplicación: Un atacante podría incluir entradas que modifiquen la consulta LDAP, lo que permitiría la ejecución de comandos o código no deseados, la lectura o modificación de datos confidenciales u otros comportamientos no deseados.</p></li></ul>",
                "remediation": "<p>Asumir que todas las entradas son maliciosas. Utilizar una estrategia de validación de entradas \"aceptar lo bueno conocido\", es decir, utilizar una lista de entradas aceptables que se ajusten estrictamente a las especificaciones. Rechaza cualquier entrada que no se ajuste estrictamente a las especificaciones, o transfórmala en algo que sí lo haga.</p><p>A la hora de validar las entradas, hay que tener en cuenta todas las propiedades potencialmente relevantes, como la longitud, el tipo de entrada, la gama completa de valores aceptables, las entradas que faltan o sobran, la sintaxis, la coherencia entre campos relacionados y el cumplimiento de las reglas de negocio. Como ejemplo de lógica de reglas de negocio, \"barco\" puede ser sintácticamente válido porque sólo contiene caracteres alfanuméricos, pero no es válido si se espera que la entrada sólo contenga colores como \"rojo\" o \"azul\".</p><p>No confíe únicamente en la búsqueda de entradas maliciosas o malformadas. Es probable que se pase por alto al menos una entrada no deseada, especialmente si cambia el entorno del código. Esto puede dar a los atacantes suficiente margen para eludir la validación prevista. Sin embargo, las listas de denegación pueden ser útiles para detectar posibles ataques o determinar qué entradas están tan malformadas que deberían rechazarse directamente.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/611.html",
                    "https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing https://capec.mitre.org/data/definitions/201.html"
                ],
                "locale": "es",
                "title": "Tratamiento de entidades externas XML (XXE)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Algunas aplicaciones transmiten datos entre el navegador y el servidor utilizando el formato XML. Las aplicaciones que realizan esto casi siempre procesan los datos XML en el servidor utilizando una biblioteca estándar o una API de plataforma. Un ejemplo de entidad XML especial es aquella cuyos valores definidos se cargan desde fuentes distintas de la DTD en la que se declaran. Desde el punto de vista de la seguridad, las entidades externas son especialmente interesantes porque permiten definir una entidad basándose en el contenido de una ruta de archivo o URL.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de ficheros o directorios: Si el atacante es capaz de incluir un DTD crafteado y se habilita un resolvedor de entidades por defecto, el atacante puede ser capaz de acceder a archivos arbitrarios en el sistema.</p></li><li><p>Integridad: Bypass de mecanismo de protección: El DTD puede incluir peticiones HTTP arbitrarias que el servidor puede ejecutar. Esto podría dar lugar a otros ataques aprovechando la relación de confianza del servidor con otras entidades.</p></li><li><p>Disponibilidad: DoS: Consumo de recursos (Memoria): El software podría consumir excesivos ciclos de CPU o memoria utilizando un URI que apunte a un archivo grande, o a un dispositivo que siempre devuelva datos como /dev/random. Alternativamente, el URI podría hacer referencia a un archivo que contiene muchas referencias a entidades anidadas o recursivas para ralentizar aún más el análisis.</p></li></ul>",
                "remediation": "<p>Según la hoja de trucos de OWASP \"XXE Prevention\", desactive el procesamiento de entidades externas XML y DTD en todos los analizadores XML de la aplicación.Además, utilice la validación de entrada del lado del servidor, el filtrado o el saneamiento positivo (\"listas blancas\") para evitar datos hostiles en documentos XML, cabeceras o nodos.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/08-Testing_for_SSI_Injection",
                    "https://owasp.org/www-community/attacks/Server-Side_Includes_(SSI)_Injection#:~:text=The%20Server%2DSide%20Includes%20attack,use%20through%20user%20input%20fields.",
                    "- http://httpd.apache.org/docs/current/howto/ssi.html",
                    "https://cwe.mitre.org/data/definitions/96.html",
                    "https://cwe.mitre.org/data/definitions/116.html",
                    "https://cwe.mitre.org/data/definitions/159.html"
                ],
                "locale": "es",
                "title": "Inyección en el lado del servidor (SSI)",
                "vulnType": "OWASP WSTG",
                "description": "<p>SSI (Server-Side Includes) son directivas presentes en las aplicaciones web que se utilizan para alimentar una página HTML con contenido dinámico. Son similares a los CGI, salvo que los SSI se utilizan para ejecutar algunas acciones antes de que se cargue la página actual o mientras se está mostrando. Para ello, el servidor web analiza los SSI antes de servir la página al usuario.</p><p>El ataque de inyección SSI permite atacar una aplicación web inyectando scripts en páginas HTML o ejecutando código arbitrario de forma remota. Se puede explotar mediante la manipulación de las directivas SSI en uso en la aplicación o forzar su uso inyectando nuevas directivas a través de los campos de entrada del usuario.</p><p>Es posible comprobar si la aplicación está validando correctamente los datos en los campos de entrada mediante la inserción de caracteres que se utilizan en las directivas SSI, tales como:</p><p>¡&lt; ! # = / . \" - &gt; y [a-zA-Z0-9].</p><p>Otra forma de averiguar si la aplicación es potencialmente vulnerable es comprobar la presencia de páginas con extensiones .stm, .shtm y .shtml. Sin embargo, la ausencia de tales páginas no significa que la aplicación esté protegida contra ataques SSI.</p><p>En cualquier caso, el ataque sólo tendrá éxito si el servidor web permite que se ejecute SSI sin realizar antes la validación adecuada. Si esto ocurre, puede ser posible acceder y manipular archivos y procesos del sistema bajo el permiso del propietario del proceso del servidor web.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El código inyectado podría acceder a datos / archivos restringidos.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: En algunos casos, el código inyectable controla la autenticación; esto puede conducir a una vulnerabilidad remota.</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: El código inyectado puede acceder a recursos a los que el atacante está directamente impedido de acceder.</p></li><li><p>Otro: Ejecución no autorizada de código o comandos: Los ataques de inyección de código pueden conducir a la pérdida de la integridad de los datos en casi todos los casos, ya que los datos del plano de control inyectados son siempre incidentales a la recuperación o escritura de datos. Además, la inyección de código a menudo puede dar lugar a la ejecución de código arbitrario.</p></li><li><p>No repudio: Ocultación de actividades: A menudo, las acciones realizadas por el código de control inyectado no se registran.</p></li><li><p>Integridad: Modificación de datos de aplicación: Las comunicaciones entre componentes pueden modificarse de forma inesperada. Pueden ejecutarse comandos inesperados, eludiendo otros mecanismos de seguridad. Los datos entrantes pueden ser malinterpretados.</p></li></ul>",
                "remediation": "<p>Los datos controlables por el usuario no deben, siempre que sea posible, ser incrustados por las aplicaciones en páginas que se renderizan para directivas SSI. Por lo general, existen formas alternativas más seguras de implementar la funcionalidad necesaria. Si esto se considera poco práctico, los datos deben validarse rigurosamente. Lo ideal sería emplear una lista blanca de valores particulares aceptables. En su defecto, sólo se aceptarán cadenas alfanuméricas breves. Cualquier dato adicional, incluido cualquier metacarácter SSI potencial, debe excluirse de la entrada.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09-Testing_for_XPath_Injection",
                    "https://owasp.org/www-community/attacks/XPATH_Injection",
                    "https://cwe.mitre.org/data/definitions/94.html"
                ],
                "locale": "es",
                "title": "Inyección XPATH",
                "vulnType": "OWASP WSTG",
                "description": "<p>De forma similar a la inyección SQL, los ataques de inyección XPath tienen lugar cuando un sitio web construye una consulta XPath para datos XML utilizando datos suministrados por el usuario.XPath es un tipo de sentencia descriptiva directa que permite buscar en el XML una información específica. Se pueden especificar atributos concretos que buscar y patrones que hacer coincidir, igual que en SQL. Es práctica común aceptar algún tipo de entrada en la cadena de consulta cuando se utiliza XML para un sitio web, con el fin de identificar el contenido a encontrar y mostrar en la página. Estas consultas pueden modificarse para devolver más datos de los que deberían o incluso ejecutar código del lado del servidor si el atacante envía una cadena XPath maliciosa.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: En algunos casos, el código inyectable controla la autenticación; esto puede conducir a una vulnerabilidad remota.</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: El código inyectado puede acceder a recursos a los que el atacante está directamente impedido de acceder.</p></li><li><p>Otro: Ejecución no autorizada de código o comandos: Los ataques de inyección de código pueden conducir a la pérdida de la integridad de los datos en casi todos los casos, ya que los datos del plano de control inyectados son siempre incidentales a la recuperación o escritura de datos. Además, la inyección de código a menudo puede dar lugar a la ejecución de código arbitrario.</p></li><li><p>No repudio: Ocultación de actividades: A menudo, las acciones realizadas por el código de control inyectado no se registran.</p></li></ul>",
                "remediation": "<p>Antes de ser incluida en las consultas XPATH (XML), la entrada del usuario debe ser estrictamente validada. Se aconseja emplear una lista blanca que restrinja los caracteres o valores que la aplicación aceptará como entrada del usuario.</p><p>Si la lista blanca no es una opción, una alternativa menos preferida es emplear una lista negra que al menos elimine los caracteres \"\"'/ @ = * [] (y)</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/35.html",
                    "https://capec.mitre.org/data/definitions/126.html"
                ],
                "locale": "es",
                "title": "Manipulación de rutas de archivos",
                "vulnType": "OWASP WSTG",
                "description": "<p>Cuando se insertan datos controlables por el usuario en una ruta de archivo o URL que se utiliza en el servidor para acceder a recursos locales, que pueden estar ubicados dentro o fuera de la raíz web, se crean vulnerabilidades de manipulación de rutas de archivo. Si una ruta de archivo es vulnerable, un atacante puede cambiarla para acceder a diferentes recursos.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de ficheros o directorios: Un atacante podría leer datos confidenciales si es capaz de controlar las referencias a recursos.</p></li><li><p>Integridad: Modificación de ficheros o directorios: Un atacante podría modificar datos sensibles, ya sea escribiendo los datos directamente en un almacén de datos que no esté debidamente restringido, o accediendo a una funcionalidad privilegiada insuficientemente protegida para escribir los datos.</p></li></ul>",
                "remediation": "<p>Creer que todas las entradas son maliciosas Utilice una lista de entradas que se ajusten estrictamente a las especificaciones como parte de una estrategia de validación de entradas de \"aceptar lo bueno conocido\". Cualquier entrada que no cumpla estrictamente las especificaciones debe rechazarse o modificarse. Utilice listas blancas estrictas que restrinjan el conjunto de caracteres que puede utilizarse al validar nombres de archivo. Para evitar vulnerabilidades como la CWE-23, sólo se permite un único carácter \".\" en el nombre de archivo, y no se permiten separadores de directorio como \"/\".</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/73.html"
                ],
                "locale": "es",
                "title": "Control externo del nombre del archivo",
                "vulnType": "OWASP WSTG",
                "description": "<p>Debido a una vulnerabilidad, los nombres de archivo utilizados por el sistema de archivos pueden ser cambiados o controlados por la entrada del usuario. Un atacante puede crear un paquete que cambie la extensión descargable del archivo ZIP.</p>",
                "observation": "<ul><li><p>Integridad: Modificación de ficheros o directorios: La aplicación puede operar sobre archivos inesperados. Esto puede violar la integridad si se escribe en el nombre del archivo, o si el nombre del archivo es para un programa u otra forma de código ejecutable.</p></li><li><p>Disponibilidad: DoS: Crash, salida, o reinicio: consumo de recursos (otro): La aplicación puede operar sobre archivos inesperados. La disponibilidad puede verse afectada si el atacante especifica un archivo inesperado que la aplicación modifica. La disponibilidad también puede verse afectada si el atacante especifica un nombre de archivo para un archivo grande, o apunta a un dispositivo especial o a un archivo que no tiene el formato que la aplicación espera.</p></li></ul>",
                "remediation": "<p>Creer que todas las entradas son maliciosas Utilice una lista de entradas que se ajusten estrictamente a las especificaciones como parte de una estrategia de validación de entradas de \"aceptar lo bueno conocido\". Cualquier entrada que no cumpla estrictamente las especificaciones debe rechazarse o modificarse. Utilice listas blancas estrictas que restrinjan el conjunto de caracteres que puede utilizarse al validar nombres de archivo. Para evitar vulnerabilidades como la CWE-23, sólo se permite un único carácter \".\" en el nombre de archivo y se excluyen los separadores de directorio como \"/\".Creer que todas las entradas son maliciosas Utilice una lista de entradas que se ajusten estrictamente a las especificaciones como parte de una estrategia de validación de entradas de \"aceptar lo bueno conocido\". Cualquier entrada que no cumpla estrictamente las especificaciones debe rechazarse o modificarse. Utilizar listas blancas estrictas que restrinjan el conjunto de caracteres que puede utilizarse al validar nombres de archivo.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion",
                    "https://cwe.mitre.org/data/definitions/20.html",
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11-Testing_for_Code_Injection"
                ],
                "locale": "es",
                "title": "Ejecución remota de código (RCE) por inyección de archivos locales",
                "vulnType": "OWASP WSTG",
                "description": "<p>Utilizando los procedimientos de llamada a archivos vulnerables de la aplicación, la inclusión de archivos locales (LFI) es el proceso de incluir archivos que ya están en el servidor. Por ejemplo, cuando una página recibe una entrada que es la ruta a un archivo local, se manifiesta esta vulnerabilidad. Los caracteres que atraviesan el directorio pueden ser inyectados para acceder a otros archivos en el servidor si esta entrada no está correctamente desinfectada.</p>",
                "observation": "<ul><li><p>Control de acceso: Ejecución no autorizada de código o comandos: Esta debilidad puede llevar a la exposición de recursos o funcionalidades a actores no intencionados, posiblemente proporcionando a los atacantes información sensible o incluso ejecutar código arbitrario.</p></li></ul>",
                "remediation": "<p>La mejor manera de deshacerse de las vulnerabilidades de inclusión de archivos es no dar nunca a ninguna API del sistema de archivos/marco ninguna entrada de usuario. Si esto no es posible, la aplicación puede mantener una lista de archivos permitidos que la página puede incluir, y luego utilizar un número de índice u otro identificador para acceder al archivo deseado. Para que los usuarios malintencionados no puedan manipular la ruta, cualquier solicitud que contenga un identificador no válido debe ser rechazada. Se aconseja adherirse a las recomendaciones de la guía OWASP (https://cheatsheetseries.owasp.org/cheatsheets/File Upload Cheat Sheet.html) para buenas prácticas de remediación contra vulnerabilidades de inclusión de archivos.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion",
                    "https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html",
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "es",
                "title": "Ejecución remota de código (RCE)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Los ataques conocidos como ejecución remota de código (RCE) dan a un atacante la capacidad de ejecutar remotamente código malicioso en un ordenador. Una vulnerabilidad RCE puede dar lugar a la ejecución de malware o a la toma completa de una máquina comprometida por parte de un atacante.</p>",
                "observation": "<ul><li><p>Control de acceso: Ejecución no autorizada de código o comandos: Esta debilidad puede llevar a la exposición de recursos o funcionalidades a actores no intencionados, posiblemente proporcionando a los atacantes información sensible o incluso ejecutar código arbitrario.</p></li></ul>",
                "remediation": "<p>Restringir la fuente, ya sea una entrada o una ruta abierta que conduce a una aplicación, desde la que se accede al RCE.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion",
                    "https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html",
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "es",
                "title": "Ejecución remota de código (RCE) por inyección remota de archivos",
                "vulnType": "OWASP WSTG",
                "description": "<p>El proceso de incluir referencias a archivos remotos de otro servidor mediante el uso de procedimientos débiles de llamada a archivos que se implementaron en la aplicación se conoce como inclusión de archivos remotos (RFI). Este fallo, por ejemplo, aparece cuando una página descarga archivos de fuentes externas y luego los incluye en la aplicación. Es posible alterar el recurso para hacer la petición contra uno que esté controlado por un atacante si esa entrada no está correctamente desinfectada.</p>",
                "observation": "<ul><li><p>Control de acceso: Ejecución no autorizada de código o comandos: Esta debilidad puede llevar a la exposición de recursos o funcionalidades a actores no intencionados, posiblemente proporcionando a los atacantes información sensible o incluso ejecutar código arbitrario.</p></li></ul>",
                "remediation": "<p>La mejor manera de deshacerse de las vulnerabilidades de inclusión de archivos es no dar nunca a ninguna API del sistema de archivos/marco ninguna entrada de usuario. Si esto no es posible, la aplicación puede mantener una lista de archivos permitidos que la página puede incluir, y luego utilizar un número de índice u otro identificador para acceder al archivo deseado. Para que los usuarios malintencionados no puedan manipular la ruta, cualquier solicitud que contenga un identificador no válido debe ser rechazada. Se aconseja adherirse a las recomendaciones de la guía OWASP (https://cheatsheetseries.owasp.org/cheatsheets/File Upload Cheat Sheet.html) para buenas prácticas de remediación contra vulnerabilidades de inclusión de archivos.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/284.html"
                ],
                "locale": "es",
                "title": "Control de acceso inadecuado",
                "vulnType": "OWASP WSTG",
                "description": "<p>El software no restringe o restringe incorrectamente el acceso a un recurso de un actor no autorizado.El control de acceso implica el uso de varios mecanismos de protección como:</p><ul><li><p>Autenticación (probar la identidad de un actor)</p></li><li><p>Autorización (garantizar que un actor determinado puede acceder a un recurso)</p></li><li><p>Rendición de cuentas (seguimiento de las actividades realizadas)</p></li></ul><p>Si alguno de estos mecanismos no se aplica o falla, los atacantes pueden poner en peligro la seguridad del software al obtener privilegios, leer información sensible, ejecutar comandos, eludir la detección, etc.</p><p>Hay dos comportamientos distintos que pueden introducir debilidades en el control de acceso:</p><ul><li><p>Especificación: se especifican explícitamente privilegios, permisos, propiedad, etc. incorrectos para el usuario o el recurso (por ejemplo, establecer un archivo de contraseña para que se pueda escribir en todo el mundo, o dar capacidades de administrador a un usuario invitado). Esta acción puede ser realizada por el programa o por el administrador.</p></li><li><p>Aplicación: el mecanismo contiene errores que le impiden aplicar correctamente los requisitos de control de acceso especificados (por ejemplo, permitir que el usuario especifique sus propios privilegios, o permitir que una ACL sintácticamente incorrecta produzca configuraciones inseguras). Este problema se produce dentro del propio programa, en el sentido de que no aplica realmente la política de seguridad prevista que especifica el administrador.</p></li></ul>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: Se pueden eludir las comprobaciones de control de acceso a datos o funciones específicas del usuario.</p></li></ul>",
                "remediation": "<p>Arquitectura y diseño</p><ul><li><p>Gestione con sumo cuidado el establecimiento, la gestión y el manejo de los privilegios. Gestionar explícitamente las zonas de confianza en el software.</p></li><li><p>Compartimentar el sistema para disponer de zonas \"seguras\" en las que los límites de confianza puedan trazarse de forma inequívoca. No permita que los datos sensibles salgan de los límites de confianza y tenga siempre cuidado al interactuar con un compartimento fuera de la zona segura.</p></li><li><p>Asegúrese de que la compartimentación adecuada está integrada en el diseño del sistema y que la compartimentación sirve para permitir y reforzar aún más la funcionalidad de separación de privilegios. Los arquitectos y diseñadores deben basarse en el principio del mínimo privilegio para decidir cuándo es apropiado utilizar y abandonar los privilegios del sistema.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/284.html"
                ],
                "locale": "es",
                "title": "Ejecución remota de código (RCE) mediante un control de acceso inadecuado",
                "vulnType": "OWASP WSTG",
                "description": "<p>El hecho de que el software no imponga controles de acceso a un objeto web se denomina vulnerabilidad de control de acceso inadecuado. Al acceder al servicio web, un usuario malintencionado puede comprometer la seguridad del software y realizar determinadas acciones no aprobadas.</p>",
                "observation": "<ul><li><p>Otro: Varía según el contexto: Un atacante puede acceder a cualquier funcionalidad que sea inadvertidamente accesible a la fuente.</p></li></ul>",
                "remediation": "<p>No permita que usuarios anónimos accedan a este sitio web.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection",
                    "https://portswigger.net/web-security/os-command-injection",
                    "https://cwe.mitre.org/data/definitions/77.html",
                    "https://cwe.mitre.org/data/definitions/78.html"
                ],
                "locale": "es",
                "title": "Inyección de comandos",
                "vulnType": "OWASP WSTG",
                "description": "<p>Las vulnerabilidades de inyección de comandos suelen producirse cuando:</p><ol><li><p>Los datos entran en la app desde una fuente que no es de confianza.</p></li><li><p>Los datos forman parte de una cadena que es ejecutada como un comando por la aplicación.</p></li><li><p>Al ejecutar el comando, la aplicación otorga a un atacante un privilegio o capacidad que no tendría de otro modo.</p></li></ol><p>Muchos protocolos y productos tienen su propio lenguaje de comandos personalizado. Mientras que las cadenas de comandos del shell o del sistema operativo se descubren y atacan con frecuencia, es posible que los desarrolladores no se den cuenta de que estos otros lenguajes de comandos también pueden ser vulnerables a los ataques.</p>",
                "observation": "<ul><li><p>Integridad: Ejecución no autorizada de código o comandos: Si un usuario malintencionado inyecta un carácter (como un punto y coma) que delimita el final de un comando y el comienzo de otro, puede ser posible insertar un comando completamente nuevo y no relacionado que no estaba previsto que se ejecutara.</p></li><li><p>Confidencialidad: Lectura de datos de aplicación: El código inyectado podría acceder a datos / archivos restringidos.</p></li><li><p>Control de acceso: Bypass de mecanismo de protección: En algunos casos, el código inyectable controla la autenticación; esto puede conducir a una vulnerabilidad remota.</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: El código inyectado puede acceder a recursos a los que el atacante está directamente impedido de acceder.</p></li><li><p>Otro: Ejecución no autorizada de código o comandos: Los ataques de inyección de código pueden conducir a la pérdida de la integridad de los datos en casi todos los casos, ya que los datos del plano de control inyectados son siempre incidentales a la recuperación o escritura de datos. Además, la inyección de código a menudo puede dar lugar a la ejecución de código arbitrario.</p></li><li><p>No repudio: Ocultación de actividades: A menudo, las acciones realizadas por el código de control inyectado no se registran.</p></li></ul>",
                "remediation": "<p>Se recomienda limitar al máximo las capacidades del usuario a la hora de permitirle ejecutar comandos específicos en el servidor y valorar y evaluar, en primera instancia, si es absolutamente necesario que el usuario pueda realizar este tipo de acciones, ya que conllevan un peligro potencial inherente.</p><p>Sería conveniente restringir estas capacidades dado que muchos lenguajes llevan incorporadas funciones para ejecutar comandos en el ordenador, como la función system() en PHP, y que es posible restringir las capacidades del intérprete que ejecuta la aplicación (como en el caso de PHP).</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection",
                    "https://cwe.mitre.org/data/definitions/644.html"
                ],
                "locale": "es",
                "title": "Inyección de comandos en las cabeceras HTTP Host.",
                "vulnType": "OWASP WSTG",
                "description": "<p>Un servidor web suele alojar varias aplicaciones web en la misma dirección IP, haciendo referencia a cada aplicación a través del host virtual. En una solicitud HTTP entrante, los servidores web suelen enviar la solicitud al host virtual de destino basándose en el valor suministrado en el encabezado Host. Sin una validación adecuada del valor del encabezado, el atacante puede suministrar datos no válidos para hacer que el servidor web:</p><ul><li><p>Envíe las peticiones al primer host virtual de la lista.</p></li><li><p>Provocar una redirección a un dominio controlado por el atacante.</p></li><li><p>Envenene la caché web.</p></li><li><p>Manipular la funcionalidad de restablecimiento de contraseña.</p></li></ul>",
                "observation": "<ul><li><p>Control de acceso: Ejecución no autorizada de código o comandos: Esta debilidad puede llevar a la exposición de recursos o funcionalidades a actores no intencionados, posiblemente proporcionando a los atacantes información sensible o incluso ejecutar código arbitrario.</p></li></ul>",
                "remediation": "<p>Para filtrar, escapar o codificar datos no seguros enviados desde el servidor en una cabecera de respuesta HTTP, realice la validación de salida.</p><p>Deshabilite la capacidad del navegador del cliente para ejecutar scripts.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-side_Template_Injection",
                    "https://cwe.mitre.org/data/definitions/94.html",
                    "https://portswigger.net/research/server-side-template-injection"
                ],
                "locale": "es",
                "title": "Inyección de plantillas en el servidor (SSTI)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Cuando un usuario solicita una vista HTML, las aplicaciones modernas la generan utilizando un motor de plantillas (también conocido como \"templates\"). Las funciones integradas del lenguaje de programación en estos motores de plantillas permiten ejecutar funciones de riesgo e incluso código en el servidor que aloja la aplicación. Es posible utilizar esas funciones para ejecutar código en el servidor si un usuario malintencionado puede inyectar directivas de plantilla, y éstas son luego renderizadas por el motor de plantillas.</p>",
                "observation": "<ul><li><p>Control de acceso: Bypass de mecanismo de protección: En algunos casos, el código inyectable controla la autenticación; esto puede conducir a una vulnerabilidad remota.</p></li><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: El código inyectado puede acceder a recursos a los que el atacante está directamente impedido de acceder.</p></li><li><p>Otro: Ejecución no autorizada de código o comandos: Los ataques de inyección de código pueden conducir a la pérdida de la integridad de los datos en casi todos los casos, ya que los datos del plano de control inyectados son siempre incidentales a la recuperación o escritura de datos. Además, la inyección de código a menudo puede dar lugar a la ejecución de código arbitrario.</p></li><li><p>No repudio: Ocultación de actividades: A menudo, las acciones realizadas por el código de control inyectado no se registran.</p></li></ul>",
                "remediation": "<p>Asegúrese de que no está pasando variables controlables por el usuario a las funciones que renderizan las plantillas. Sanitizar la entrada es crucial en el caso de que sea necesario para evitar que se interpreten caracteres.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/19-Testing_for_Server-Side_Request_Forgery",
                    "https://cwe.mitre.org/data/definitions/918.html"
                ],
                "locale": "es",
                "title": "Falsificación de peticiones del lado del servidor (SSRF)",
                "vulnType": "OWASP WSTG",
                "description": "<p>La vulnerabilidad SSRF (Server-Side Request Forgery) surge cuando es posible dirigir al servidor para que envíe una petición a cualquier dominio utilizando los datos de entrada del usuario. Cuando el usuario que realiza la petición no recibe la respuesta del servidor, esta vulnerabilidad puede volverse \"ciega\". En este caso no se proporciona tal respuesta. Sin embargo, basándose en el tiempo de respuesta del servidor, se puede llevar a cabo una enumeración de las máquinas cercanas en la red.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El código inyectado podría acceder a datos / archivos restringidos.</p></li><li><p>Integridad: Ejecución no autorizada de código o comandos: El atacante puede ser capaz de crear o sobrescribir archivos críticos que se utilizan para ejecutar código, como programas o bibliotecas.</p></li></ul>",
                "remediation": "<p>Poner en la lista blanca las entradas permitidas por ese parámetro es la mitigación apropiada para esta vulnerabilidad. En otras palabras, sólo acepte las rutas a los recursos a los que realmente necesita acceder porque, a partir de ahora, hacer lo contrario le da acceso al usuario www-data a cualquier área del sistema de permisos donde pueda leer.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "es",
                "title": "Esquema de validación JSON",
                "vulnType": "OWASP WSTG",
                "description": "<p>Un vocabulario llamado JSON Schema permite anotar y validar documentos JSON.</p><p>Usted tiene un mejor control sobre los tipos de entrada de usuario que se pueden suministrar en su aplicación al añadir esquemas a sus archivos JSON.Cuando se hace correctamente, esto reduce drásticamente el vector de un atacante.</p><p>Sin embargo, como línea de defensa adicional, siempre deberías aplicar tu propia validación y rechazo de entradas. Esta estrategia también es preferible porque también quieres contrarrestar y registrar las peticiones y entradas de los usuarios.</p>",
                "observation": "<ul><li><p>Disponibilidad: DoS: Consumo de recursos (Memoria): Un atacante podría proporcionar valores inesperados y provocar un bloqueo del programa o un consumo excesivo de recursos, como memoria y CPU.</p></li><li><p>Confidencialidad: Lectura de ficheros o directorios: Un atacante podría leer datos confidenciales si es capaz de controlar las referencias a recursos.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: Un atacante podría utilizar una entrada maliciosa para modificar datos o posiblemente alterar el flujo de control de formas inesperadas, incluida la ejecución arbitraria de comandos.</p></li></ul>",
                "remediation": "<p>Para garantizar una solicitud JSON con el formato adecuado, confirme que se produce la validación del esquema JSON. A continuación, valide cada campo de entrada antes de procesar los datos.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "es",
                "title": "Esquema XML (XSD)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Usted tiene un mejor control sobre el tipo de entrada de usuario que se puede proporcionar en su aplicación al añadir esquemas a sus archivos XML. Cuando se hace correctamente, esto reduce drásticamente el vector de un atacante. Sin embargo, como línea de defensa adicional, siempre deberías aplicar tu propia validación y rechazo de entradas. Esta estrategia también es preferible porque también quieres contrarrestar y registrar las peticiones y entradas de los usuarios.</p>",
                "observation": "<ul><li><p>Disponibilidad: DoS: Consumo de recursos (Memoria): Un atacante podría proporcionar valores inesperados y provocar un bloqueo del programa o un consumo excesivo de recursos, como memoria y CPU.</p></li><li><p>Confidencialidad: Lectura de ficheros o directorios: Un atacante podría leer datos confidenciales si es capaz de controlar las referencias a recursos.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: Un atacante podría utilizar una entrada maliciosa para modificar datos o posiblemente alterar el flujo de control de formas inesperadas, incluida la ejecución arbitraria de comandos.</p></li></ul>",
                "remediation": "<p>Compruebe que el esquema XSD está validado para garantizar que el documento XML tiene el formato correcto y, a continuación, valide cada campo de entrada antes de procesar los datos.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "es",
                "title": "Verificar que los datos estructurados están fuertemente tipados y validados.",
                "vulnType": "OWASP WSTG",
                "description": "<p>Cuando los datos estructurados están estrechamente tipificados y se comprueban con respecto a un esquema especificado, se puede crear una aplicación proactiva defendible. Al utilizar los esquemas definidos, la aplicación puede ahora medir todo lo que está fuera de su funcionamiento previsto y debe utilizarse para rechazar la entrada si las comprobaciones del esquema devuelven falso.</p>",
                "observation": "<ul><li><p>Disponibilidad: DoS: Consumo de recursos (Memoria): Un atacante podría proporcionar valores inesperados y provocar un bloqueo del programa o un consumo excesivo de recursos, como memoria y CPU.</p></li><li><p>Confidencialidad: Lectura de ficheros o directorios: Un atacante podría leer datos confidenciales si es capaz de controlar las referencias a recursos.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: Un atacante podría utilizar una entrada maliciosa para modificar datos o posiblemente alterar el flujo de control de formas inesperadas, incluida la ejecución arbitraria de comandos.</p></li></ul>",
                "remediation": "<p>Compruebe que los datos estructurados están fuertemente tipificados y validados con respecto a un esquema definido, incluidos los caracteres permitidos, la longitud y el patrón (por ejemplo, números de tarjetas de crédito o números de teléfono, o validar que dos campos relacionados son lógicos, como validar que los suburbios y los códigos postales o postales coinciden).</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Error handling",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling"
                ],
                "locale": "es",
                "title": "Revelación de información sensible debido a una gestión inadecuada de los errores de aplicación.",
                "vulnType": "OWASP WSTG",
                "description": "<p>Los errores verbosos que no se controlan adecuadamente suelen dar lugar a respuestas que informan al usuario de la arquitectura interna de la aplicación. Las versiones del software instalado o la información de la base de datos son algunos ejemplos de los datos que pueden recuperarse de este modo.</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El atacante obtiene información de una respuesta de mensaje de error</p></li></ul>",
                "remediation": "<p>Para evitar que la aplicación muestre información sensible de su infraestructura o base de datos, implemente un sistema adecuado de redirecciones a páginas seguras o textos genéricos en la respuesta.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
        "category": "Functionality/Business Logic",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/06-Testing_for_the_Circumvention_of_Work_Flows"
                ],
                "locale": "es",
                "title": "Abuso del flujo de trabajo lógico de la aplicación.",
                "vulnType": "OWASP WSTG",
                "description": "<p>Las vulnerabilidades de flujo de trabajo implican cualquier tipo de vulnerabilidad que permita a un atacante hacer un mal uso de una aplicación/sistema de forma que le permita eludir (no seguir) el flujo de trabajo diseñado/previsto.</p><p>Definición de flujo de trabajo en Wikipedia:</p><p>Un flujo de trabajo consiste en una secuencia de pasos conectados en la que cada paso sigue sin demora o brecha, terminando justo antes de que el siguiente paso pueda comenzar. Es una representación de una secuencia de operaciones, enunciada como el trabajo de una persona o grupo, una organización de personal, o uno o más mecanismos simples o complejos. El flujo de trabajo puede considerarse una abstracción del trabajo real.</p><p>La lógica de negocio de la aplicación debe requerir que el usuario complete pasos específicos en el orden correcto/específico y si el flujo de trabajo se termina sin completarlo con éxito, todas las acciones y acciones generadas son \"\"revertidas\"\" o abortadas. Las vulnerabilidades relacionadas con la elusión de la lógica empresarial correcta por parte del flujo de trabajo son únicas en el sentido de que son muy específicas de la aplicación/sistema y deben desarrollarse casos de abuso manuales y cuidadosos utilizando los requisitos. y casos de uso.</p><p>El proceso de negocio de las aplicaciones debe tener comprobaciones para asegurar que las transacciones/acciones del usuario proceden en el orden correcto/aceptable y si una transacción desencadena algún tipo de acción, esa acción será \"\"revertida\"\" y anulada si la transacción no se completa con éxito.</p>",
                "observation": "<ul><li><p>Otro: Alteración de la lógica de la ejecución: Un atacante podría hacer que el software se saltara pasos críticos o los realizara en el orden equivocado, saltándose la lógica de negocio prevista. Esto a veces puede tener implicaciones de seguridad.</p></li></ul>",
                "remediation": "<p>La aplicación necesita controles que garanticen que los usuarios completan cada paso del flujo de trabajo en el orden correcto e impidan que los atacantes se salten, omitan o repitan cualquier paso o proceso del flujo de trabajo. También debe ser consciente de sí misma. Crear casos de abuso o mal uso de la lógica de negocio con el objetivo de completar con éxito el proceso de negocio mientras no se completan los pasos correctos en el orden correcto es la forma en que se realizan las pruebas de vulnerabilidades del flujo de trabajo.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Functionality/Business Logic",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/09-Test_Upload_of_Malicious_Files.html",
                    "https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html"
                ],
                "locale": "es",
                "title": "Validación insegura en la función de carga de archivos",
                "vulnType": "OWASP WSTG",
                "description": "<p>Muchas aplicaciones permiten a los usuarios cargar datos en sus procesos empresariales. Aunque la validación de entrada para campos de entrada basados en texto se entiende ampliamente, la aceptación de archivos hace que sea más difícil de implementar. A pesar de que muchos sitios web utilizan restricciones directas basadas en una lista de extensiones permitidas (o bloqueadas), esto es insuficiente para impedir que los atacantes carguen tipos de archivos seguros con contenido malicioso.</p>",
                "observation": "<ul><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: La ejecución arbitraria de código es posible si un archivo subido es interpretado y ejecutado como código por el destinatario. Esto es especialmente cierto en el caso de las extensiones .asp y .php cargadas en servidores web, ya que estos tipos de archivos suelen tratarse como ejecutables automáticamente, incluso cuando los permisos del sistema de archivos no especifican la ejecución. Por ejemplo, en entornos Unix, los programas normalmente no pueden ejecutarse a menos que el bit de ejecución esté activado, pero los programas PHP pueden ser ejecutados por el servidor web sin invocarlos directamente en el sistema operativo.</p></li></ul>",
                "remediation": "<p>Controle adecuadamente los tipos de archivos que se envían a la aplicación. Examine el tipo de archivo, prestando atención tanto a la extensión como al contenido.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Functionality/Business Logic",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/01-Test_Business_Logic_Data_Validation",
                    "https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html",
                    "https://cwe.mitre.org/data/definitions/502.html"
                ],
                "locale": "es",
                "title": "Deserialización insegura",
                "vulnType": "OWASP WSTG",
                "description": "<p>A menudo es conveniente serializar objetos para la comunicación o para guardarlos para su uso posterior. Sin embargo, el código o los datos deserializados a menudo pueden modificarse sin utilizar las funciones de acceso proporcionadas si no utilizan criptografía para protegerse. Además, cualquier criptografía seguiría siendo seguridad del lado del cliente, lo cual es una suposición de seguridad peligrosa.</p><p>No se puede confiar en que los datos no fiables estén bien formados. Cuando los desarrolladores no ponen restricciones en las \"\"cadenas de gadgets\"\", o series de instancias e invocaciones de métodos que pueden auto-ejecutarse durante el proceso de deserialización (es decir, antes de que el objeto sea devuelto al llamante), a veces pueden ser explotadas por atacantes para realizar acciones no autorizadas, como generar un shell.</p><p>Serialización y deserialización se refieren al proceso de tomar los datos relacionados con el objeto interno del programa, empaquetarlos de una manera que permita que los datos sean almacenados o transferidos externamente (\"\"serialización\"\"), y luego extraer los datos serializados para reconstruir el objeto. original (\"\"deserialización\"\").</p>",
                "observation": "<ul><li><p>Integridad: Estado inesperado: Los atacantes pueden modificar objetos inesperados o datos que se suponía que estaban a salvo de modificaciones.</p></li><li><p>Disponibilidad: DoS: Consumo de recursos (CPU): Si una función está haciendo una suposición sobre cuándo terminar, basándose en un centinela en una cadena, podría fácilmente no terminar nunca.</p></li><li><p>Otro: Varía según el contexto: Las consecuencias pueden variar mucho, porque depende de qué objetos o métodos se están de-serializando, y cómo se utilizan. Asumir que el código en el objeto de-serializado es válido es peligroso y puede permitir la explotación.</p></li></ul>",
                "remediation": "<p>A continuación se describen posibles mitigaciones para las distintas fases del proceso de creación de la aplicación:</p><ul><li><p>Fases: Arquitectura y diseño; implementación. Si está disponible, utilice las funciones de firma/sellado del lenguaje de programación para garantizar que los datos deserializados no han sido contaminados. Por ejemplo, podría utilizarse un código de autenticación de mensajes basado en hash (HMAC) para garantizar que los datos no han sido modificados.</p></li><li><p>Fase: Implementación. Cuando se deserializan datos, se recomienda rellenar un nuevo objeto en lugar de simplemente deserializar. El resultado es que los datos pasan por una validación de entrada segura y las funciones son seguras.</p></li><li><p>Fase: Implementación. Definir explícitamente un objeto final() para evitar la deserialización.</p></li><li><p>Fases: Arquitectura y Diseño; Implementación. Hacer transitorios los campos para protegerlos de la deserialización. Un intento de serializar y luego deserializar una clase que contenga campos transitorios resultará en NULLs donde deberían estar los datos transitorios. Esta es una gran manera de prevenir que variables temporales, de entorno o sensibles sean transferidas y mal utilizadas.</p></li><li><p>Fase: Implementación. Evite tener disponibles tipos o gadgets innecesarios que puedan ser explotados con fines maliciosos. Esto limita la posibilidad de que tipos y gadgets no deseados o no autorizados sean explotados por el atacante. Añada sólo clases aceptables a una lista de permitidos. Nota: Constantemente se descubren nuevos gadgets, por lo que esto por sí solo no es una mitigación suficiente.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Web client side",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/601.html",
                    "https://portswigger.net/kb/issues/00500100_open-redirection-reflected"
                ],
                "locale": "es",
                "title": "Redirección de URL del lado del cliente (redirección abierta)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Una vulnerabilidad conocida como Open Redirect se produce cuando un programa incorpora inadvertidamente datos controlables por el usuario en el destino de una redirección. Dentro de la aplicación, un atacante puede crear una URL que dirija el tráfico a cualquier dominio externo.</p>",
                "observation": "<ul><li><p>Control de acceso: Obtención de privilegios o suplantación de identidad: El usuario puede ser redirigido a una página que no es de confianza y que contiene malware que puede comprometer la máquina del usuario. Esto expondrá al usuario a un gran riesgo y la interacción del usuario con el servidor web también puede verse comprometida si el malware realiza keylogging u otros ataques que roben credenciales, información de identificación personal (PII) u otros datos importantes.</p></li><li><p>Otro: Otros: El usuario puede ser objeto de ataques de phishing al ser redirigido a una página que no es de confianza. El ataque de phishing puede apuntar a una página web controlada por un atacante que aparenta ser un sitio web de confianza. Los phishers pueden robar las credenciales del usuario y utilizarlas para acceder al sitio web legítimo.</p></li></ul>",
                "remediation": "<p>Deshabilitando la función de redirección o manteniendo una lista del lado del servidor de todas las URL a las que se permite redirigir, las aplicaciones deberían, siempre que sea posible, evitar incorporar datos controlables por el usuario en los objetivos de redirección.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Web client side",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/03-Testing_for_HTML_Injection",
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "es",
                "title": "Inyección de contenido HTML",
                "vulnType": "OWASP WSTG",
                "description": "<p>Las inyecciones HTML permiten inyectar código HTML en el lado del cliente que el navegador de la víctima interpretará cuando visite una URL. Es posible alterar el DOM y, en algunas circunstancias, inyectar código JavaScript para ayudar a robar datos del navegador de la víctima.</p>",
                "observation": "<ul><li><p>Disponibilidad: DoS: Consumo de recursos (Memoria): Un atacante podría proporcionar valores inesperados y provocar un bloqueo del programa o un consumo excesivo de recursos, como memoria y CPU.</p></li><li><p>Confidencialidad: Lectura de ficheros o directorios: Un atacante podría leer datos confidenciales si es capaz de controlar las referencias a recursos.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: Un atacante podría utilizar una entrada maliciosa para modificar datos o posiblemente alterar el flujo de control de formas inesperadas, incluida la ejecución arbitraria de comandos.</p></li></ul>",
                "remediation": "<p>Este tipo de ataque puede detenerse saneando adecuadamente la entrada del usuario o validando correctamente los contenidos que el servidor recibe y envía.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Web client side",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/05-Testing_for_CSS_Injection",
                    "https://research.securitum.com/css-data-exfiltration-in-firefox-via-single-injection-point/",
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "es",
                "title": "Inyección de contenido CSS",
                "vulnType": "OWASP WSTG",
                "description": "<p>De forma similar a cómo funcionan las inyecciones HTML o XSS, las inyecciones CSS ofrecen a los hackers la posibilidad de insertar código CSS en el lado del cliente, que el navegador de la víctima interpretará cuando visite una URL. Se ha demostrado que es posible exfiltrar datos del DOM utilizando únicamente CSS, a pesar de que CSS no tiene el mismo potencial que HTML o JavaScript y sólo es capaz de exportar estilos.</p>",
                "observation": "<ul><li><p>Disponibilidad: DoS: Consumo de recursos (Memoria): Un atacante podría proporcionar valores inesperados y provocar un bloqueo del programa o un consumo excesivo de recursos, como memoria y CPU.</p></li><li><p>Confidencialidad: Lectura de ficheros o directorios: Un atacante podría leer datos confidenciales si es capaz de controlar las referencias a recursos.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: Un atacante podría utilizar una entrada maliciosa para modificar datos o posiblemente alterar el flujo de control de formas inesperadas, incluida la ejecución arbitraria de comandos.</p></li></ul>",
                "remediation": "<p>Este tipo de ataque puede detenerse validando adecuadamente los contenidos que el servidor recibe y envía, o saneando correctamente la entrada del usuario.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Web client side",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/01-Testing_for_DOM-based_Cross_Site_Scripting",
                    "https://cwe.mitre.org/data/definitions/79.html"
                ],
                "locale": "es",
                "title": "Cross-Site Scripting (XSS) basado en DOM",
                "vulnType": "OWASP WSTG",
                "description": "<p>Un ataque XSS conocido como XSS basado en DOM hace que el código del lado del cliente se ejecute de forma \"inesperada\" al alterar el \"entorno\" DOM que el navegador de la víctima fue diseñado para utilizar por el script original del lado del cliente. Como resultado de los cambios maliciosos realizados en el entorno DOM, el código del lado del cliente contenido en la página se ejecuta de forma diferente aunque la página en sí (es decir, la respuesta HTTP) siga siendo la misma.</p><p>Otros ataques XSS (almacenados o reflejados), por el contrario, colocan la carga útil del ataque en la página de respuesta (debido a un fallo del lado del servidor).</p>",
                "observation": "<ul><li><p>Confidencialidad: Lectura de datos de aplicación: El ataque más común realizado con cross-site scripting implica la divulgación de información almacenada en las cookies del usuario. Normalmente, un usuario malintencionado elabora un script del lado del cliente que, cuando es analizado por un navegador web, realiza alguna actividad (como enviar todas las cookies del sitio a una dirección de correo electrónico determinada). Este script será cargado y ejecutado por cada usuario que visite el sitio web. Dado que el sitio que solicita ejecutar el script tiene acceso a las cookies en cuestión, el script malicioso también lo tiene.</p></li><li><p>Disponibilidad: Ejecución no autorizada de código o comandos: En algunas circunstancias puede ser posible ejecutar código arbitrario en el ordenador de una víctima cuando el cross-site scripting se combina con otros fallos.</p></li><li><p>Control de acceso: Lectura de datos de aplicación: La consecuencia de un ataque XSS es la misma independientemente de si se almacena o se refleja. La diferencia está en cómo llega la carga útil al servidor. XSS puede causar una variedad de problemas para el usuario final que varían en gravedad desde una molestia hasta el compromiso completo de la cuenta. Algunas vulnerabilidades de cross-site scripting pueden ser explotadas para manipular o robar cookies, crear peticiones que pueden ser confundidas con las de un usuario válido, comprometer información confidencial, o ejecutar código malicioso en los sistemas del usuario final para una variedad de propósitos nefastos. Otros ataques dañinos incluyen la divulgación de archivos del usuario final, la instalación de programas troyanos, la redirección del usuario a otra página o sitio, la ejecución de controles \"Active X\" (bajo Microsoft Internet Explorer) desde sitios que el usuario percibe como fiables y la modificación de la presentación del contenido.</p></li></ul>",
                "remediation": "<p>No existe una única acción que pueda eliminar por completo la amenaza de los ataques basados en DOM. En términos generales, sin embargo, la forma más eficaz de prevenir las vulnerabilidades basadas en DOM es evitar que los datos de cualquier fuente no confiable alteren dinámicamente el valor que se pasa a cualquier receptor.</p><p>Si la funcionalidad deseada de la aplicación significa que este comportamiento es inevitable, entonces las defensas deben ser implementadas dentro del código del lado del cliente. En muchos casos, los datos relevantes pueden ser validados contra una lista blanca, permitiendo sólo el contenido que se sabe que es seguro. En otros casos, será necesario desinfectar o cifrar los datos. Esto puede ser una tarea compleja y, dependiendo del contexto en el que se vayan a insertar los datos, puede implicar una combinación de escape de JavaScript, codificación HTML y codificación URL, en la secuencia apropiada.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Web client side",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/07-Testing_Cross_Origin_Resource_Sharing",
                    "https://cwe.mitre.org/data/definitions/942.html",
                    "https://developer.mozilla.org/es/docs/Web/HTTP/CORS",
                    "https://stackoverflow.com/questions/1653308/access-control-allow-origin-multiple-origin-domains"
                ],
                "locale": "es",
                "title": "Error de configuración en la compartición de recursos entre orígenes (CORS)",
                "vulnType": "OWASP WSTG",
                "description": "<p>CORS son las siglas de Cross-Origin Resource Sharing. Es una característica que ofrece la posibilidad de:- Una aplicación web exponga recursos a todos los dominios o a dominios restringidos.- Que un cliente web realice una petición AJAX de un recurso en un dominio distinto al de origen.Una política CORS no restrictiva puede ser abusada de varias maneras que pueden poner en riesgo la confidencialidad, disponibilidad e integridad de la información del usuario.</p>",
                "observation": "<ul><li><p>Otro: Varía según el contexto: Un atacante puede acceder a cualquier funcionalidad que sea inadvertidamente accesible a la fuente.</p></li></ul>",
                "remediation": "<p>Permitir sólo los dominios o subdominios de confianza en los que la aplicación debe confiar en el encabezado Access-Control-Allow-Origin.</p>"
            }
        ]
    }
]