auth - Asegurar la API REST no autenticada
yii2 rest api (4)
He estado leyendo sobre la seguridad de API REST y he leído sobre oAuth y JWT. Ambos son realmente buenos enfoques, pero por lo que he entendido, ambos funcionan después de que un usuario se autentica o, en otras palabras, "inicia sesión". Esto se basa en las credenciales de los usuarios. Se generan oAuth y JWT, y una vez que se obtiene el token o el JWT oAuth, el usuario puede realizar todas las acciones para las que está autorizado.
Pero mi pregunta es, ¿qué pasa con las API de inicio de sesión y registro? ¿Cómo puede uno protegerlos? Si alguien lee mis archivos javascript para ver mis llamadas ajax, pueden encontrar fácilmente los puntos finales y los parámetros aprobados, y podrían golpearlo varias veces a través de algún cliente REST, más severamente podrían codificar un programa que llegue a mi API de registro. decir miles de veces, lo que sería crear miles de usuarios de correo no deseado, o incluso podría obligar a la fuerza de la API de inicio de sesión. Entonces, ¿cómo uno los asegura?
Estoy escribiendo mi API en yii2.
El framework Yii 2.0 tiene un filtro yii/filters/RateLimiter llamado yii/filters/RateLimiter que implementa un algoritmo de limitación de velocidad basado en el algoritmo del cubo con fugas . Le permitirá limitar el número máximo de solicitudes aceptadas en un determinado intervalo de tiempo. Como ejemplo, puede limitar los puntos finales tanto de inicio de sesión como de inicio de sesión para aceptar como máximo 100 llamadas API dentro de un intervalo de tiempo de 10 minutos. Cuando se excede ese límite, se yii/web/TooManyRequestsHttpException una yii/web/TooManyRequestsHttpException ( código de estado 429 ).
Puede leer más sobre esto en la documentación relacionada con Yii2 RESTful API o dentro de esta publicación SO .
Hasta ahora no lo uso, pero de lo que sí lo leí en los documentos oficiales, y me refiero a esto:
Tenga en cuenta que yii/filters/RateLimiter requiere $user para implementar los yii/filters/RateLimitInterface . RateLimiter no hará nada si $user no está configurado o no implementa yii/filters/RateLimitInterface .
Supongo que fue diseñado para funcionar con los usuarios que iniciaron sesión solo utilizando la tabla de base de datos relacionada con el usuario, la predeterminada que se introdujo en la plantilla avanzada. No estoy seguro, pero sé que necesita almacenar el número de solicitudes permitidas y la marca de tiempo relacionada a algún almacenamiento persistente dentro del método saveAllowance que deberá definir en la clase de usuario. Por lo tanto, creo que tendrá que rastrear a sus usuarios invitados por direcciones IP ya que @LajosArpad sí sugirió, tal vez, rediseñar su clase de usuario para mantener sus identidades para que pueda habilitarlo.
Una búsqueda rápida en Google me permitió yii2-ip-ratelimiter a esta extensión: yii2-ip-ratelimiter a la que también puede echarle un vistazo.
Para javascript, debe usar el flujo OAuth 2.0 Implicit Grant como Google o Facebook.
El inicio de sesión y la inscripción usan 2 páginas web básicas. No olvides agregar captcha para ellos.
Para algunos clientes especiales, como aplicaciones móviles o webServer:
Si está seguro de que su archivo binario es seguro, puede crear una API de inicio de sesión personalizada para él. En esta API debes intentar verificar tu cliente.
Una solución simple, puede referirse:
- utilice un algoritmo de encriptación como AES o 3DES para cifrar la contraseña del cliente, use una clave secreta (solo el cliente y el servidor lo saben)
- utilice un algoritmo hash como sha256 para hash (nombre de usuario + tiempo del cliente + otra clave secreta). El cliente enviará el tiempo del cliente y la cadena hash al servidor. El servidor rechazará la solicitud si la hora del cliente es muy diferente de la del servidor o si la cadena hash no es correcta.
P.ej:
api/login?user=user1&password=AES(''password'',$secret_key1)&time=1449570208&hash=sha256(''user1''+''|''+''1449570208''+''|''+$secret_key2)
Nota: En cualquier caso, el servidor debe usar captcha para evitar el ataque de fuerza bruta. No crea en ningún otro filtro.
Sobre captcha para REST APIs, podemos crear captcha base en token.
P.ej.
Para la acción de registro: debe llamar a 2 api
- / getSignupToken: para obtener la URL de imagen captcha y una ficha de registro, respectivamente.
- / registrarse: para publicar datos de registro (incluye token de registro y captcha escritos por el usuario)
Para la acción de inicio de sesión: podemos requerir captcha por conteo fallido inicios de sesión base en nombre de usuario
Sigue mi módulo de API aquí para referencia. Gestiono la autenticación del usuario mediante el token de acceso. Cuando inicio de sesión, genero token, luego accedo de nuevo, el cliente necesita enviar token y el servidor comprobará.
Sus URL serán fácilmente determinadas. Debería tener una lista negra de direcciones IP y cuando una dirección IP actúe sospechosamente, simplemente agréguela a la lista negra. Usted define qué es sospechoso, pero si no está seguro, puede comenzar con lo siguiente:
Cree algo así como una tabla de base de datos con este esquema:
ip_addresses (ip, is_suspicious, login_attempts, register_attempts)
Where is_suspicious significa que está en la lista negra. login_attemtps y register_attempts deben ser valores json, mostrando el historial de esa dirección IP tratando de iniciar sesión / registrarse. Si los últimos 20 intentos no tuvieron éxito y estuvieron dentro de un minuto, entonces la dirección IP debe estar en la lista negra. Las direcciones IP incluidas en la lista negra deberían recibir una respuesta de que están en la lista negra sea cual sea su solicitud. Entonces, si niegan sus servicios o intentan piratear cosas, entonces les niega sus servicios.
Contraseñas seguras usando sha1, por ejemplo. Ese algoritmo es lo suficientemente seguro y es más rápido que sha256, por ejemplo, que podría ser una exageración. Si su API involucra cuentas bancarias o algo extremadamente importante como eso, lo suficientemente importante como para que los malos usen parques de servidores para hackearlo, entonces obligue a los usuarios a crear contraseñas muy largas, incluyendo números, caracteres especiales, letras grandes y pequeñas.