Decidir el parámetro de alcance CVSS v3 para algunas de las 10 principales vulnerabilidades de OWASP

2

Estoy tratando de obtener un puntaje en el top 10 en cvss v3 y tengo dificultades para asignar el parámetro "alcance" para algunos. Por favor, corrija la siguiente lista si hay algunas fallas.

  • Inyección SQL: modificado.
    Componente vulnerable: servidor web / servidor de base de datos
    Componente impactado: aplicación web. Puede hacer que la aplicación web no esté disponible.

  • XSS: Cambiado
    Componente vulnerable: servidor web
    Componente afectado: navegador

  • Redirecciones no validadas: Cambiado
    Componente vulnerable: servidor web
    Componente afectado: navegador (se puede descargar malware)

  • CSRF: Sin cambios

  • Fijación de sesión: sin cambios

  • Referencia de objetos directa no segura: sin cambios

  • Subida de archivos sin restricciones: Modificado
    Componente Vulnerable: servidor web
    Componente afectado: podría ser el sistema operativo host

pregunta one 05.07.2016 - 14:28
fuente

3 respuestas

1

Ámbito en CVSSv3

El alcance se define en la documentación :

  

Cuando la vulnerabilidad de un componente de software regido por un ámbito de autorización puede afectar a los recursos gobernados por otro ámbito de autorización, se ha producido un cambio de Ámbito.

Ejemplos

  

1) Inyección SQL: modificado.
  Componente vulnerable: servidor web / servidor de base de datos
  Componente impactado: aplicación web. Puede hacer que la aplicación web no esté disponible.

No estaría de acuerdo con su razonamiento, pero estaría de acuerdo en que se cambia el alcance.

El componente vulnerable es la aplicación web: la vulnerabilidad no fue introducida por el servidor ni por el DBMS, pero el problema existe porque la aplicación web insertó la entrada del usuario en una consulta SQL.

El componente afectado es la base de datos, ya que gobierna los datos que contiene, y un ataque puede extraer información que no debería estar disponible. Si se pueden ejecutar comandos del sistema o si se pueden cargar archivos, el servidor también se vería afectado.

Otras opiniones:

  • CVE-2015-8604 está calificado como alcance sin cambios.
  • High-Tech Bridge clasifica las inyecciones de SQL como alcance modificado en una publicación de blog sobre CVSSv3.
  • High-Tech Bridge clasifica las inyecciones de SQL como un alcance sin cambios en su calculadora CVSSv3.

Se puede ver que hay al menos cierta falta de claridad sobre la calificación del alcance de las inyecciones de SQL. No he encontrado ningún otro ejemplo que determine el alcance de una inyección SQL.

  

2) XSS: Cambiado
  Componente vulnerable: servidor web
  Componente impactado: navegador

Tiene sentido, y así es como First lo califica en su ejemplo de XSS .

  

3) Redirecciones no validadas: modificadas.
  Componente vulnerable: servidor web
  Componente afectado: navegador (se puede descargar malware)

Esto también tiene sentido, por la misma razón que XSS.

  

4) CSRF: Sin cambios

Esto también tiene sentido, y es también el modo en que First lo califica en su CSRF example . El componente vulnerable y el componente afectado son la aplicación web.

  

5) Fijación de sesión: Sin cambios

Esto también tiene sentido, por la misma razón que CSRF.

  

6) Referencia de objeto directo inseguro: Sin cambios

Esto también tiene sentido, por la misma razón que CSRF.

  

7) Carga de archivos sin restricciones: Modificado
  Componente Vulnerable: servidor web
  Componente impactado: podría ser el sistema operativo host

Esto tiene sentido.

    
respondido por el tim 05.07.2016 - 16:04
fuente
0

Este parámetro se introdujo porque algunos sistemas diferentes podrían verse afectados. XSS es un ejemplo muy real: en versiones anteriores de CVSS, XSS obtendría una puntuación muy baja porque, aunque existe una vulnerabilidad en una aplicación web, la aplicación web en sí misma o el servidor en el que se ejecuta no se ven realmente afectados. quién es la víctima.

Lo mismo ocurre con cosas como la intoxicación por ARP. Eso no afecta realmente al conmutador o al enrutador que se ataca, sino a otros dispositivos en la misma red que ahora pueden ser 'hombres en el medio'.

Consulte también enlace para obtener más información.

Entonces, en el caso de XSS, creo que es correcto usar la puntuación "C", pero para la inyección SQL no estoy tan seguro. Eso es un simple robo en la aplicación en cuestión. (a menos que, por supuesto, se produzca una mala configuración de la base de datos a través de la cual es posible un mayor compromiso de la red, pero la inyección de SQL solo debería afectar a la aplicación en cuestión).

    
respondido por el Mark Koek 05.07.2016 - 15:34
fuente
0

Creo que la inyección de SQL tiene un alcance sin cambios la mayor parte del tiempo.

Aquí hay ejemplos de algunas vulnerabilidades de inyección de SQL, con puntaje CVSS 3:

Todos estos tienen alcance sin cambios.

También hay inyecciones de SQL con el alcance cambiado, pero estas no son sus inyecciones de SQL normales:

Aunque estoy bastante seguro de que la inyección de SQL no ha cambiado el alcance, no sé lo suficiente sobre el alcance de CVSS para determinar por qué esto es así.

    
respondido por el Sjoerd 06.06.2017 - 16:27
fuente

Lea otras preguntas en las etiquetas