¿Por qué CVSSv2 no considera que XSS tenga un impacto de confidencialidad?

4

De la especificación CVSSv2:

  

CONSEJO DE PUNTUACIÓN # 2: Al calificar una vulnerabilidad, considere el impacto directo solo en el host de destino. Por ejemplo, considere una vulnerabilidad de secuencias de comandos entre sitios: el impacto en el sistema de un usuario podría ser mucho mayor que el impacto en el host de destino. Sin embargo, este es un impacto indirecto. Las vulnerabilidades de las secuencias de comandos entre sitios deben puntuarse sin afectar la confidencialidad o la disponibilidad, y el impacto parcial a la integridad especificación CVSSv2

También es así como he visto que se puntúa XSS en la práctica.

Pero incluso si solo consideramos el impacto en el host, un atacante podría usar una carga útil de JavaScript que lee información confidencial de la aplicación web afectada (si la víctima está actualmente registrada, por supuesto, y si existe dicha información confidencial) ).

Entonces, ¿por qué la confidencialidad no se considera baja? ¿Es este un impacto indirecto? Y si es así, ¿por qué (y por qué el impacto de la integridad no es indirecto entonces)? Y para el caso, ¿por qué no hay un impacto en la disponibilidad? ¿Un atacante no podría pasar por alto la protección CSRF y, por lo tanto, posiblemente (dependiendo de la aplicación, por supuesto), eliminar datos importantes o cambiar la configuración para que la aplicación no esté disponible?

Relacionado: ¿Por qué se califica XSS con impacto parcial a la integridad en CVSS V2? .

Sé que esto ha cambiado en CVSSv3 (porque ahora se considera el navegador en lugar del host).

    
pregunta tim 09.10.2016 - 22:49
fuente

1 respuesta

2

La respuesta es bastante simple. Dado que es un efecto indirecto del XSS. Ejemplo: una vulnerabilidad que le permita leer las cookies tendría un impacto de confidencialidad. Pero una vulnerabilidad que le permite inyectar XSS tiene un impacto en la integridad (le permite cambiar la página), pero como puede cambiar arbitrariamente la página, a una página maliciosa que roba las cookies, la calificación no toma en cuenta las vulnerabilidades indirectas. que se encuentran.

Tomemos como ejemplo esto: Una vulnerabilidad en un script de descarga permite a un atacante reemplazar el EXE que se está descargando. Tendría un impacto de integridad bastante alto.

Pero no tiene un impacto de confidencialidad simplemente porque el EXE malicioso que se está descargando podría filtrar información.

Lo mismo con XSS. Este puntaje es importante ya que la corrección de la vulnerabilidad es resolverlo en su origen (elimine la posibilidad de XSS filtrando mejor). Mejorar la confidencialidad no solucionará esto sin incurrir en efectos secundarios no deseados, y además de eso, el XSS permanecería en la aplicación web, causando que la vulnerabilidad aún estuviera vigente (el CVE no se puede registrar como resuelto) porque hay Otros riesgos son los riesgos de confidencialidad.

El sistema CVSSv3 tiene algunos otros vectores agregados que compensan esto, por eso también se cambia en CVSSv3. (con las métricas de cambio de alcance, que se tienen en cuenta si el efecto del ataque se produce en otro lugar, y esto se puede considerar cuando se mitiga la vulnerabilidad)

    
respondido por el sebastian nielsen 10.10.2016 - 01:35
fuente

Lea otras preguntas en las etiquetas