Exponer API protegida sin credenciales de codificación en el Cliente (JS)

0

Intente exponer la API REST protegida sin exponer las credenciales en el Cliente (Código JS).

Todas las soluciones que vienen a mi mente, pueden revertirse y el atacante puede reconstruirlos.

¿Hay soluciones probadas? ¿Mejores prácticas?

Ideas, surgí por ejemplo:

  1. Confundiendo credenciales

  2. Hashing conjunto de elementos del lado del cliente y comparación del lado del servidor con asegúrese de que el Cliente no esté tocado (no es utilizado por el Atacante)

se puede revertir.

Lamentablemente, la autenticación HTTPS no entra en juego, ya que el sitio web que accede a la API REST (Cliente, Código JS) debe estar abierto al público. No puedo solicitar a cada Cliente (visitante del sitio web) que solicite un PKC (Certificado de clave pública)

HTTPS Client Authentication

HTTPS Client Authentication requires the client to possess a Public Key 
Certificate (PKC). 
If you specify client authentication, the web server will authenticate the 
client using the client’s public key certificate.
HTTPS Client Authentication is a more secure method of authentication than 
either basic or form-based authentication. It uses HTTP over SSL (HTTPS), 
in which the server authenticates the client using the client’s Public Key 
Certificate (PKC). Secure Sockets Layer (SSL) technology provides data encryption,
server authentication, message integrity, and optional client authentication for a 
TCP/IP connection. You can think of a public key certificate as the digital 
equivalent of a passport. It is issued by a trusted organization, which 
is called a certificate authority (CA), and provides identification for 
the bearer.

Quiero evitar que las personas obtengan credenciales y rasguen / realicen muchas solicitudes a la API REST.

Supongo que nuestra única solución es que la limitación basada en IP. Para castigar a los malos clientes.

Gracias de antemano!

Actualización 1:

Después de las discusiones con @ThoriumBR, se le ocurrió esta solución. No es óptimo, pero debería ser mejor que nada.

Diseño :

Sitio web del cliente < - > Nueva API (proxy) < - > API antigua

Flow:

Envuelva la API antigua (privada) contra la nueva API (pública, en el diagrama anterior Proxy)

1) El sitio web del cliente realiza una solicitud de proxy

2) El proxy envía CAPCHA de vuelta

3) Sitio web del cliente completo CAPCHA

4) El proxy crea JWT (asigna capcha intrval en JWT, por ejemplo, como 10 (capcha_int: 10), asigna deviceid: fingerprint (para conocer a los usuarios de la misma IP)) lo envía de vuelta al sitio web del cliente. El proxy también verifica el abuso, si Deviceid se está comportando mal, será bloqueado.

5) Sitio web Enviar solicitud a Proxy con JWT

6) Proxy check JWT, si el intervalo de capcha (capcha_int) es igual a 10 enviar CAPCHA, lo restablece, si se comporta mal, si no, envía la solicitud a la API antigua

7) el viejo Api envía una respuesta a través de Proxy al sitio web del cliente

Las IP se basarán en IP para el abuso. (segunda capa para prevenir el abuso)

    
pregunta android_dev 20.08.2018 - 14:57
fuente

0 respuestas

Lea otras preguntas en las etiquetas