security - ¿Por qué no hay verificación previa en CORS para solicitudes POST con tipo de contenido estándar?

same-origin-policy preflight

Question

Estoy un poco confundido acerca de los aspectos de seguridad de las solicitudes CORT POST. Sé que hay una pérdida de información sobre este tema en línea, pero no pude encontrar una respuesta definitiva a mis preguntas.

Si lo entendí correctamente, el objetivo de la política del mismo origen es evitar los ataques CSRF y el objetivo de CORS es habilitar el uso compartido de recursos si (y solo si) el servidor acepta compartir sus datos con aplicaciones alojadas en otros sitios (orígenes) ).

HTTP especifica que las solicitudes POST no son "seguras", es decir, podrían cambiar el estado del servidor, por ejemplo, agregando un nuevo comentario. Al iniciar una solicitud CORS con el método HTTP POST, el navegador solo realiza una solicitud de verificación previa "segura" si el tipo de contenido de la solicitud no es estándar (o si hay encabezados http no estándar). Por lo tanto, las solicitudes POST con encabezados estándar y de tipo de contenido se ejecutan y pueden tener efectos secundarios negativos en el servidor (aunque la respuesta puede no ser accesible para el script de solicitud).

Existe esta técnica de agregar un token aleatorio a cada formulario, que el servidor luego debe ser parte de cada solicitud que no sea segura. Si un script intenta falsificar una solicitud,

1. no tiene el token aleatorio y el servidor rechaza la solicitud, o
2. intenta acceder al formulario donde se define el token aleatorio. Esta respuesta con el token aleatorio debe tener los campos de encabezado apropiados, de modo que el navegador no otorgue acceso al script malvado a esta respuesta. También en este caso el intento falla.

Mi conclusión es que la única protección contra las solicitudes POST falsificadas con encabezados y tipo de contenido estándar es la técnica descrita anteriormente (o una similar). Para cualquier otra solicitud que no sea segura, como PUT o DELETE, o un POST con contenido json, no es necesario usar la técnica porque CORS realiza una solicitud de OPCIONES "segura".

¿Por qué los autores de CORS excluyeron estos POST exentos de las solicitudes de verificación previa y, por lo tanto, hicieron necesario emplear la técnica descrita anteriormente?

Answer 1

Consulte CORS: ¿Cuál es la motivación detrás de la introducción de solicitudes de verificación previa? y otras respuestas allí.

La razón por la que CORS no requiere que los navegadores realicen una verificación previa para los tipos de contenido application/x-www-form-urlencoded , multipart/form-data o text/plain es que si lo hiciera, eso haría a CORS más restrictivo que lo que los navegadores ya han permitido (y no es la intención de CORS poner nuevas restricciones a lo que ya era posible sin CORS).

Es decir, con CORS, las solicitudes POST que podría hacer anteriormente no tienen verificación previa, ya que los exploradores ya las permitieron antes de que existiera CORS y los servidores las conocían. Entonces, CORS no cambia nada sobre esos tipos de solicitudes "antiguas".

Pero antes de CORS, los navegadores no le permitirían hacer una application/json origen cruzado application/json POST, por lo que los servidores podrían asumir que no los recibirían. Es por eso que se requiere una verificación previa de CORS para esos tipos de solicitudes "nuevas" y no para las "antiguas"; para informar al servidor de que se trata de una solicitud "nueva" diferente a la que deben optar explícitamente. en el apoyo.