CORS aceptando un origen arbitrario con GET pero no con OPTIONS

Question

CORS aceptando un origen arbitrario con GET pero no con OPTIONS

#1 de 1lastBr3ath (0 votos)

1

Estoy probando una API, que permite un origen arbitrario en las solicitudes POST / GET , respondiendo con el encabezado CORS Access-Control-Allow-Origin: * .

Sin embargo, con las solicitudes OPTIONS y un origen arbitrario, el servicio web no responde con Access-Control-Allow-Origin: * , no usa el encabezado de respuesta en absoluto.

Esto significa que cualquier solicitud de verificación previa de CORS con un origen arbitrario, fallaría.

No veo el punto de tener el encabezado de respuesta CORS para las solicitudes GET / POST , pero no la solicitud OPTIONS . Sin embargo, tampoco puedo proporcionar un ejemplo de una vulnerabilidad o cómo se puede explotar.

P: ¿Es seguro decir que no representa una vulnerabilidad, sino que es una mala práctica?

web-application api cors web-service

pregunta Dolores The Third 03.12.2018 - 13:45

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application api cors web-service

¿Cómo asegurar la conexión Wifi Direct p2p entre dispositivos Android? ¿Existe una lista compilada de certificados de fabricantes / certificados de TEE (Trusted Execution Environment)?

score 0 · Answer 1

P: ¿Es seguro decir que no representa una vulnerabilidad, pero es simplemente una mala práctica?

Ya que es una API y suponiendo requiere un encabezado Authorization para todas las solicitudes, es seguro decir que no representa una vulnerabilidad. El comportamiento, sin embargo, limita la comunicación al mismo dominio.

Vale la pena señalar que no todas las solicitudes están marcadas previamente. Para obtener más detalles, consulte enlace .

Una API espera, si está correctamente configurada , un encabezado Content-type adecuado y un encabezado de autorización que en la mayoría de los casos es Authorization . Si una solicitud establece un " nombre de encabezado prohibido " o un Content-type inseguro, siempre está marcado previamente. Y, como tal, ningún otro dominio podría enviar una solicitud autenticada.