Verifique si hay configuraciones de CORS inseguras con cURL

0

Estoy tratando de verificar la configuración de CORS de un sitio web usando cURL. El siguiente comando debería permitirme verificar si la configuración de CORS puede considerarse segura o si se pueden realizar solicitudes a través de los orígenes.

Estoy realizando una comprobación de verificación previa, pero lo mismo debería funcionar con la solicitud normal y el encabezado de origen.

Comprobación previa:

curl -H "Origin: https://example.local" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: X-Requested-With" \
  -X OPTIONS -D - -o /dev/null\
  -x http://127.0.0.1:8080/\
  https://example.com

OBTENER con Origen:

  curl -H "Origin: https://example.local"\
  -D - -o /dev/null\
  https://example.com

Ahora lo que no entiendo es que la aplicación de destino simplemente responde con el contenido como de costumbre. No hay encabezados Access-Control-Allow-Origin , Access-Control-Allow-Methods y Access-Control-Allow-Headers .

Así que efectivamente no puedo decidir si la configuración de CORS es segura o no. Intenté enviar las solicitudes a través de Burp (con los dos métodos a continuación), pero algo está mal y la solicitud nunca llega a Burp.

Método 1 cURL:

curl [...] -x http://127.0.0.1:8080/ [...]

Método 2 CLI:

export https_proxy='https://127.0.0.1:8080/'
export http_proxy='http://127.0.0.1:8080/'

curl [...]

export https_proxy=''
export http_proxy=''

Lo que puede causar el comportamiento extraño de la aplicación web con mis solicitudes de Pre-vuelo de OPCIONES y la solicitud GET con el encabezado de origen. ¿Cómo puedo enviar la solicitud a través de Burp para verificar la solicitud en sí?

    
pregunta SaAtomic 15.11.2017 - 16:20
fuente

1 respuesta

4

Solo debe especificar el encabezado de origen en su solicitud. La aplicación responderá con los encabezados Access-Control- *. Intente solo especificar el encabezado de origen y vea cómo se ve el resultado.

En cuanto a si los encabezados no se devuelven, el servidor web no tiene que responder con una política CORS. Si no es así, el navegador no permitirá solicitudes de origen cruzado como de costumbre. CORS permite al servidor habilitar las solicitudes de origen cruzado en función de ciertos criterios.

El problema principal que encuentro al realizar pruebas de problemas de CORS es que el encabezado Access-Control-Allow-Origin se completa con lo que se envía a través del encabezado Origin en la solicitud. Esto derrota todo el propósito de CORS. Un atacante no debería poder definir los orígenes permitidos.

Hay varias extensiones Burp diferentes que informarán sobre errores de configuración relacionados con CORS y problemas de seguridad. También hay esta publicación en el blog Portswigger que detalla algunas configuraciones erróneas comunes.

enlace

    
respondido por el Joshua Gimer 15.11.2017 - 16:59
fuente

Lea otras preguntas en las etiquetas