ajax - headers - cors php
Misma política de origen y CORS(intercambio de recursos de origen cruzado) (2)
Estaba tratando de entender CORS. Según mi entender, es un mecanismo de seguridad implementado en los navegadores para evitar cualquier solicitud de ajax a un dominio que no sea el abierto por el usuario (especificado en la url)
Ahora, debido a esta limitación, se implementaron muchos CORS para permitir que los sitios web realicen solicitudes de origen cruzado. pero según mi entendimiento, la implementación de CORS desafía el propósito de seguridad del SOP de la "Política de origen similar"
CORS es solo para proporcionar control adicional sobre qué servidor de solicitudes quiere servir. Tal vez puede evitar los spammers.
De la Wikipedia :
Para iniciar una solicitud de origen cruzado, un navegador envía la solicitud con un encabezado HTTP de origen. El valor de este encabezado es el sitio que sirvió a la página. Por ejemplo, supongamos que una página en http://www.example-social-network.com intenta acceder a los datos de un usuario en online-personal-calendar.com. Si el navegador del usuario implementa CORS, se enviaría el siguiente encabezado de solicitud:
Origen: http://www.example-social-network.com
Si online-personal-calendar.com permite la solicitud, envía un encabezado Access-Control-Allow-Origin en su respuesta. El valor del encabezado indica qué sitios de origen están permitidos. Por ejemplo, una respuesta a la solicitud anterior contendría lo siguiente:
Access-Control-Allow-Origin: http://www.example-social-network.com
Si el servidor no permite la solicitud de origen cruzado, el navegador enviará un error a la página example-social-network.com en lugar de la respuesta online-personal-calendar.com.
Para permitir el acceso a todas las páginas, un servidor puede enviar el siguiente encabezado de respuesta:
Access-Control-Allow-Origin: *
Sin embargo, esto podría no ser apropiado para situaciones en las que la seguridad es una preocupación.
que me estoy perdiendo aqui? ¿Cuál es la intención de CORS para proteger el servidor y proteger al cliente?
Política del mismo origen
¿Qué es?
La política de origen idéntico es una medida de seguridad estandarizada entre los navegadores. El "origen" se refiere principalmente a un "dominio" . Evita que diferentes orígenes interactúen entre ellos para evitar ataques como la falsificación de solicitudes entre sitios .
¿Cómo funciona un ataque CSRF?
Los navegadores permiten a los sitios web almacenar información en la computadora de un cliente, en forma de cookies. Estas cookies tienen cierta información adjunta, como el nombre de la cookie, cuándo se creó, cuándo expirará, quién configuró la cookie, etc. Una cookie se ve así:
Cookie: cookiename=chocolate; Domain=.bakery.com; Path=/ [// ;otherDdata]
Así que esta es una galleta de chocolate, que debería ser accesible desde http://bakery.com y todos sus subdominios.
Esta cookie puede contener algunos datos confidenciales. En este caso, esa información es ... chocolate . Muy sensible, como puedes ver
Entonces el navegador almacena esta cookie. Y siempre que el usuario haga una solicitud a un dominio en el que se puede acceder a esta cookie, la cookie se enviará al servidor para ese dominio. Servidor feliz.
Ésto es una cosa buena. Una manera genial para que el servidor almacene y recupere información sobre y desde el lado del cliente.
¡Pero el problema es que esto permite que http://malicious-site.com envíe esas cookies a http://bakery.com , sin que el usuario lo sepa! Por ejemplo, considere la siguiente situación:
# malicious-site.com/attackpage
var xhr = new XMLHttpRequest();
xhr.open(''GET'', ''http://bakery.com/order/new?deliveryAddress="address of malicious user"'');
xhr.send();
Si visita el sitio malicioso, y se ejecuta el código anterior, y la política del mismo origen no estaba allí, el usuario malintencionado realizaría un pedido en su nombre, y recibiría el pedido en su lugar ... y es posible que no le guste esto. .
Esto sucedió porque su navegador envió su cookie de chocolate a http://bakery.com , lo que hizo que http://bakery.com pensara que estaba haciendo la solicitud para el nuevo pedido, a sabiendas . Pero no lo eres.
Esto es, en palabras simples, un ataque CSRF. Se realizó una solicitud falsificada en todos los sitios. "Falsificación de solicitudes cruzadas". Y no funcionaría, gracias a la política del mismo origen.
¿Cómo lo soluciona la política del mismo origen?
Impide que malicious-site.com realice solicitudes a otros dominios. Sencillo.
En otras palabras, el navegador no permitiría que ningún sitio realice una solicitud a ningún otro sitio. Evitaría que diferentes orígenes interactuaran entre sí a través de tales solicitudes, como AJAX.
Sin embargo , la carga de recursos de otros hosts como imágenes, scripts, hojas de estilo, iframes, envíos de formularios, etc. no están sujetos a esta limitación. Necesitamos otro muro para proteger nuestra panadería del sitio malicioso, mediante el uso de tokens CSRF .
Fichas CSRF
Como se indicó, el sitio malicioso puede hacer algo como esto sin violar la política de origen mismo:
<img src=''http://bakery.com/order/new?deliveryAddress="address of malicious user"''/>
Y el navegador intentará cargar una imagen desde esa url, dando como resultado una solicitud GET a esa url que envía todas las cookies. Para evitar que esto suceda, necesitamos cierta protección del lado del servidor.
Básicamente, adjuntamos un token aleatorio y único de entropía adecuada a la sesión del usuario, lo almacenamos en el servidor y también lo enviamos al cliente con el formulario. Cuando se envía el formulario, el cliente envía ese token junto con la solicitud, y el servidor verifica si ese token es válido o no.
Ahora que hemos hecho esto, y el sitio web malicioso envía nuevamente la solicitud, siempre fallará, ya que no existe una forma factible para que el sitio web malicioso conozca el token de la sesión del usuario.
CORS
Cuando sea necesario, la política puede evitarse, cuando se requieren solicitudes entre sitios. Esto se conoce como CORS . Intercambio de recursos Cross Origin.
Esto funciona haciendo que los "dominios" le indiquen al navegador que se enfríe y permita tales solicitudes. Esto de "decir" se puede hacer pasando un encabezado. Algo como:
Access-Control-Allow-Origin: //comma separated allowed origins list, or just * Entonces, si http://bakery.com pasa este encabezado al navegador, y la página que crea la solicitud a http://bakery.com es presente en la lista de origen, el navegador dejará ir la solicitud, junto con las cookies.
Hay reglas según las cuales el origen está definido 1 . Por ejemplo, diferentes puertos para el mismo dominio no son del mismo origen. Entonces, el navegador puede rechazar esta solicitud si los puertos son diferentes. Como siempre, nuestro querido Internet Explorer es la excepción a esto. IE trata a todos los puertos de la misma manera. Esto no es estándar y ningún otro navegador se comporta de esta manera. No confíes en esto
JSONP
JSON con relleno es solo una forma de eludir la política del mismo origen, cuando CORS no es una opción. Esto es arriesgado y una mala práctica. Evita usar esto.
Lo que implica esta técnica es hacer una solicitud al otro servidor de la siguiente manera:
<script src="http://badbakery.com/jsonpurl?callback=cake"></script>
Como la política del mismo origen no impide esta solicitud 2 , la respuesta de esta solicitud se cargará en la página.
Esta url probablemente respondería con contenido JSON. Pero solo incluir ese contenido JSON en la página no ayudará. Por supuesto, daría lugar a un error. Así que http://badbakery.com acepta un parámetro de devolución de llamada, y modifica los datos JSON, enviándolo envuelto en lo que se pase al parámetro de devolución de llamada.
Entonces, en lugar de regresar,
{ user: "vuln", acc: "B4D455" }
que es JavaScript no válido lanzando un error, volvería,
cake({user: "vuln", acc:"B4D455"});
que es JavaScript válido, se ejecutará y probablemente se almacenará en algún lugar de acuerdo con la función de cake , de modo que el resto de JavaScript en la página pueda usar los datos.
Esto es utilizado principalmente por las API para enviar datos a otros dominios. De nuevo, esta es una mala práctica, puede ser riesgoso y debe evitarse estrictamente.
¿Por qué es JSONP malo?
En primer lugar, es muy limitado. No puede manejar ningún error si la solicitud falla (al menos no de manera sensata). No puede volver a intentar la solicitud, etc.
También requiere que tenga una función de cake en el alcance global que no sea muy buena. Que los cocineros lo salven si necesita ejecutar múltiples solicitudes JSONP con diferentes devoluciones de llamada. Esto se resuelve mediante funciones temporales de varias bibliotecas, pero sigue siendo una forma de hackear de hacer algo hackish.
Finalmente, está insertando código JavaScript aleatorio en el DOM. Si no está 100% seguro de que el servicio remoto le devolverá los pasteles seguros, no puede confiar en esto.
Referencias
1. https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin
2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details
Otras lecturas dignas
http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html
http://tools.ietf.org/html/rfc3986 (lo siento: p)
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
La misma política de origen (SOP) es la política que implementan los navegadores para evitar vulnerabilidades a través de Cross Site Scripting (XSS). Esto es principalmente para proteger el servidor, ya que hay muchas ocasiones en las que un servidor puede estar lidiando con autenticación, cookies, sesiones, etc.
Cross Origin Resource Sharing (CORS) es una de las pocas técnicas para relajar el SOP. Como el SOP está "activado" de forma predeterminada, al configurar CORS en el lado del servidor permitirá que se envíe una solicitud al servidor a través de XMLHttpRequest, incluso si la solicitud se envió desde un dominio diferente. Esto se vuelve útil si su servidor fue diseñado para servir solicitudes de otros dominios (por ejemplo, si está proporcionando una API).
Espero que esto aclare la distinción entre SOP y CORS y los propósitos de cada uno.