Recientemente tuve que configurarlo Access-Control-Allow-Originpara *poder hacer llamadas ajax entre subdominios.
Ahora no puedo evitar sentir que estoy poniendo mi entorno en riesgos de seguridad.
Por favor, ayúdame si lo estoy haciendo mal.
Respuestas:
Al responder con Access-Control-Allow-Origin: *, el recurso solicitado permite compartir con cada origen. Esto básicamente significa que cualquier sitio puede enviar una solicitud XHR a su sitio y acceder a la respuesta del servidor, lo que no sería el caso si no hubiera implementado esta respuesta CORS.
Por lo tanto, cualquier sitio puede hacer una solicitud a su sitio en nombre de sus visitantes y procesar su respuesta. Si tiene algo implementado como un esquema de autenticación o autorización que se basa en algo que el navegador proporciona automáticamente (cookies, sesiones basadas en cookies, etc.), las solicitudes activadas por los sitios de terceros también los usarán.
De hecho, esto plantea un riesgo de seguridad, especialmente si permite compartir recursos no solo para los recursos seleccionados sino para todos los recursos. En este contexto, debería echar un vistazo a ¿ Cuándo es seguro habilitar CORS? .
Access-Control-Allow-Origin: *? No habrá nogin, etc., ¿son públicos para todos?
Access-Control-Allow-Origin: *es totalmente seguro agregarlo a cualquier recurso, a menos que ese recurso contenga datos privados protegidos por algo distinto a las credenciales estándar (cookies, autenticación básica, certificados de cliente TLS).
Imagine https://example.com/users-private-data, que puede exponer datos privados según el estado de inicio de sesión del usuario. Este estado usa una cookie de sesión. Es seguro agregar Access-Control-Allow-Origin: *a este recurso, ya que este encabezado solo permite el acceso a la respuesta si la solicitud se realiza sin cookies, y se requieren cookies para obtener los datos privados. Como resultado, no se filtran datos privados.
Imagine https://intranet.example.com/company-private-data, que expone los datos de la empresa privada, pero solo se puede acceder si está en la red wifi de la empresa. No es seguro agregar Access-Control-Allow-Origin: *a este recurso, ya que está protegido con algo más que las credenciales estándar. De lo contrario, un script incorrecto podría usarlo como un túnel hacia la intranet.
Imagine lo que vería un usuario si accediera al recurso en una ventana de incógnito. Si está contento con que todos vean este contenido (incluido el código fuente que recibió el navegador), es seguro agregarlo Access-Control-Allow-Origin: *.
Access-Control-Allow-Origin: *solo permite solicitudes sin cookies. He editado la respuesta para aclarar un poco.
AFAIK, Access-Control-Allow-Origin es solo un encabezado http enviado desde el servidor al navegador. Limitarlo a una dirección específica (o deshabilitarlo) no hace que su sitio sea más seguro, por ejemplo, para los robots. Si los robots lo desean, pueden ignorar el encabezado. Los navegadores habituales (Explorer, Chrome, etc.) cumplen el encabezado de forma predeterminada. Pero una aplicación como Postman simplemente lo ignora.
El servidor no verifica realmente cuál es el 'origen' de la solicitud cuando devuelve la respuesta. Simplemente agrega el encabezado http. Es el navegador (el cliente final) el que envió la solicitud que decide leer el encabezado de control de acceso y actuar sobre él. Tenga en cuenta que en el caso de XHR puede usar una solicitud especial de 'OPCIONES' para pedir primero los encabezados.
Por lo tanto, cualquier persona con capacidades creativas de secuencias de comandos puede ignorar fácilmente todo el encabezado, lo que esté configurado en él.
Consulte también Posibles problemas de seguridad al configurar Access-Control-Allow-Origin .
Ahora para responder realmente la pregunta
No puedo evitar sentir que estoy poniendo mi entorno en riesgos de seguridad.
Si alguien quiere atacarte, puede pasar fácilmente por Access-Control-Allow-Origin. Pero al habilitar '*', le da al atacante algunos 'vectores de ataque' más para jugar, por ejemplo, utilizando navegadores web regulares que respetan ese encabezado HTTP.
Access-Control-Allow-Origin *se desaconseja configurar un sitio web malicioso que aloje scripts para robar contraseñas :-)
192.168.1.1) y reconfigurar su enrutador para permitir ataques. Incluso puede usar su enrutador directamente como un nodo DDoS. (La mayoría de los enrutadores tienen páginas de prueba que permiten pings o verificaciones simples del servidor HTTP. Se puede abusar de ellas en masa).
Aquí hay 2 ejemplos publicados como comentarios, cuando un comodín es realmente problemático:
Supongamos que inicio sesión en el sitio web de mi banco. Si voy a otra página y luego vuelvo a mi banco, todavía estoy conectado debido a una cookie. Otros usuarios en Internet pueden acceder a las mismas URL en mi banco que yo, pero no podrán acceder a mi cuenta sin la cookie. Si se permiten solicitudes de origen cruzado, un sitio web malicioso puede suplantar efectivamente al usuario.
- Brad
Suponga que tiene un enrutador doméstico común, como un Linksys WRT54g o algo así. Suponga que el enrutador permite solicitudes de origen cruzado. Un script en mi página web podría realizar solicitudes HTTP a direcciones IP comunes de enrutadores (como 192.168.1.1) y reconfigurar su enrutador para permitir ataques. Incluso puede usar su enrutador directamente como un nodo DDoS. (La mayoría de los enrutadores tienen páginas de prueba que permiten pings o verificaciones simples del servidor HTTP. Se puede abusar de ellas en masa).
- Brad
Siento que estos comentarios deberían haber sido respuestas, porque explican el problema con un ejemplo de la vida real.
En un escenario en el que el servidor intenta deshabilitar el CORS por completo, configura los siguientes encabezados.
Access-Control-Allow-Origin: * (le dice al navegador que el servidor acepta solicitudes de sitios cruzados de cualquier ORIGEN)
Access-Control-Allow-Credentials: verdadero (le dice al navegador que las solicitudes de sitios cruzados pueden enviar cookies)
Hay un sistema a prueba de fallos implementado en los navegadores que generará el siguiente error
"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"Entonces, en la mayoría de los escenarios, configurar 'Access-Control-Allow-Origin' *no será un problema. Sin embargo, para protegerse contra ataques, el servidor puede mantener una lista de orígenes permitidos y cada vez que el servidor recibe una solicitud de origen cruzado, puede validar el encabezado ORIGIN contra la lista de orígenes permitidos y luego repetir el mismo en Access-Control-Allow-Origin encabezamiento.
Dado que el encabezado ORIGIN no se puede cambiar con JavaScript que se ejecuta en el navegador, el sitio malicioso no podrá falsificarlo.