Drupal disputado CVE Cinco años Tempestad - ¿Falta de seguridad de código abierto?

Por lo que puedo decir, este es un informe de errores falso. Creo que el equipo de Drupal está 100% en el derecho de despedir y disputar este "informe de error". Ninguna de las supuestas "vulnerabilidades" me parecen vulnerabilidades. Simplemente afirmar que algo es una vulnerabilidad no necesariamente lo hace así.

El periodista alega una serie de problemas:

1. Alegación: si el atacante aprende el token CSRF, puede derrotar a la defensa CSRF. Bueno, duh. Así es como funcionan los tokens CSRF. No es una vulnerabilidad. Cuando usamos tokens CSRF, diseñamos el sistema para evitar revelar el token al atacante. Si el reportero encontró alguna manera de que un atacante pudiera aprender el token CSRF, podríamos discutirlo, pero tal como está, el reportero no tiene nada.

2. Alegación: el método de cierre de sesión no está protegido por un token CSRF, por lo que un atacante podría cerrar la sesión de un administrador. Este reclamo no parece ser cuestionado por los hechos, por lo que asume que es correcto Sin embargo, no existe una consecuencia o peligro obvio para la seguridad por el hecho de poder cerrar sesión por la fuerza de un administrador. También hay otras formas de cerrar la sesión de un usuario a la fuerza, en cada aplicación web que se haya creado, por ejemplo, superando los límites de capacidad en el navegador tarro de galletas .

3. Alegación: Drupal no comprueba constantemente el encabezado del remitente en todas las solicitudes. Eso no es un defecto de seguridad. El encabezado del Referer no debe usarse con fines de seguridad, ya que los atacantes pueden falsificarlo o forzar su omisión. El periodista no alega ningún daño causado por esta propiedad de Drupal.

4. Alegación: Drupal no distingue los métodos POST vs GET. Este es probablemente un caso de mala práctica de implementación, pero no hay una consecuencia de seguridad identificada por el reportero ni un daño evidente.

Consulte también la respuesta oficial del grupo Drupal .

Básicamente, creo que el informe original debe ignorarse y tratarse como no válido, por no poder alegar una vulnerabilidad de seguridad válida. No veo ningún defecto, fundamental o no, en la seguridad del código abierto. En realidad, creo que es un mérito del equipo de Drupal responder a las acusaciones con cuidado.

La seguridad es siempre una compensación. Para obtener seguridad adicional, generalmente tiene que sacrificar la conveniencia, el rendimiento o algún otro costo. En este caso, el equipo de Drupal sostiene que el beneficio de seguridad incremental es tan intrascendente que no garantiza el costo de la implementación.

Al leer el informe de exploits, parece que hay algunos "exploits" reportados. Uno indica que si una persona ataca desde una posición de hombre en el medio o desde un proceso en la propia computadora de la víctima, puede aprovechar esa posición para realizar un ataque XSRF. Se puede argumentar que tal atacante debe tener tanto acceso para montar tal ataque que no está ganando nada que ya no tiene.

Otro ataque de la lista dice que el atacante puede crear un formulario de cierre de sesión que, si lo envía la víctima, cerrará la sesión. El equipo drupal argumenta que debido a que la víctima realmente tiene que POSTAR un formulario de cierre de sesión (que requiere una acción deliberada), y porque la "carga útil" del ataque es simplemente cerrar la sesión, y dado que solucionar este problema romperá la mayoría de los temas existentes, entonces, el beneficio de seguridad obtenido no garantiza el desorden que causaría su reparación.

Finalmente, el informe dice que si bien los formularios tienen la comprobación XSRF adecuada, la interfaz NO realiza la comprobación de referencia de HTTP en todas las formas. Y por lo tanto, si el atacante pudo capturar el token XSRF de alguna manera, podría usarlo para montar un ataque XSRF desde otro dominio. El equipo de drupal argumenta que todo el punto del token de XSRF es evitar este tipo de ataque incluso sin verificaciones de Referrer. Argumentan que agregar una verificación de referencia no agrega más seguridad, pero sí reduce el rendimiento y la compatibilidad del navegador. Por lo tanto, argumentan, esto no es un problema y no vale la pena abordarlo.