Estoy profundizando en el desarrollo de API RESTful y hasta ahora he trabajado con algunos marcos diferentes para lograr esto. Por supuesto, me he encontrado con la política del mismo origen, y ahora me pregunto cómo los servidores web (en lugar de los navegadores web) la aplican. Por lo que entiendo, parece que se aplica algo al final del navegador (por ejemplo, honrar un encabezado Access-Control-Allow-Origin recibido de un servidor). ¿Pero qué hay del servidor?
Por ejemplo, supongamos que un servidor web aloja una aplicación web Javascript que accede a una API, también alojada en ese servidor. Supongo que el servidor aplicaría la política del mismo origen, de modo que solo el javascript alojado en ese servidor podría acceder a la API. Esto evitaría que alguien más escriba un cliente de JavaScript para esa API y lo aloje en otro sitio, ¿verdad? Entonces, ¿cómo podría un servidor web detener a un cliente malintencionado que intentaría realizar solicitudes AJAX a sus puntos finales API mientras afirmaba estar ejecutando JavaScript que se originó en ese mismo servidor web? ¿Cuál es la forma en que los servidores más populares (Apache, nginx) protegen contra este tipo de ataque? ¿O entiendo esto de alguna manera fuera de lugar?
¿O la política de origen cruzado solo se aplica en el extremo del cliente?
fuente
Respuestas:
La misma política de origen es una restricción totalmente basada en el cliente, y está diseñada principalmente para proteger a los usuarios , no a los servicios . Todos o la mayoría de los navegadores incluyen un interruptor de línea de comando u opción de configuración para desactivarlo. El SOP es como los cinturones de seguridad en un automóvil: protegen al conductor del automóvil, pero cualquiera puede elegir libremente no usarlos. Ciertamente , no espere que el cinturón de seguridad de una persona les impida salir de su automóvil y atacarlo (o acceder a su servicio web).
Supongamos que escribo un programa que accede a su servicio web. Es solo un programa que envía mensajes TCP que incluyen solicitudes HTTP. Está solicitando un mecanismo del lado del servidor para distinguir entre las solicitudes realizadas por mi programa (que puede enviar cualquier cosa) y las solicitudes realizadas por un navegador que tiene una página cargada desde un origen permitido. Simplemente no se puede hacer; mi programa siempre puede enviar una solicitud idéntica a una formada por una página web.
La política del mismo origen se inventó porque evita que el código de un sitio web acceda a contenido restringido por credenciales en otro sitio. Las solicitudes de Ajax se envían de forma predeterminada con las cookies de autenticación otorgadas por el sitio de destino. Por ejemplo, supongamos que cargo accidentalmente
http://evil.com/, lo que envía una solicitud dehttp://mail.google.com/. Si el SOP no estaba en su lugar, y me registraron en Gmail, el script enevil.compodría ver mi bandeja de entrada. Si el sitioevil.comquiere cargarsemail.google.comsin mis cookies, solo puede usar un servidor proxy; los contenidos públicos demail.google.comno son secretos (pero los contenidos demail.google.comcuando se accede con mis cookies son secretos).fuente
La política del mismo origen se aplica en el lado del cliente. Si el navegador admite CORS , el servidor puede enviar encabezados que le indiquen que haga excepciones a la política del mismo origen. Por ejemplo, enviando el encabezado
le diría al navegador que permita solicitudes de origen cruzado de www.example.com.
le dice al navegador que permita todas las solicitudes de origen cruzado a ese recurso.
fuente
Los servidores web generalmente evitan ataques de este tipo al verificar la línea (infamemente mal escrita)
Refereren el encabezado HTTP, para garantizar que una solicitud provenga de una página en su propio sitio. No hay una buena manera de protegerse contra un cliente malicioso, pero no es así como funcionan los ataques XSRF.El cliente no es malicioso; generalmente es un usuario común que ha sido engañado por un tercero malintencionado para que abra un documento que silenciosamente realiza una solicitud HTTP utilizando las cookies almacenadas del cliente. Entonces, si el servidor puede verificar a través de
Refererque la solicitud HTTP proviene de gmail.com, y no de MyAwesomeWebsite.com, puede cerrar el ataque.fuente
Refererlínea es generada por el navegador web del usuario, y el usuario es la víctima aquí, no el atacante. No tiene ninguna razón para forjarloReferer, y el atacante no tiene la oportunidad de hacerlo.En resumen, no lo hacen, como apuntaron Apsillers y Dirk .
Una razón importante es que el encabezado ACAO protege los propios servidores de DDOS desenfrenados, ataques de denegación distribuida de servicio .
Quien:
El ACAO como encabezado de respuesta HTTP está destinado a que el cliente web sea interpretado, operando bajo el supuesto de que la mayoría de los usuarios humanos de Internet navegan por la web a través de los principales proveedores de navegadores que se adhieren e implementan el borrador recomendado por el W3C . Después de todo, la mayoría de ellos deberían beneficiarse de una Internet rápida y accesible.
Cómo:
De lo contrario, cualquiera podría simplemente copiar y pegar unas pocas líneas de código JavaScript en un sitio web malicioso que ejecuta un bucle simple, lo que hace que la solicitud de Ajax GET o POST a un dominio extranjero. Sin interacción del usuario, y la capacidad de multihilo.
Es por eso que debe optar por acceder a un sitio de origen cruzado, a través del encabezado HTTP ACAO . Usted, el usuario, puede acceder a dicho sitio en cualquier momento a través de una interacción consciente del usuario, es decir, un enlace a Internet. Al igual que usted puede copiar o pegar el contenido de su portapapeles, pero no de otra manera, aparte de los complementos.
Futuro:
En ese punto, preste atención a la dirección del fabricante del navegador web de:
Las restricciones de seguridad se pueden establecer decentemente utilizando una combinación de TSL 2/3, ID de sesión fuertes, TAN, autenticación de dos factores, etc.
'Google' tiene esto para mostrar y decir sobre DDOS
Por último, cualquier persona es libre de usar proxy para cualquier contenido web y agregar un encabezado ACAO deseado para acceder al contenido entre sitios proxy. Del mismo modo, este proxy está entonces tan abierto a un ataque DDOS, como lo permite la configuración ACAO. De hecho, no conozco una sola oferta de servicio público gratuito. Por favor, corríjame si estoy equivocado.
fuente
Como otros dijeron, depende del cliente. Pero el servidor puede necesitar lidiar con XSS, que evita SOP.
Supopse su servidor permite a los usuarios cargar contenido, que se muestra cuando otros usuarios navegan por su sitio. Esta página es un buen ejemplo: acabo de subir contenido y se le muestra.
Si mi contenido contiene la
<script>etiqueta y el servidor simplemente lo copia en el HTML que genera, se ejecutará el script que cargué.Como el script se encontró en HTML desde su archivo, tiene todos los permisos del script de su sitio. Puede, por ejemplo, votar esta respuesta. Y es por eso que esta respuesta tiene tantos votos positivos.
Un buen servidor web (como, por desgracia, el que usa StackExchange), no permitirá que esto suceda. Puede eliminar la
<script>etiqueta o escapar de ella, por lo que se verá pero no se ejecutará (advertencia: esta respuesta está lejos de ser una receta confiable para evitar XSS).Por lo tanto, es el lado del cliente el que impone el SOP, pero en algunos casos el servidor debería funcionar para evitar eludirlo.
fuente