security - sirve - ¿Cómo aseguro las llamadas a la API REST?
qué es una api rest y para qué sirve (5)
Establezca una SESIÓN var en el servidor cuando el cliente primero carga su
index.html(obackbone.jsetc.)Compruebe esta var en el lado del servidor en cada llamada API.
¡PD, esta no es una solución de "seguridad"! Esto es solo para facilitar la carga en su servidor para que la gente no abuse de él ni "enlace" su API desde otros sitios web y aplicaciones.
Estoy desarrollando una aplicación web relajante que usa algún framework web popular en el backend, por ejemplo (rails, sinatra, flask, express.js). Idealmente, quiero desarrollar el lado del cliente con Backbone.js. ¿Cómo dejo que mi lado del cliente de JavaScript interactúe con esas llamadas API? No quiero que esas llamadas API sean públicas y se llamen por curl o simplemente ingresando el enlace en el navegador.
Como primer principio, si su cliente JS consume su API, debe suponer que es pública: un simple depurador JS pone a un atacante en una posición, donde puede enviar una solicitud idéntica de byte por byte desde un herramienta de su elección.
Dicho esto, si leo su pregunta correctamente, esto no es lo que quiere evitar: lo que realmente no quiere que suceda es que su API se consuma (de forma regular) sin que su cliente JS participe. Aquí hay algunas ideas sobre cómo hacer para no hacer cumplir, al menos alentar a usar su cliente:
Estoy seguro de que su API tiene algún tipo de campo de autenticación (por ejemplo, Hash calculado en el cliente). Si no, echa un vistazo a esta pregunta . Asegúrese de utilizar una sal (o incluso la clave API) que se le da a su cliente JS en una sesión (no codificada). De esta forma, un consumidor no autorizado de su API se ve obligado a trabajar mucho más.
Al cargar el cliente JS, recuerde algunos encabezados HTTP (el agente de usuario viene a la mente) y la dirección IP y solicite la reautenticación si cambian, empleando listas negras para los sospechosos habituales. Esto obliga a un atacante a hacer su tarea más a fondo de nuevo.
En el lado del servidor, recuerde las últimas pocas llamadas a la API, y antes de permitir otra, verifique si la lógica comercial permite la nueva en este momento: esto le niega a un atacante la capacidad de concentrar muchas de sus sesiones en una sola sesión con su servidor: combinación con las otras medidas, esto hará que un abusador sea fácilmente detectable.
Puede que no lo haya dicho con la claridad necesaria: considero que es imposible hacer que sea completamente imposible para un abusador consumir su servicio, pero puede hacerlo tan difícil que puede no valer la pena.
Deberías implementar algún tipo de sistema de autenticación. Una buena forma de manejar esto es definir algunas variables de encabezado esperadas. Por ejemplo, puede tener una llamada de API de autenticación / inicio de sesión que devuelva un token de sesión. Las llamadas subsiguientes a su API esperarán que un token de sesión se establezca en una variable de encabezado HTTP con un nombre específico como ''your-api-token''.
Alternativamente, muchos sistemas crean tokens de acceso o claves que se esperan (como youtube, facebook o twitter) utilizando algún tipo de sistema de cuenta api. En esos casos, su cliente tendría que almacenarlos de alguna manera en el cliente.
Entonces, simplemente es cuestión de agregar un cheque para la sesión en su marco REST y lanzar una excepción. Si es posible, el código de estado (para estar tranquilo) sería un error 401.
Disculpe @MarkAmery y Eugene, pero eso es incorrecto.
Su aplicación js + html (cliente) que se ejecuta en el navegador PUEDE estar configurada para excluir llamadas directas no autorizadas a la API de la siguiente manera:
- Primer paso: configure la API para que requiera autenticación. El cliente primero debe autenticarse a través del servidor (u otro servidor de seguridad), por ejemplo, solicitando al usuario humano que proporcione la contraseña correcta.
Antes de la autenticación, las llamadas a la API no son aceptadas.
Durante la autenticación, se devuelve un "token".
Después de la autenticación, solo se aceptarán llamadas API con el "token" de autenticación.
Por supuesto, en esta etapa, solo los usuarios autorizados que tengan la contraseña pueden acceder a la API, aunque si son programadores que depuran la aplicación, pueden acceder a ella directamente para fines de prueba.
- Segundo paso: ahora configure una API de seguridad adicional, que debe ser llamada dentro de un límite de tiempo corto luego de que la aplicación js + html del cliente se haya solicitado inicialmente al servidor. Esta "devolución de llamada" le indicará al servidor que el cliente se descargó con éxito. Restrinja las llamadas a la API REST para que funcionen solo si el cliente fue solicitado recientemente y con éxito.
Ahora, para usar su API, primero deben descargar el cliente y, de hecho, ejecutarlo en un navegador. Solo después de recibir con éxito la devolución de llamada, y luego la entrada del usuario dentro de un corto período de tiempo, la API aceptará llamadas.
Así que no tiene que preocuparse de que este sea un usuario no autorizado sin credenciales.
(El título de la pregunta, ''¿Cómo aseguro las llamadas a la API REST'', y de la mayoría de lo que dices, es tu mayor preocupación, y no la pregunta literal de CÓMO se llama a tu API, sino más bien POR QUIEN, correcto? )
Hay un estándar abierto ahora llamado "JSON Web Token",
ver https://jwt.io/ & https://en.wikipedia.org/wiki/JSON_Web_Token
JSON Web Token (JWT) es un estándar abierto basado en JSON (RFC 7519) para crear tokens que afirman cierto número de reclamaciones. Por ejemplo, un servidor podría generar un token que tenga el reclamo "iniciado sesión como administrador" y proporcionarlo a un cliente. El cliente podría usar ese token para demostrar que está conectado como administrador. Los tokens están firmados por la clave del servidor, por lo que el servidor puede verificar que el token sea legítimo. Los tokens están diseñados para ser compactos, seguros para URL y utilizables especialmente en el contexto de inicio de sesión único (SSO) del navegador web. Los reclamos de JWT se pueden usar para pasar la identidad de los usuarios autenticados entre un proveedor de identidades y un proveedor de servicios, o cualquier otro tipo de reclamo según lo requieran los procesos de negocios. [1] [2] Los tokens también pueden ser autenticados y encriptados. [3] [4]