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:
-
Confundiendo credenciales
-
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)