Está en la página 1de 5

1. Ausencia de cabeceras HTTP seguras.

(CWE-16)
Describe los encabezados de respuesta HTTP que su aplicación puede usar para aumentar
la seguridad de su aplicación. Una vez configurados, estos encabezados de respuesta HTTP
pueden impedir que los navegadores modernos se encuentren con vulnerabilidades
fácilmente evitables.
El procedimiento a ejecutar hace referencia a la inclusión de cabeceras de respuesta HTTP
en las cuales se configuran distintos parámetros que permiten controlar que las
aplicaciones sean más seguras y versátiles.
Puntualmente, para IIS dichos parámetros se configuran de acuerdo con el siguiente
documento oficial de Microsoft: https://docs.microsoft.com/en-us/troubleshoot/iis/add-
http-response-header-web-site
Se hará la configuración puntual de los parámetros necesarios de acuerdo con la
vulnerabilidad reportada y basados en el informe presentado: https://owasp.org/www-
project-secure-headers/

2. Divulgación de Información. (CWE-200)


Esta vulnerabilidad podría ser el resultado de numerosos tipos de problemas que implican
la exposición de información sensible. La información se considera sensible cuando:

 Es sensible dentro de la funcionalidad del producto (por ejemplo, información con


acceso restringido, mensajes privados, etc.)
 Contiene datos sobre el producto en sí, su entorno o el sistema relacionado que no
está destinado a ser divulgado por la aplicación.
Desde el lado de la aplicación, se deben tener en cuenta los siguientes aspectos a revisar y
aplicar dentro del entorno o servidor web:

 Desactive el listado de directorios para evitar la exposición de la estructura del sitio


web y los archivos potencialmente confidenciales.
 Utilice páginas de error personalizadas que eviten que se muestre información
excesiva del sistema.
 Deshabilite la salida de informes de errores en el navegador del cliente.
 Utilice un enfoque basado en IP para acceder a directorios confidenciales o
restringir el acceso a directorios de otro modo.
3. Canales de transmisión seguros. (CWE-319)
El software transmite datos confidenciales o críticos para la seguridad en texto sin cifrar
en un canal de comunicación que puede ser detectado por medios no autorizados. Se
deben configurar los servidores para que utilicen canales encriptados para la
comunicación, que pueden incluir SSL u otros protocolos seguros.
Para verificar como remediar esta vulnerabilidad, se harán una serie de validaciones y
comprobaciones de seguridad sobre el servidor web, teniendo en cuenta que debe estar
protegido con un certificado de seguridad SSL que asegure la transmisión de la
información por medio del protocolo HTTPS.
https://owasp.org/www-project-mobile-top-10/2016-risks/m3-insecure-communication
https://cwe.mitre.org/data/definitions/319.html

4. Web API Help y Enumeración de WSDL (CWE-200)


Hace referencia a la misma vulnerabilidad del punto 2 del presente documento. Para
remediar la enumeración del WSDL y asegurar la Web API Help se debe evitar el listado de
directorios que pueda comprometer la obtención de los archivos de código fuente de los
servicios WEB así como de la API propia de la aplicación que puede ser explotada por un
atacante externo o interno.
Se realizará la verificación de parches a nivel de sistema operativo del servidor para
garantizar que se encuentran cubiertas dichas vulnerabilidades.
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-1334
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-1337
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-1344
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-1345

5. Consumo público de web services (CWE-285)


Esta vulnerabilidad puede llevar desde la divulgación de información menor hasta la
ejecución remota de código y la aplicación web o el compromiso del sistema.
Dependiendo del diseño y la funcionalidad de la aplicación, un atacante puede usar esta
debilidad para acceder a información confidencial, desencadenar un ataque de
denegación de servicio o ejecutar código.
Sin embargo, hay tres reglas básicas que pueden ayudar a eliminar posibles problemas de
autorización inadecuada:

 Identifique todos los activos privilegiados dentro de su aplicación (páginas web que
muestran datos confidenciales, secciones de sitios web que contienen
funcionalidad privilegiada / administrativa, etc.)
 Identificar los roles de los usuarios dentro de la aplicación y sus permisos de
acceso.
 Siempre verifique si el usuario debe tener privilegios para acceder al activo.
Se aplicarán las mejores prácticas teniendo en cuenta el siguiente documento como
referencia:
https://cwe.mitre.org/data/definitions/285.html

6. Inyección SQL (CWE-89)


En términos generales, una aplicación es vulnerable a ataques de inyección cuando no
está equipada adecuadamente para hacer frente a comandos o consultas inesperados.
Cualquier aplicación o código que acepte la entrada del usuario puede estar sujeto a fallas
de inyección, lo que le permite al usuario inyectar código malicioso a través de la interfaz
de usuario.
Las vulnerabilidades de inyección afectan a los protocolos utilizados para recuperar datos
de una base de datos o servidor, como SQL o LDAP. Sin embargo, se pueden encontrar en
cualquier lenguaje utilizado para recuperar parcelas específicas de datos o código, como
nodos de datos en documentos XML a través de XPath y otros analizadores XML.
Referencia: https://www.immuniweb.com/vulnerability/sql-injection.html
Se realizarán validaciones de los parámetros configurados en el servidor web para
garantizar que la seguridad de la aplicación esté de acuerdo con las mejores prácticas para
evitar la inyección SQL.

También podría gustarte