Tengo el problema de que las personas clonan mi sitio web e imitan las llamadas a mi API desde sus propios dominios para abusar de mi servicio. La solución que se me ocurrió es que el cliente Angular verifique la URL en la que funciona, la cifre y la agregue como encabezado a la llamada API. Ofusque el código JS para evitar la ingeniería inversa. De esta manera, la API recibirá un encabezado encriptado y se asegurará de que el dominio sea el correcto.
Así que en el lado del cliente
headers.append(`CustomHeader`, this.encryptDomain());y del lado del servidor
var domainEncrypted = Request.Content?.Headers?.GetValues("CustomHeader").FirstOrDefault(); var domainPlain = Decrypt(domainEncrypted); if (domainPlain != myDomain) { return BadRequest(); } ¿Pueden ayudarme con ejemplos de código para que coincidan con los algoritmos de cifrado y descifrado de JS y C#? Entonces, encryptDomain funciona en el lado de JS y Decrypt funciona en el lado de C#. Soy consciente de que esta no es una solución perfecta, pero quiero intentarlo. Y si alguien tiene una idea mejor, bienvenido sea.
Editar: aparentemente lo que quiero hacer es similar a la función de bloqueo de dominio JScrambler
No es posible evitar la comunicación con su API a través de diferentes clientes (clonados) de manera garantizada en los casos en que las listas blancas de direcciones IP no pueden/no deben usarse.
Piénsalo de esa manera. Tiene un servidor que tiene alguna regla de identificación: el cliente debe tener algún identificador que lo marque como confiable. En tu pregunta es un dominio.
El dominio es una información pública que se puede pasar en el encabezado HTTP o en el cuerpo de su solicitud, es fácil, pero también será fácil para los clientes reemplazar esta información de su lado.
Y si usa cualquier tipo de criptografía para proporcionar un mecanismo de identificación más seguro, solo hace que sea más difícil piratearlo y nuevamente fingir ser un cliente confiable, porque cada mecanismo que usa en el lado del cliente podría ser modificado por ingeniería inversa por un hacker. Solo mira esta pregunta .
Una idea que puede usar para garantizar la restricción de acceso es usar una lista blanca de direcciones IP en el lado del servidor, porque la dirección IP es parte del protocolo de nivel de transporte TCP/IP y tiene un proceso de "apretón de manos" para identificar los puntos comunicados entre sí. , y es un poco difícil reemplazarlo. Verifique esta pregunta para más detalles.
Configurar la política CORS es un primer paso para crear una comunicación cliente-servidor confiable. La mayoría de los navegadores son compatibles con las políticas de CORS, pero, por supuesto, el cliente puede no ser un navegador. Y las preguntas no eran sobre la comunicación entre navegador y servidor, pero debo mencionar eso porque el navegador también es un cliente.
Puede usar el cifrado, pero no veo ninguna razón para hacerlo porque cualquier solicitud al servidor podría leerse a través de su cliente legal (sitio web). Entonces, incluso si lo encriptó, cualquier persona tiene una clave y un algoritmo criptográfico de su lado para pretender ser un cliente confiable. Pero si quieres...
Debe crear una clave única para cada solicitud para hacer la vida de los pretendientes un poco más difícil. Para hacerlo necesitas pocos ingredientes:
Las bibliotecas criptográficas RSA del lado JS se pueden buscar fácilmente en Google ( por ejemplo )
Las bibliotecas de ofuscación también se pueden encontrar usando google (como esta )
El descifrado del lado del servidor se puede realizar con el espacio de nombres System.Security.Cryptography si usa el backend de C#.
Básicamente, el algoritmo de generación de claves más complejo que crea y el código más ofuscado que crea, más difícil para el pirata informático pretender ser un cliente confiable. Pero como dije, no hay una forma garantizada de identificar completamente al cliente confiable.
No puede evitar que las personas copien los activos FE de su sitio web... Se supone que deben estar disponibles públicamente. Podría intentar hacerlo un poco más difícil dividiendo su aplicación integrada en más partes (con la carga diferida de angular o manipulando la configuración del paquete web). Aún así, los navegadores requieren código en texto sin formato, por lo que, aunque esto lo hace un poco más difícil, no evita la copia.
Cuando construimos angular para producción, ya realiza ofuscación de código a través de sus optimizaciones (minificación, sacudida de árboles, etc.).
Para mitigar el problema de que las personas hagan un mal uso de los recursos de su servidor, debe implementar prácticas sólidas en la autorización de solicitudes de back-end y alguna detección de uso indebido.
La configuración de CORS no funcionaría, ya que informó que los atacantes están usando proxies BE.
Asegúrese de que la autenticación de su solicitud sea sólida. Un enfoque estándar del mercado es el uso de una carga útil JWT incrustada en el encabezado de Authorization de cada solicitud. Es simple, confiable y económico en recursos.
También recomendaría la implementación de la regulación de solicitudes . Pero esta es una pregunta aparte.
Si su autenticación ya es sólida, deberá detectar cuándo sus usuarios reales están haciendo un mal uso de su sistema. Existen muchas herramientas para monitorear el tráfico (como Azure ), pero no existe una definición general para "tráfico inusual". La detección de "tráfico inusual" es lo que necesitaría personalizar para las especificaciones de su sistema. Una vez que tenga una herramienta de tráfico de red que debería ayudarlo a comenzar.
Un par de soluciones para ti. En primer lugar, puede bloquear aplicando una política CORS en el servidor. Si aún desea hacerlo desde el código, puede bloquear en base a este nombre de host en c # de esta manera.
var hostname = requestContext.HttpContext.Request.Url.Host; if (hostname != myDomain) { return BadRequest(); }