¿Cuándo la política del mismo origen impide que se envíe una solicitud?

3

He estado lidiando con algunas confusiones sobre la política del mismo origen.

Digamos que mi ataque se ve así. En la página en evil.com que el atacante ha puesto (jQuery):

$.post('http://bank.com/transfer', { to: 'ciro', ammount: '100' })

El atacante lo convence de visitar evil.com .

¿Se seguirá ejecutando esta carga útil (jQuery)? ¿Enviaría una solicitud o lanzaría un error sin enviar la solicitud?

Estoy comparando esto con XMLHttpRequest donde la solicitud por lo menos va pero la respuesta no se puede leer debido a violaciones de la política del mismo origen. En caso de violación de SOP, ¿la solicitud siempre viaja al servidor? ¿Hay casos en los que SOP impida que se envíe la solicitud y la detecte antes?

    
pregunta H4X 11.12.2016 - 04:47
fuente

1 respuesta

4
  

¿Enviaría una solicitud o lanzaría un error sin enviar la solicitud?

Se enviaría tu solicitud POST . Sin embargo, la política del mismo origen impide que se pueda leer la respuesta. Al igual que un envío de formulario normal, es un tipo de escritura de origen cruzado . Aquí hay una descripción general de Mozilla :

  
  • Por lo general, se permiten writes de origen cruzado. Los ejemplos son enlaces, redirecciones y envíos de formularios. Ciertas solicitudes HTTP rara vez utilizadas   requiere verificación previa .
  •   
  • Por lo general, se permite inclusión de origen cruzado. Los ejemplos se enumeran a continuación.
  •   
  • Por lo general, no se permiten lecturas de origen cruzado, pero el acceso de lectura a menudo se filtra mediante incrustaciones. Por ejemplo puedes leer el ancho y   altura de una imagen incrustada, las acciones de un script incrustado, o la    disponibilidad de un recurso incorporado .
  •   

En su escenario, la solicitud desencadenaría una acción involuntaria (una transferencia bancaria). Este tipo de ataque se llama falsificación de solicitud entre sitios (CSRF). Para evitar esto, los desarrolladores deben tomar contramedidas de manera activa, como la implementación de tokens CSRF .

  

¿Hay casos en los que SOP impida que se envíe la solicitud y   lo atrapa antes?

Sí. Por ejemplo, no puede especificar métodos distintos a GET , POST y HEAD de forma predeterminada. Otros métodos deben permitirse explícitamente utilizando una técnica llamada intercambio de recursos entre orígenes (CORS ). Es por eso que los métodos personalizados a veces se usan como una alternativa (cuestionable) a los tokens CSRF.

Para permitir un método personalizado FOO desde cualquier origen, el servidor podría responder con estos encabezados:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: FOO

Aquí es cómo Google Chrome rechaza una solicitud con el método FOO a https://www.google.com :

Puedeverqueelnavegadorenvíaprimerouna preflight OPTIONS para verificar qué métodos están permitidos a través de CORS. Luego, el servidor responde con un estado 405 , lo que indica que no se permite FOO , y la solicitud completa falla.

    
respondido por el Arminius 11.12.2016 - 05:51
fuente

Lea otras preguntas en las etiquetas