¿Existe alguna vulnerabilidad al utilizar XHR con el método GET y el encabezado HTTP personalizado anti-CSRF?

Question

¿Existe alguna vulnerabilidad al utilizar XHR con el método GET y el encabezado HTTP personalizado anti-CSRF?

#1 de Lachezar Balev (9 votos)
#2 de Sachin Kumar (1 votos)

1

Imagina el botón después de hacer clic en qué navegador envía una solicitud XHR http con el método GET. Características:

después de ejecutar la solicitud, se realiza una acción sensible
la información confidencial se envía en los parámetros GET
Los encabezados HTTP X-Requested-With: XMLHttpRequest y X-CSRF-Token con un token PRG suficientemente grande se envían y son necesarios para que la acción se ejecute
para Copy link location cuando se hace clic derecho en el botón ya que es un formulario.

Normalmente, XHR se usa con GET, pero aquí se usa con GET. Es la única diferencia con respecto a las solicitudes XHR normales.

¿Este diseño conduce a alguna vulnerabilidad de seguridad?

Editar: Algunos respondedores y comentaristas dicen que:

El usuario puede copiar o marcar la URL. Sin embargo, el único lugar desde donde el usuario puede copiar la URL es el código fuente de la página, ya que esta URL no está expuesta en la barra de direcciones del navegador; haga clic derecho en el menú porque el botón es un formulario). También los parámetros son agregados a solicitud por el propio navegador para que el usuario no pueda copiar la url completa del código fuente.
El usuario puede copiar parte de la ventana del navegador. Sin embargo, la url no está expuesta en la ventana del navegador
Puede convertirse en parte del encabezado del Referer. Sin embargo, es XHR y no cambia la URL en el encabezado del Referente de las próximas solicitudes

Por lo tanto, la única vulnerabilidad válida parece ser que los parámetros GET pueden registrarse en los registros del servidor web (no se registrarán en el proxy debido al uso de TLS). Si esos registros son accesibles para el atacante, entonces él tendrá información confidencial.

web-application appsec http csrf

pregunta Andrei Botalov 17.05.2012 - 13:37

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application appsec http csrf

¿El hash resuelve las contraseñas en partes? ¿Existen reglas relacionadas con la seguridad en PCI-DSS que rigen cuando puedo capturar un pago?

score 9 · Answer 1

No confiaría en este diseño. La especificación de HTTP dice:

Los implementadores deben tener en cuenta que el software representa al usuario en   sus interacciones a través de Internet, y deben tener cuidado de permitir   el usuario debe ser consciente de cualquier acción que pueda tomar que pueda tener una   significado inesperado para ellos mismos u otros.

En particular, se ha establecido la convención de que el GET y   Los métodos de HEAD NO DEBEN tener el significado de tomar una acción   Aparte de la recuperación. Estos métodos deben considerarse "seguros".   Esto permite a los agentes de usuario representar otros métodos, como POST, PUT   y BORRAR, de una manera especial, para que el usuario tenga conocimiento de la   hecho de que se está solicitando una acción posiblemente insegura.

Naturalmente, no es posible garantizar que el servidor no lo haga   generar efectos secundarios como resultado de realizar una solicitud GET; en   De hecho, algunos recursos dinámicos consideran que una característica. Lo importante   La distinción aquí es que el usuario no solicitó los efectos secundarios, por lo que   por lo tanto, no puede ser responsabilizado por ellos.

En términos generales, nunca recomendaría el uso de tokens CSRF en las solicitudes GET, ya que pueden estar disponibles en varios archivos de registro (vulnerabilidad si el token anticsrf no se elimina correctamente después de un uso), pueden convertirse en parte del encabezado de referencia , los usuarios pueden marcarlos y esto provocará una fuga de seguridad o marcadores no válidos. Esto también puede tener un impacto negativo en el SEO. Etc., etc.

Así que creo que GET + CSRF + ANY_OTHER_SENSITIVE_DATA = mala idea.

score 1 · Answer 2

Problema 1: datos confidenciales en la URL.
Problema 2: token CSRF en URL Todo lo que ponga en la URL se registrará en el historial del navegador, los registros de proxy, los registros del servidor web ...
Problema 3: no puede evitar que el usuario vea el enlace / url deshabilitando las opciones de clic derecho, todo lo que envió al navegador será accesible para el usuario, de una forma u otra

NO USE GET para publicar datos y solicitudes que cambien el estado.

No veo ningún problema al poner el token CSRF en el encabezado, las cosas adicionales que debe tener en cuenta no abren su servidor a las solicitudes de CORS de HTML5. Si necesita permitir CORS, entonces hay cosas adicionales que debería considerar.