¿Cors está ayudando de alguna manera contra la falsificación entre sitios?

Comenzaré mi respuesta diciendo que muchas personas entienden mal la Política del mismo origen y qué CORS trae a la mesa.

Algunas de las respuestas más votadas que ya están aquí indican que la Política del mismo origen evita las solicitudes entre sitios y, por lo tanto, impide que CSRF . Este no es el caso. Todo lo que hace el SOP es evitar que la respuesta sea leída por otro dominio (también conocido como origen). Esto es irrelevante para que un ataque CSRF tenga éxito o no.

La única vez que el SOP entra en juego con CSRF es evitar que un dominio diferente lea un token.

Todo lo que hace CORS es relajar el SOP cuando está activo. No aumenta la seguridad, simplemente permite que se realicen algunas excepciones. Algunos navegadores con compatibilidad parcial con CORS permiten solicitudes XHR entre sitios (por ejemplo, IE 10 y versiones anteriores), sin embargo, no permiten que los encabezados personalizados ser anexado En los navegadores compatibles con CORS, el encabezado Origin no se puede configurar, lo que evita que un atacante pueda falsificar esto.

Mencioné que los dominios eran orígenes diferentes. Los orígenes también pueden diferir según el puerto y el protocolo cuando se habla de solicitudes AJAX (no tanto con las cookies).

Finalmente, todo lo anterior no tiene nada que ver con las solicitudes falsificadas que provienen directamente de un atacante, por ejemplo con curl. Recuerde que el atacante debe usar el navegador de la víctima para atacar. Necesitan el navegador para enviar automáticamente sus cookies. Esto no se puede lograr mediante una solicitud de curvatura directa, ya que esto solo sería autenticar al atacante en este tipo de escenario de ataque (la categoría conocida como "ataques del lado del cliente").

El beneficio de CORS es que permite que su dominio permita lecturas de otro dominio de confianza. Entonces, si tiene http://data.example.org , puede configurar los encabezados de respuesta para permitir que http://site.example.com realice solicitudes AJAX y recupere datos de su API.

Estás mezclando las cosas. CORS no pretende proteger su aplicación de solicitudes http creadas , sino protegerlo de un cierto tipo de ataques que "roba" las cookies o tokens de acceso del usuario, al verificar qué sitios pueden acceder a su recurso. .

Se utiliza principalmente para proteger su servidor / aplicación de la falsificación de solicitudes entre sitios, donde un sitio malicioso realizará una solicitud en nombre del usuario, posiblemente con intentos maliciosos (cambio de credenciales, transferencia de dinero ...), explotando el De hecho, el navegador enviará cualquier cookie de inicio de sesión y sesión que aún esté activa y sea válida para su sitio.

Si CORS está configurado correctamente, la solicitud ajax del sitio del atacante se rechazará, ya que, de forma predeterminada, solo aceptará solicitudes del mismo sitio.

Esto NO significa que no debes desinfectar tus entradas , y solo te protege de un cierto tipo de ataques CSFR. En caso de que el atacante obtenga las cookies / tokens de acceso de su usuario, se le otorgará acceso de todos modos, y es por eso que la mayoría de los procesos de autenticación deben usar SSL como una capa adicional de protección.

PS: Esto supone que el navegador que usa tu usuario está actualizado, no tiene fallas y obedece correctamente la misma política de origen.

EDITAR: En cuanto a las solicitudes de verificación previa, esta es una medida adicional para asegurarse de que se le otorgue acceso al sitio, y no se realiza para todas las solicitudes de origen cruzado

  

He estado leyendo en los últimos días sobre CORS y en muchos   de los lugares que se menciona, ya que es una característica de "Seguridad" para ayudar al   mundo de la falsificación de dominios cruzados.

Usted malinterpretó los beneficios de CORS o puede haber leído que en algunos blogs de amateur realizados por desarrolladores que están más preocupados por cómo hacer que funcione que < em> cómo hacerlo seguro (si entiendes lo que quiero decir), porque CORS hace que tu aplicación web sea vulnerable a tales ataques ( CSRF ) cuando abre solicitudes de origen cruzado desde el origen del atacante utilizando CORS con el siguiente encabezado: Access-Control-Allow-Origin: *

  

¿Cómo está ayudando CORS y en qué beneficia?

CORS nació para aliviar las restricciones del SOP para confianza solicitudes sólo . Pero los problemas comienzan exactamente con esa confianza . Un atacante podría hacer daño a través de los origins forjando solicitudes maliciosas a través de métodos GET y POST, por ejemplo, y puede expóngalo incluso Reenlazado de DNS

En cuanto a esta parte,

  

los navegadores realizarán una solicitud de verificación previa / el servidor validará el origen. Pero un atacante puede crear fácilmente un HttpRequest de arriba a abajo con los Encabezados (Origen) que quiera y tendrá acceso al recurso.

De enlace

  

Además, para los métodos de solicitud HTTP que pueden causar efectos secundarios en los datos del usuario (en particular, para métodos HTTP distintos de GET, o para el uso de POST con ciertos tipos MIME), la especificación exige que los navegadores "revisen" la solicitud solicitar métodos admitidos desde el servidor con un método de solicitud de OPCIONES HTTP, y luego, una vez "aprobado" desde el servidor, enviar la solicitud real con el método de solicitud HTTP real. Los servidores también pueden notificar a los clientes si se deben enviar las "credenciales" (incluidas las cookies y los datos de autenticación HTTP) con las solicitudes.

Por lo que sé, si utiliza métodos HTTP como 'PUT' en lugar de 'POST' y porque hace una solicitud de dominio cruzado usando 'PUT' ya que el método especificado siempre será precedida por una solicitud de verificación previa al vuelo para ver si se permite el Origen, esto puede prevenir ataques en ciertas situaciones. Esto se debe a que el atacante no puede falsificar el origen, ya que los navegadores modernos no permiten los lenguajes de scripting del lado del cliente, como Javascript para establecer el 'Origen' o cualquier encabezado personalizado dominio cruzado, el ataque fallará .

Espero que haya ayudado.