¿Cómo clasificar las vulnerabilidades de la web en un informe?

Navega tus respuestas
2

¿Cuál es una buena manera de categorizar las vulnerabilidades en los informes de seguridad de TI? Suponiendo que se trata de entornos basados en web como:

  1. sitios web,
  2. aplicaciones web,
  3. Tiendas web,
  4. Cualquier interfaz que use tecnología web y es accesible mediante un navegador.

Actualmente estoy usando Top 10 de OWASP de 2013 y opcionalmente agrego una categoría adicional "otra ". ¿Alguna idea sobre buenas alternativas?

    
pregunta Bob Ortiz 19.06.2016 - 00:40
fuente

2 respuestas

1

Esto es muy controvertido y controvertido, pero quería proporcionarte algo para pensar para que tomes tu propia decisión.

Hay OWASP, CWE y WASC. No me gustan ninguno de ellos.

¿Por qué no debería usar ninguno de estos métodos de categorización?

Los 10 principales intentos de OWASP para proporcionar una lista más común en una vista de alto nivel de lo que ha sucedido en los últimos dos años. Pero cuando está creando informes técnicos, el intento de asignar vulnerabilidades a estas categorías de alto nivel deja mucho espacio para la interpretación y queda mucho espacio para las cosas que no encajan.

Toma estos ejemplos:

"Ejecución de código remoto mercurial en Importador": ¿Falta el control de acceso a nivel de función? Según OWASP, eso no es apropiado. enlace incluso dice que es para controlar el acceso a datos confidenciales, no para prevenir arbitrarios código de ejecución.

Pero hay más.

"La ejecución del código Git LFS" se coloca en "Otros". "La ejecución remota de código de GitHub para Windows" está en inyección.

¿Qué tienen estos tres en común? Son código de inyección. Pero bajo estas asignaciones de OWASP, son tres cosas diferentes. ¿Eso tiene sentido para un gerente que tiene que revisar su informe? Llámelo como es: ejecución remota de código. Cómo surgió, cómo solucionarlo, son cosas separadas de lo que es el problema, el problema es ejecutar códigos o comandos arbitrarios.

¿Por qué debería usar estos métodos de categorización?

La asignación a alguna categorización principal puede facilitar los informes al proporcionar la frecuencia con la que la organización se encuentra con XSS u otros problemas.

Palabra de advertencia final

La industria tiene algunos problemas que arreglar, y creo que este es uno grande. 10 categorías no es suficiente para el mapeo. 25 categorías están mejorando, pero su organización puede estar más orientada a aplicaciones móviles con puntos finales de API web, para las cuales la categorización como "Inyección" no funciona tan bien como la categorización de la inyección LDAP, o algo más.

La elección es, por supuesto, tuya, pero a lo largo de los años, esto es lo que he aprendido.

    
respondido por el h4ckNinja 19.06.2016 - 01:37
fuente
0

Hay cientos de vulnerabilidades basadas en aplicaciones web y se pueden clasificar en estas:

  • Validación de entrada (XSS, inyección de SQL)
  • Autenticación (contraseña débil, enumeración de usuarios)
  • Autorización (escalada de privilegios, referencia de objeto de dirección insegura)
  • Administración de sesión (corrección de sesión, botón de cierre de sesión ausente)
  • Divulgación de información (mensaje de error detallado)
  • Sistema operativo / servidor web (secuencias de comandos de marcos cruzados)
  • Manipulación de la lógica de la aplicación (redirecciones no válidas, PRSSI)

Esto no es una regla y se puede modificar según sus necesidades.

    
respondido por el one 19.06.2016 - 07:03
fuente

Lea otras preguntas en las etiquetas

¿Es normal que las extensiones de Chrome exijan demasiados permisos? RSA-1024 vs. DSA-1024: la clave DSA SSH de reclamación es mucho más rápida que la fuerza bruta