¿Qué hace el token de URL en phpMyAdmin si no está impidiendo CSRF?

Question

¿Qué hace el token de URL en phpMyAdmin si no está impidiendo CSRF?

#1 de Anders (3 votos)

2

Vi que había un vulnerabilidad de seguridad para phpMyAdmin mediante la falsificación de solicitudes entre sitios (CSRF) . Siempre pensé que el parámetro ?token= en todas las URL de phpMyAdmin evitaba esto, pero luego leí esto:

Para preparar una URL de ataque CSRF, el atacante debe conocer el nombre de la base de datos y la tabla de destino.

Eso implica que el atacante no necesita conocer el token. Probé esto copiando el enlace del botón desplegable de la tabla para un DB de prueba en mi phpMyAdmin, eliminando el parámetro ?token= . Para mi sorpresa, dejó caer la mesa.

¿Este parámetro de token está destinado a evitar CSRF? Si no, ¿para qué sirve?

csrf phpmyadmin

pregunta Goose 04.01.2018 - 17:01

fuente

1 respuesta

Lea otras preguntas en las etiquetas csrf phpmyadmin

¿Se puede usar mprotect () para cambiar los permisos de .rodata? ¿Cómo puedo concentrarme en el lado positivo de la seguridad de la información para crear conciencia?

score 3 · Accepted Answer

El parámetro token URL es de hecho un token anti CSRF. Esto es de el mensaje de confirmación que corrige la vulnerabilidad :

Devolver la validación del token a las solicitudes GET

Esto es necesario para evitar CSRF en consultas SQL. Esto es realmente más un   solución a corto plazo, la solución adecuada (que se implementará en el maestro) es evitar   aceptando consultas SQL de solicitudes GET.

A partir de esto, podemos deducir que la vulnerabilidad fue el resultado de dos errores combinados:

Aceptar consultas SQL, una operación de cambio de estado, a partir de solicitudes GET. Esto se está desviando de la filosofía detrás de los verbos HTTP y en general es una mala idea.
No se comprueba el token CSRF para las solicitudes GET.

Parece que phpMyAdmin originalmente no diferenciaba tan bien entre GET y POST. P.ej. el token está en un parámetro de URL, no en un campo de formulario oculto, y el código utiliza $_REQUEST para verificarlo.

Luego alguien intentó solucionarlo, deshabilitando el cambio de estado de las solicitudes GET, así como la comprobación de token para las solicitudes GET, ya que ya no era necesario. Desafortunadamente, fallaron en el primero pero no en el segundo, y de ahí nació la vulnerabilidad.