Perspectivas Profundas sobre las Soluciones de Cross-Origin en APISIX

En el desarrollo de aplicaciones web, los problemas de origen cruzado se han convertido en un tema popular. Sin embargo, con la adopción generalizada de las puertas de enlace de API, ahora tenemos una solución más conveniente y eficiente para abordar los problemas de origen cruzado. La puerta de enlace de API, como un componente clave en la arquitectura de la aplicación, no solo proporciona funcionalidades como el enrutamiento de solicitudes y la gestión de API, sino que también maneja eficazmente las solicitudes de origen cruzado, ayudando a los desarrolladores a eludir las restricciones de la política de mismo origen del navegador. Este artículo profundizará en cómo usar la puerta de enlace de API APISIX para resolver problemas de origen cruzado.

¿Qué es el Origen Cruzado?

Los problemas de origen cruzado surgen principalmente de la política de mismo origen aplicada por los navegadores. La política de mismo origen requiere que el origen (protocolo, dominio, puerto) de una solicitud sea exactamente idéntico al recurso de destino; de lo contrario, el navegador bloqueará la solicitud. Esta política tiene como objetivo proteger la seguridad de la información del usuario y evitar que sitios web maliciosos roben datos. Sin embargo, en el desarrollo práctico, escenarios como la separación frontend-backend o la implementación con diferentes dominios o puertos a menudo conducen a problemas de origen cruzado.

Resolviendo Problemas de Origen Cruzado Usando APISIX

CORS (Intercambio de Recursos de Origen Cruzado)

CORS (Intercambio de Recursos de Origen Cruzado) es un estándar W3C que permite a los navegadores enviar solicitudes a servidores de origen cruzado, superando las restricciones impuestas por la política de mismo origen. En APISIX, los desarrolladores pueden configurar fácilmente reglas de CORS utilizando el plugin CORS, especificando qué orígenes están permitidos para acceder a los recursos.

Ejemplo de comando usando curl para configurar CORS en APISIX:

curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/hello", "plugins": { "cors": {} }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:8080": 1 } } }'

Este comando usa curl para enviar una solicitud PUT a la API de administración de APISIX, creando una ruta con el ID 1. La ruta está configurada con una ruta URI de /hello, y la configuración predeterminada habilita el plugin CORS. Además, se especifica el servidor upstream como 127.0.0.1:8080.

Ejecutando una solicitud de prueba se obtendrán los resultados de la configuración predeterminada:

curl http://127.0.0.1:9080/hello -v

...
< Server: APISIX web server
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: *
< Access-Control-Allow-Headers: *
< Access-Control-Expose-Headers: *
< Access-Control-Max-Age: 5
...

Si es necesario ajustar la política de CORS, simplemente modifique las configuraciones relevantes del plugin. Aquí hay varias opciones de configuración comúnmente utilizadas:

• allow_origins: Especifica los orígenes permitidos para el acceso de origen cruzado. Puede ser una URL específica o usar el comodín '*' para permitir todos los orígenes. Los valores múltiples se separan por comas.

• allow_methods: Define los métodos HTTP permitidos para el acceso de origen cruzado, como GET, POST, etc. Los valores múltiples se separan por comas.

• allow_headers: Permite que los campos de encabezado personalizados se incluyan en las solicitudes de origen cruzado. Los valores múltiples se separan por comas.

• expose_headers: Especifica los campos de encabezado personalizados que se expondrán en las respuestas de origen cruzado. Los valores múltiples se separan por comas.

• max_age: Establece el tiempo máximo para que el navegador almacene en caché las respuestas de CORS.

• allow_credentials: Determina si se permite llevar credenciales (como Cookies) en las solicitudes de origen cruzado.

Puntos a Considerar

Se debe prestar especial atención al hecho de que, aunque CORS es fácil de usar, habilitarlo puede llevar a problemas de seguridad. Esto se debe principalmente a que CORS relaja las restricciones impuestas por la política de mismo origen, permitiendo que las solicitudes de diferentes orígenes accedan a los recursos.

En este contexto, centrémonos en allow_credentials. allow_credentials es un elemento de configuración crucial en CORS, que determina si las solicitudes de origen cruzado pueden llevar información de autenticación. Esto incluye, pero no se limita a datos sensibles, como cookies, información de autenticación HTTP o certificados SSL de cliente.

Por defecto, allow_credentials está deshabilitado, lo que significa que no permite llevar información de autenticación. Sin embargo, si CORS está habilitado y permite llevar información de autenticación (allow_credentials: true), se debe tener precaución adicional. Esto implica que las solicitudes de otros orígenes también pueden acceder a recursos protegidos, potencialmente ejecutando operaciones sensibles. Por ejemplo, un sitio web malicioso que explote esta vulnerabilidad de configuración podría inducir a los usuarios a iniciar solicitudes de origen cruzado, lo que podría llevar al robo de sus cookies de sesión o a acciones no autorizadas.

Para minimizar los posibles problemas de seguridad al habilitar solicitudes de origen cruzado, se recomienda seguir las siguientes mejores prácticas:

1. Configurar cuidadosamente allow_origin: Evite establecer allow_origin a * (permitir todos los orígenes) indiscriminadamente. En su lugar, especifique explícitamente los orígenes permitidos.
2. Limitar allow_credentials: Habilite allow_credentials solo cuando sea necesario y restríjalo a orígenes confiables.
3. Usar un protocolo de transporte seguro: Asegúrese de que las solicitudes de CORS se transmitan a través de HTTPS para prevenir ataques de intermediario.
4. Validación y autorización: En el servidor backend, implemente verificaciones adecuadas de validación y autorización para las solicitudes de origen cruzado, asegurando que solo los usuarios autorizados puedan acceder a recursos sensibles.
5. Evitar el uso de métodos HTTP inseguros: Restrinja los métodos HTTP utilizados en las solicitudes de origen cruzado, permitiendo solo métodos seguros como GET y POST, mientras deshabilita métodos potencialmente riesgosos como PUT y DELETE, que pueden presentar riesgos de seguridad.

Proxy Inverso

Además de usar CORS, APISIX puede abordar indirectamente los problemas de origen cruzado configurándose como un proxy inverso. Un proxy inverso es un patrón común de arquitectura de servidor donde el servidor proxy inverso actúa como intermediario entre el cliente y el servidor de destino. Cuando un cliente inicia una solicitud, estas solicitudes se envían primero al servidor proxy inverso, que luego las reenvía al servidor de destino real. Una vez que se completa el procesamiento, la respuesta del servidor de destino se devuelve al proxy inverso, que finalmente la pasa de vuelta al cliente.

Es crucial entender que un proxy inverso en sí mismo no resuelve directamente los problemas de origen cruzado, pero elude inteligentemente las restricciones de la política de mismo origen del navegador. Cuando un cliente necesita hacer una solicitud de origen cruzado, en realidad envía la solicitud al servidor proxy inverso en lugar de directamente al servidor de destino. Dado que el servidor proxy inverso y el servidor de destino suelen estar en el mismo entorno de red o configuración, su comunicación no está sujeta a las restricciones de la política de mismo origen. Esto permite que el servidor proxy inverso reenvíe libremente las solicitudes del cliente al servidor de destino y devuelva las respuestas al cliente, logrando indirectamente el objetivo de acceso de origen cruzado.

Como APISIX sirve como una puerta de enlace de API, está inherentemente posicionado para ser implementado entre el cliente y el servidor. Por lo tanto, en aplicaciones de menor escala, implementar la aplicación cliente y APISIX en el mismo dominio y modificar la dirección de solicitud del cliente a la dirección del servicio APISIX garantiza un acceso fluido del cliente a APISIX. Esto puede aprovechar la funcionalidad de proxy inverso para proporcionar acceso de origen cruzado al cliente. Además, se pueden combinar otros plugins para garantizar la seguridad y confiabilidad de todo el proceso de comunicación.

Conclusión

En este artículo, hemos explorado cómo usar APISIX para abordar problemas de origen cruzado, centrándonos en dos métodos: CORS y proxy inverso. Al configurar adecuadamente el plugin CORS, podemos relajar las restricciones de la política de mismo origen impuestas por los navegadores, permitiendo que las solicitudes de origen cruzado accedan a los recursos. Por otro lado, el proxy inverso actúa como intermediario, eludiendo la política de mismo origen de los navegadores y facilitando el acceso de origen cruzado. Cada método tiene sus ventajas, y la elección de la solución adecuada depende de los requisitos específicos. Ya sea empleando CORS o proxy inverso, APISIX ofrece funcionalidades flexibles y potentes, ayudando a los desarrolladores a resolver sin problemas los problemas de origen cruzado y garantizando el funcionamiento normal y la experiencia del usuario de las aplicaciones.