javascript - missing - Implicaciones de seguridad de agregar todos los dominios a CORS(Access-Control-Allow-Origin:*)

cors javascript

Question

Se dice que en lugar de agregar todos los dominios a CORS , solo se debe agregar un conjunto de dominios. Sin embargo, a veces no es trivial agregar un conjunto de dominios. Por ejemplo, si quiero exponer públicamente una API, entonces, para cada dominio que desee realizar una llamada a esa API, debería contactarme para agregar ese dominio a la lista de dominios permitidos.

Me gustaría tomar una decisión de compromiso consciente entre las implicaciones de seguridad y menos trabajo.

Los únicos problemas de seguridad que veo son ataques DoS y ataques CSRF . Los ataques CSRF ya se pueden lograr con elementos IMG y elementos FORM. Los ataques DoS relacionados con CORS pueden superarse mediante el bloqueo de solicitudes en el encabezado de referencia.

¿Me estoy perdiendo las implicaciones de seguridad?

=== Editar ===

• Se supone que el encabezado Access-Control-Allow-Credentials no está configurado
• Sé cómo agregar una lista de dominios "CORS access" y, por lo tanto, solo me interesan las implicaciones de seguridad de agregar todos los dominios "CORS access".

Answer 1

CORS trata de recuperar el contenido, no solo hacer la solicitud. Cuando obtiene un recurso a través de una etiqueta img o script, puede engañar al navegador de alguien para que haga una solicitud de estilo CSRF. Esto es normal, y puede protegerse contra eso con un token CSRF normal.

Con CORS habilitado en todos los dominios, ahora puede tener javascript en un sitio atacante hacer una solicitud y recuperar el contenido, invadiendo su privacidad.

Ejemplo:

Imagine que su espalda permite CORS para todos los dominios. Ahora hago un sitio web que hace una solicitud a yourimaginarybank.com/balance

Una solicitud de IMG no haría nada, porque mi javascript no puede obtener lo que estaba en el html de esa página en el sitio web de su banco. Ahora que han activado CORS, el javascript en mi sitio realmente recupera una página HTML con su saldo y lo guarda en mi servidor. No solo puedo hacer una solicitud GET como antes, sino que ahora puedo ver lo que hay adentro. Este es un gran problema de seguridad.

¿Cómo resolver el problema sin agregar una gran lista en sus encabezados? Cada solicitud CORS se realiza con el encabezado Origen. La mejor solución es, probablemente, leer el encabezado de Origin y consultar una base de datos para ver si está en la lista blanca, como lo sugirió Fritz en su respuesta.

Answer 2

Excepto en el caso de csauve , ninguna de las respuestas responde mi pregunta original.

Para responder mi pregunta; Parece que, mientras no se configure Access-Control-Allow-Credentials no hay ningún problema de seguridad.

(¿Qué me hace preguntar por qué la especificación requiere verificación previa cuando Access-Control-Allow-Credentials no está configurado?)

Answer 3

La mejor práctica es verificar primero el dominio de la solicitud entrante y luego generar el encabezado de respuesta. Dependiendo de si este dominio puede enviar solicitudes, lo agrega (solo este) al encabezado de respuesta de Access-Control-Allow-Origin .

Afaik, ni siquiera es posible agregar más de un dominio a este encabezado. Entonces, es * o un dominio específico y siempre preferiría no agregar *

Answer 4

Los ataques de falsificación de solicitudes entre sitios son, por lejos, la principal preocupación que abordan las direcciones de acceso-control-permiso-origen.

Ryan es ciertamente correcto con respecto a la recuperación de contenido. Sin embargo, sobre el tema de hacer la solicitud hay más para decir aquí. Muchos sitios web ahora ofrecen servicios web RESTful que exponen una amplia gama de características que pueden implicar cambios significativos en el back-end. Muy a menudo, estos servicios RESTful están destinados a ser invocados con una solicitud XHR (por ejemplo, AJAX) (probablemente con una " Aplicación de página única " como front-end). Si un usuario tiene una sesión activa que otorga acceso a estos servicios cuando visita un sitio de terceros malicioso, ese sitio puede intentar invocar esos puntos finales REST entre bastidores, pasando valores que podrían comprometer al usuario o al sitio. Dependiendo de cómo se definan los servicios REST, hay varias formas de protegerse contra esto.

En el caso específico de los servicios web REST para una aplicación de una sola página, puede dictar que todas las solicitudes a los puntos finales REST de fondo se realizan con XHR y rechazar cualquier solicitud que no sea XHR. Puede dictar esto comprobando la presencia de un encabezado de solicitud personalizado (algo así como X-Requerido-Con de jQuery). Solo las solicitudes de tipo XHR pueden establecer estos encabezados; las simples solicitudes GET y POST de formularios y recursos integrados no pueden. Finalmente, la razón por la que queremos dictar las solicitudes de XHR nos lleva de vuelta a la pregunta original: las solicitudes de XHR están sujetas a las reglas de CORS.

Si permitía Access-Control-Allow-Origin: *, cualquier sitio podría realizar cualquier solicitud AJAX en nombre del usuario a sus puntos finales REST. Si sus puntos finales REST involucran cualquier tipo de datos confidenciales o permiten la persistencia de los datos, esta es una vulnerabilidad de seguridad inaceptable. En su lugar, aplique solicitudes XHR-only como describí y defina una lista blanca de orígenes permitidos para realizar esas solicitudes.

Vale la pena señalar que si los puntos finales REST no exponen ninguna información sensible, o si no permiten al usuario realizar cambios persistentes en los datos, entonces Access-Control-Allow-Origin: * puede ser la decisión adecuada. Google Maps, por ejemplo, proporciona vistas de solo lectura en los datos de mapas públicos; no hay ninguna razón para restringir los sitios de terceros que deseen invocar esos servicios.

Answer 5

Puede enviar más de uno, como:

Access-Control-Allow-Origin: http://my.domain.com https://my.domain.com http://my.otherdomain.com

pero recomendaría no hacerlo. En cambio, mantenga una lista blanca de dominios permitidos. Digamos:

allowed = [ "X", "Y", "A.Z" ];

Luego, si recibe una solicitud de X , responde con:

Access-Control-Allow-Origin: X

Si recibe una solicitud de AZ , responda con:

Access-Control-Allow-Origin: A.Z

Si recibe una solicitud de un dominio que no está permitido, responda con un error o sin una política de CORS.

Todas las solicitudes de XHR enviarán un encabezado de Origin , así que úselo. Y solo necesita enviar los encabezados de las políticas CORS para la solicitud OPTIONS , no la solicitud GET/POST/HEAD que sigue.

El principal problema que veo es que expones todos tus dominios. Tal vez tenga un dominio de administrador seguro como: https://admin.mydomain.com , o tal vez tenga un sitio web de producto que aún no está listo para su lanzamiento. No desea incluir nada que no sea absolutamente necesario para la solicitud en cuestión.

Y * es extremadamente flojo.

Answer 6

Una vieja pregunta, pero muchas respuestas malas aquí, así que tengo que agregar la mía.

Si no configura Access-Control-Allow-Credentials y realiza una autenticación sin cookies (es decir, la persona que llama proporciona un encabezado de Autorización de portador), entonces no necesita incluir en la lista blanca los orígenes. Solo repite el origen en Access-Control-Allow-Origin .

Una API REST bien estructurada se puede llamar de forma segura desde cualquier origen.