El original XHR nunca fue diseñado para permitir solicitudes de origen cruzado. La razón era una vulnerabilidad de seguridad tangible que se conoce principalmente por CSRF attacks.
En este escenario de ataque, un sitio de terceros puede obligar a un agente de usuario de la víctima a enviar solicitudes falsas pero válidas y legítimas al sitio de origen. Desde la perspectiva del servidor de origen, dicha solicitud falsificada no es indiscernible de otras solicitudes de ese usuario que fueron iniciadas por las páginas web del servidor de origen. La razón de esto es porque en realidad es el agente de usuario el que envía estas solicitudes y también incluiría automáticamente cualquier credencial, como cookies, autenticación HTTP e incluso certificados SSL del lado del cliente.
Ahora estas solicitudes se pueden falsificar fácilmente: comenzando con simples solicitudes GET usando <img src="…"> hasta solicitudes POST usando formularios y enviándolos automáticamente.Esto funciona siempre y cuando sea predecible cómo forjar tales solicitudes válidas.
Pero esta no es la razón principal para prohibir las solicitudes de origen cruzado para XHR. Porque, como se muestra arriba, hay formas de falsificar solicitudes incluso sin XHR e incluso sin JavaScript. No, la razón principal por la que XHR no permitió las solicitudes de origen cruzado es porque sería el JavaScript en la página web del tercero al que se enviaría la respuesta. Por lo tanto, no solo sería posible enviar solicitudes de origen cruzado sino también recibir la respuesta que pueda contener información confidencial a la que luego accedería el JavaScript.
Es por eso que la especificación original XHR no permitió solicitudes de origen cruzado. Pero a medida que la tecnología avanza, hubo solicitudes razonables para apoyar solicitudes de origen cruzado. Es por eso que la especificación XHR original se extendió a XHR level 2 (XHR y XHR nivel 2 ahora están fusionados) donde la extensión principal es para admitir solicitudes de origen cruzado bajo requisitos particulares que se especifican como CORS. Ahora el servidor tiene la capacidad de verificar el origen de una solicitud y también puede restringir el conjunto de orígenes permitidos, así como el conjunto de métodos HTTP permitidos y campos de encabezado.
Ahora en JSONP: para obtener la respuesta JSON de una solicitud en JavaScript y poder procesarla, debería ser una solicitud de origen idéntico o, en el caso de una solicitud de origen cruzado, su servidor y el agente de usuario necesitaría soportar CORS (del cual este último solo es compatible con los navegadores modernos). Pero para poder trabajar con cualquier navegador, se inventó JSONP que es simplemente una llamada de función de JavaScript válida con el JSON como un parámetro que se puede cargar como un JavaScript externo a través de <script> que, similar a <img>, no está restringido al mismo origen peticiones. Pero además de cualquier otra solicitud, una solicitud JSONP también es vulnerable a CSRF.
Así que para concluir que desde el punto de vista de la seguridad: se requiere
- XHR para realizar solicitudes de recursos de JSON para obtener sus respuestas en JavaScript
- XHR2/CORS se requiere para hacer las solicitudes de origen cruzado por los recursos de JSON para obtener sus respuestas en JavaScript
- JSONP es una solución para eludir las solicitudes de origen cruzado con XHR
Pero también:
- solicitudes de forja es de risa fácil, aunque forjar las solicitudes válidas y legítimas es más difícil (pero a menudo bastante fácil así)
- ataques CSRF son un no deben subestimar la amenaza, por lo que aprender a protect against CSRF
Pertenece a http://security.stackexchange.com/ – Knu