Je ne comprends pas cette explication et à mon avis, elle peut être évitée en appliquant la sécurité dès la conception dans le processus de conception. À mon avis, une augmentation de 5,4 millions d’appels api devrait vraiment être un motif d’alerte, surtout si vous voyez dans l’URL qu’il s’agit de demandes de connexion.
Bien sûr, en chiffres absolus, les demandes supplémentaires peuvent ne pas être absorbées par la surveillance en raison du nombre de connexions qui ont lieu chaque jour. En même temps, quel utilisateur de Twitter devrait se connecter plus que je ne sais pas (je n’ai pas de chiffres) 10 comptes par heure à partir d’une adresse IP donnée ?
Ensuite, la limitation du débit sur une telle API aiderait déjà, la surveillance et l’alerte lorsque quelqu’un dépasse la valeur X par Y fois pourraient aider.
De plus, vous pouvez également regarder l’intervalle entre les tentatives de connexion, les scripts préfèrent fonctionner les uns après les autres, donc avec une légère déviation due à la congestion Internet/serveur occupé/client lent, vous pouvez surveiller ces modèles et y connecter des actions. Bien sûr, un randomiseur qui fournit une valeur aléatoire à chaque fois pour une fonction de sommeil entre les demandes est fait de cette façon, mais le fait est que vous essayez de capturer autant de risques que possible en matière de sécurité.
Ce n’est toujours pas étanche, mais la plupart des pirates qui vont écrire un script de force brute ne pourront pas / ne prendront pas la peine de changer leur adresse IP de requête toutes les X fois.