socket - Cómo asegurarse de que mis solicitudes AJAX se originan en el mismo servidor en Python
metodo recv python (8)
Como sugirió Venkatesh Bachu, Same Origin Policy y http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing (CORS) se podrían usar como una solución. En su API, puede verificar el encabezado de Origen y responder en consecuencia. Es necesario comprobar si el encabezado de origen se puede modificar utilizando extensiones como datos de manipulación. Un pirata informático determinado aún puede husmear apuntando el navegador a un servidor proxy local.
Ya he hecho una pregunta sobre la autenticación de IP aquí: Autenticación de TastyPie desde el mismo servidor
Sin embargo, necesito algo más! Una dirección IP podría ser muy fácil de falsificar.
Escenario: Mi API (TastyPie) y la aplicación de cliente (en javascript) están en el mismo servidor / sitio / dominio. Mis usuarios no inician sesión. Quiero consumir mi API en el lado de mi cliente javascript.
Pregunta: ¿Cómo puedo asegurarme (autenticación) de que mis solicitudes AJAX se originan en el mismo servidor ?
Estoy usando Tatypie. Necesito autenticar que las solicitudes del cliente se realizan en el mismo servidor / dominio, etc. No puedo usar "sesiones iniciadas" ya que mis usuarios no inician sesión.
He mirado las claves privadas y generando una firma, pero pueden verse en el javascript haciendo que el método sea inseguro. Si lo hago de una manera para solicitar una firma del servidor (ocultando la clave privada en algún código de Python) cualquiera puede hacer la misma solicitud http para get_signature que mi javascript, derrotando así el punto.
También intenté que la vista Django pusiera la firma en la vista, eliminando la necesidad de hacer la llamada get_signature. Esto es seguro, pero significa que ahora tengo que actualizar la página cada vez para obtener una nueva firma. Desde el punto de vista de los usuarios, solo la primera llamada a la API funcionaría, después de lo cual deben actualizarse, nuevamente sin sentido.
No puedo creer que soy la única persona con este requisito. Este es un escenario común, estoy seguro. Por favor, ayuda :) Un ejemplo de autenticación personalizada en Tastypie también sería bienvenido.
Gracias
Adicional:
Dependiendo de su infraestructura, la respuesta de @ dragonx puede interesarle más.
mi 2c
¿Quiere asegurarse de que solo si un cliente visita su sitio web puede usar la API? Hmm, ¿el robot, el robot y el rastreador se ubican en la misma categoría que el cliente? ¿O me equivoco? Esto puede ser fácilmente explotado en caso de que realmente quiera asegurarlo realmente.
No puedo creer que soy la única persona con este requisito.
Tal vez no, pero como puedes ver, eres propenso a varios ataques a tu API y eso puede ser una razón para que alguien no comparta tu diseño y haga que la seguridad sea más estricta con la autenticación.
EDITAR
Ya que estamos hablando de solicitudes de AJAX, ¿qué tiene que ver la parte de IP con esto? ¡La IP siempre será la IP del Cliente ! Así que probablemente, quieres una API pública ...
Iría con la parte de tokens / session / cookie.
Iría con un token generado que dura un poco y un flujo que se describe a continuación.
Iría con un limitador por algún tiempo, como hace Github . Por ejemplo, 60 solicitudes por hora por ip o más para usuarios registrados.
Para superar el problema con el token refrescante, simplemente haría esto:
El cliente visita el sitio
-> servidor genera API TOKEN INIT
-> El cliente obtiene la API TOKEN INIT que es válida solo para iniciar una solicitud.
El cliente realiza una solicitud de AJAX a la API
-> El cliente usa API TOKEN INIT
-> Verificaciones del servidor contra API TOKEN INIT y límites
-> Servidor acepta solicitud
-> El servidor devuelve la API TOKEN
-> El cliente consume datos de respuesta y almacena la API TOKEN para su uso posterior (se almacenará en la memoria del navegador a través de JS)
El cliente comienza a comunicarse con la API por un tiempo o solicitudes limitadas . Observe que también conoce la fecha del token de inicio para poder usarla para verificar la primera visita en la página.
El primer token se genera a través del servidor cuando el cliente visita. Luego, el cliente usa ese token para obtener uno real, que dura un tiempo u otra cosa como limitación. Esto hace que alguien realmente visite la página web y luego pueda acceder a la API por un tiempo límite, quizás solicitudes, etc.
De esta manera no necesitas refrescarte.
Por supuesto, el escenario anterior podría simplificarse con un solo token y un límite de tiempo como se mencionó anteriormente.
Por supuesto, el escenario anterior es propenso a los rastreadores avanzados, etc., ya que no tiene autenticación.
Por supuesto, un atacante inteligente puede tomar tokens del servidor y repetir los pasos, pero entonces ya tenía ese problema desde el principio.
Algunos puntos extra
- Como los comentarios proporcionados por favor cierre las escrituras a la API. No desea ser víctima de los ataques de DOS con escrituras si tiene dudas sobre su implementación (si no usa auth) o por seguridad adicional
- El escenario de token descrito anteriormente también puede complicarse, por ejemplo, intercambiando tokens constantemente.
Solo como referencia, el almacenamiento en la nube de GAE utiliza signed_urls para el mismo propósito.
Espero eso ayude.
PD. En cuanto a la suplantación de IP y la defensa contra los ataques de suplantación, wikipedia dice que los paquetes no serán devueltos al atacante:
Algunos protocolos de capa superior ofrecen su propia defensa contra los ataques de suplantación de IP. Por ejemplo, el Protocolo de control de transmisión (TCP) utiliza números de secuencia negociados con la máquina remota para garantizar que los paquetes que llegan forman parte de una conexión establecida. Como el atacante normalmente no puede ver ningún paquete de respuesta, el número de secuencia debe ser adivinado para poder secuestrar la conexión. Sin embargo, la implementación deficiente en muchos sistemas operativos y dispositivos de red más antiguos significa que se pueden predecir los números de secuencia TCP.
Hay dos tipos de soluciones generales: soluciones en banda que utilizan mecanismos de servidor / cliente web normales, que son fáciles de implementar pero tienen limitaciones; y soluciones fuera de banda que dependen de usted para configurar algo externo, que requieren un poco más de trabajo pero no tienen las mismas limitaciones que en la banda.
Si prefiere una solución en banda, el enfoque típico utilizado para evitar la falsificación de solicitudes entre sitios (XSRF) funcionaría bien. El servidor emite un token con una vida útil limitada; el cliente usa el token en las solicitudes; la privacidad del token está (más o menos asegurada) mediante el uso de una conexión HTTPS. Este enfoque se usa ampliamente y funciona bien a menos que esté preocupado por los ataques de intermediarios que podrían interceptar el token, o los navegadores con errores que podrían filtrar datos a otro código del lado del cliente que está siendo malo.
Puede eliminar esas limitaciones, si está motivado, mediante la introducción de certificados de cliente. Esta es la otra cara de los certificados SSL que todos usamos en los servidores web: operan de la misma manera, pero se usan para identificar al cliente en lugar del servidor. Debido a que el certificado en sí nunca pasa por el cable (usted lo instala localmente en el navegador u otro cliente), no tiene las mismas amenazas de las personas que están en el medio y las fugas del navegador. Esta solución no se usa mucho en la naturaleza porque su configuración es confusa (muy confuso para el usuario típico), pero si tiene un número limitado de clientes y están bajo su control, entonces sería factible implementar y administrar este número limitado de certificados de clientes. Las operaciones de certificado son manejadas por el navegador, no en el código del cliente (es decir, no en JavaScript), por lo que su preocupación sobre los datos clave visibles en JavaScript no se aplicaría en este escenario.
Por último, si desea omitir la tontería de la configuración del cliente, use la solución definitiva fuera de banda: iptables o una herramienta similar para crear un firewall a nivel de aplicación que solo permita sesiones que se originan en las interfaces de red (como bucle de retorno local) que sabes con certeza no se puede acceder desde la caja.
Puede ser que puedas lograr esto usando la política del mismo origen.
Si es puramente el mismo servidor, puede verificar las solicitudes contra 127.0.0.1 o localhost.
De lo contrario, la solución es probablemente a nivel de red, para tener una subred privada separada con la que pueda verificar. Debería ser difícil para un atacante falsificar su subred sin estar en su subred.
Si este servidor de aplicaciones se ejecuta en un servidor web normal que tiene una dirección IP de escucha configurable, configúrelo en 127.0.0.1. Con el módulo TCPServer, es como
SocketServer.TCPServer(("127.0.0.1", 12345), TheHandlerClass)
Use el comando netstat para verificar que la dirección de escucha sea correcta como "127.0.0.1"
tcp4 0 0 127.0.0.1.12345 *.* LISTEN
Esto hará que cualquier conexión originada fuera del mismo host sea imposible en el nivel TCP.
Supongo que estás un poco confundido (o lo estoy, corrígeme). Que su código JS se publique en el mismo servidor que su API no significa que las solicitudes AJAX provendrán de su servidor. Los clientes descargan el JS de su servidor y lo ejecutan, lo que da como resultado solicitudes a su API enviadas desde los clientes, no desde el mismo servidor .
Ahora, si el escenario anterior describe correctamente su caso, lo que probablemente está tratando de hacer es proteger su API del raspado de bots . La protección más fácil es CAPTCHA, y puedes encontrar más ideas en la página Wiki.
Si le preocupa que otros sitios puedan realizar llamadas AJAX a su API para copiar la funcionalidad de su sitio, no debería hacerlo: las solicitudes AJAX solo pueden enviarse al mismo servidor que la página en la que se está ejecutando JS, a menos que sea JSONP .
Respuesta corta: No es posible prevenir a un atacante dedicado.
No tiene un método para identificar a un cliente que no sea con la información que le proporcionan. Por ejemplo, la autenticación de nombre de usuario / contraseña funciona bajo el supuesto de que solo un cliente válido podría proporcionar credenciales válidas. Cuando alguien inicia sesión, todo lo que sabe es que alguna persona le proporcionó esas credenciales; usted asume que esto significa que esto significa que es un usuario legítimo.
Echemos un vistazo a su escenario aquí, como lo entiendo. El único método que tiene para autenticar a un cliente es la dirección IP, una forma de autenticación muy débil . Como dijo, esto puede ser fácilmente falsificado, y con un poco de esfuerzo, la respuesta de su servidor puede ser recibida de nuevo en la dirección IP original del atacante. Si esto sucede, no puedes hacer nada al respecto. El hecho es que, si asume que alguien de una dirección IP válida es un usuario válido, los falsificadores y los usuarios legítimos no se pueden distinguir. Esto es como si alguien robara su contraseña e intentara iniciar sesión en . Para , el atacante y usted no se pueden distinguir, ya que todo lo que tienen que hacer es el nombre de usuario y la contraseña.
Puede hacer cosas elegantes con el cliente como se menciona en otras respuestas, como tokens, límites de tiempo, etc., pero un atacante dedicado podría imitar las acciones de un cliente legítimo, y usted no podría decirles aparte porque ambos parecen ser de direcciones IP válidas. Por ejemplo, en su último ejemplo, si yo fuera un atacante que buscaba hacer llamadas a la API, falsificaría una dirección IP legítima, obtendría la firma y la utilizaría para hacer una llamada a la API, como lo haría un cliente legítimo.
Si su aplicación es lo suficientemente crítica como para considerar este nivel de pensamiento en seguridad, al menos debe pensar en implementar algo como tokens de API, cifrado de clave pública u otros métodos de autenticación que sean más seguros que las direcciones IP para diferenciar a sus clientes de cualquier atacante. . La autenticación por dirección IP (u otros tokens fácilmente forjados como el nombre de host o los encabezados) simplemente no la cortarán.