Binary Coffee

¬ŅQu√© es el intercambio de recursos de origen cruzado (CORS)?

chrome cors firefox
En el art√≠culo de [JWT](https://binary-coffee.dev/post/conociendo-jwt-desde-dentro) se explica al inicio c√≥mo funcionaban las sesiones en en un sitio web basado en **Cookies**, y c√≥mo los navegadores son los encargados de almacenar estas **Cookies** y enviarlas en cada petici√≥n al servidor como un adjunto de la petici√≥n en s√≠. Y este es posiblemente el m√©todo que a trav√©s de los a√Īos m√°s se ha utilizado para el manejo de las sesiones de los usuarios. Sobre todo en aplicaciones monol√≠ticas, donde b√°sicamente toda la l√≥gica ocurre del lado del servidor, por tanto es la √ļnica manera de identificar al usuario. Esto indudablemente fue la mejor soluci√≥n con la que se contaba hasta el momento y todos los navegadores soportaban este intercambio de datos. Pero as√≠ como las **Cookies** permitieron el uso de sesiones en la web, tambi√©n abrieron la puerta a una vulnerabilidad que puede parecer inofensiva, pero no lo es. Partiremos inicialmente del concepto **Same-Origin Policcy** (SOP) o en espa√Īol **Pol√≠tica de Seguridad del mismo Origen**. Donde el navegador proh√≠be estrictamente que se carguen datos de dominios ajenos al que se encuentra el usuario. B√°sicamente todos los datos deben provenir de la misma fuente. Y entonces se preguntar√°n, que resolvemos con esto. Pues imaginen el caso en el cual el usuario se autentica en su p√°gina de banco, ejemplo en la siguiente imagen: ![](https://api.binary-coffee.dev//uploads/cdae5c7423894500aa958c9a19238e78.png) Luego contin√ļa navegando por la Internet y entra al sitio *evil-web.com*, y este sitio peculiar, hace la siguiente petici√≥n: ![](https://api.binary-coffee.dev//uploads/ddf371636acf4ca0bf00fd3e4f421fea.png) Ya no parece tan agradable el sitio no? Pues como las **Cookies** se almancenan en el navegador, cualquier petici√≥n que se haga a un sitio, el navegador autom√°ticamente adjunta las **Cookies** almacenadas para dicho sitio. Permitiendo que como en el ejemplo anterior, un sitio malicioso reutilice la sesi√≥n de la cuenta del usuario en el banco, para transferir dinero sin que el usuario lo notara. Pero c√≥mo resolver este problema? Si sabemos que en la actualidad un sitio consume informaci√≥n de diversos lugares al mismo tiempo. Esta petici√≥n a un dominio que no es el del sitio actual se conoce como **Petici√≥n de Origen Cruzado**, y como definimos anteriormente, los navegadores se rigen por el concepto **SOP**. Pero con **CORS** (Cross-Origin Resourse Sharing) o en espa√Īol **Intercambio de Recursos de Origen Cruzado**, esto se puede resolver. B√°sicamente lo que se necesita es una manera en la cual el navegador pueda saber si el sitio que intenta hacer la petici√≥n est√° autorizado por el destino de dicha petici√≥n. ## Entonces ¬Ņqu√© ocurre cuando se hace la petici√≥n de recursos cruzados? Se muestra en la siguiente imagen el flujo de una petici√≥n cruzada: ![](https://api.binary-coffee.dev//uploads/da6af8a3480b4b86b3388601d0928ef1.png) Como se puede notar el navegador siempre realiza una petici√≥n de control antes de la petici√≥n real (usualmente un **OPTIONS**), con lo cual chequea los dominios permitidos por dicho servidor, y permite o deniega al dominio actual. Si el navegador encuentra problemas de permisos, autom√°ticamente lanza un error como respuesta de la petici√≥n JavaScript. ## ¬ŅPero c√≥mo los servidores permiten o no a un sitio hacer una petici√≥n de origen cruzada? Esto se logra por medio de cabeceras que se env√≠an en el *header* de cada respuesta. Para el caso de **CORS**, hay un listado de cabeceras definidas, que todos los navegadores conocen y son las siguientes: * **Access-Control-Allow-Origin**: Listado de or√≠genes permitido * **Access-Control-Allow-Credentials**: Permite env√≠o de **Cookies** (que es donde habitan las sesiones) * **Access-Control-Max-Age**: Tiempo de validez de la petici√≥n * **Access-Control-Allow-Methods**: M√©todos HTTP permitidos * **Access-Control-Expose-Headers**: Cabeceras que pueden mostrarse * **Access-Control-Request-Method**: ¬ŅQu√© m√©todo de petici√≥n HTTP se indica en la solicitud preflight? usualmente **OPTIONS** * **Access-Control-Allow-Headers**: Cabeceras que pueden utilizarse * **Access-Control-Request-Headers**: ¬ŅQu√© header HTTP se indica en la solicitud? * **Origin**: Origen de la solicitud La primera cabecera es la m√°s importante debido a que especifica desde qu√© dominios se puede acceder, tambi√©n puede contener un asterisco **(*)** expresando que permite peticiones de cualquier origen. ## Resumen - Si tu sistema hace usos de sesiones por medio de **Cookies**, es un buen momento para habilitar **CORS** en tu servidor. - Sistemas que utilizan **JWT** o otros m√©todos de sesiones, no corren el riesgo de peticiones cruzadas. - Todo paso para mejorar la seguridad, aunque parezca trivial, puede significar la diferencia en que tu sistema sea vulnerado o no. # Referencias - [Art√≠culo en developer.mozilla.org](https://developer.mozilla.org/es/docs/Web/HTTP/Access_control_CORS) - [Art√≠culo en dzone.com](https://dzone.com/articles/do-you-really-know-cors) > Keep calm and drink Binary Coffee!
Opiniones