Je travaille réellement sur un projet PHP qui comportera un système utilisateur (identifiant, registre, envoyer un mot de passe perdu au courrier électronique ..) Et je pense que cela peut être très vulnérable aux attaques et / ou au spam brute. (Envoyez un mot de passe à l'email de quelqu'un comme 1000 fois, etc. Utilisez votre fantasme) . p>
Quel serait le meilleur moyen de mettre en œuvre un système anti-spam / inondation, si je par exemple: Vous voulez qu'une page ne puisse pas être appelée plus de deux fois par minute, mais une autre page peut être appelée à 100 fois une minute ou plus. P>
Je devrais certainement stocker des adresses IP, le moment où ils ont visité une page et le nombre de visites quelque part - mais seraient-ils suffisamment efficaces le stockant dans une base de données / base de données (MySQL) p> li>
devrais-je utiliser captchas pour des choses comme l'enregistrement / la récupération de mots de passe perdus? p> li>
est "Texte" CAPTCHAS viable? (Quelque chose comme "Qu'est-ce que 5 Plus 9 Moins 2?") P> Li>
La page ne sera pas utilisée par de nombreux utilisateurs (100-200), dois-je réellement mettre en œuvre toutes ces choses? P> LI> ul> li> ul>
6 Réponses :
Je suis d'accord avec votre réponse n ° 4. Un nombre limité d'utilisateurs peut l'utiliser, mais si un spammer / attaquant découvre une faille sur le site, elles pourraient utiliser toute vulnérabilité qu'ils trouvent dans les systèmes ci-dessus.
Stockage des adresses IP est une bonne pratique pour la connexion et le suivi, mais je pense que juste un captcha cesserait le spam, les attaques brute-force et les inondations. p>
reCAPTCHA est en effet une bonne solution. P>
En plus de faire ce que Gazler vous dit, vous devriez également avoir un moyen de compter les tentatives de connexion en général. Le total de toutes les tentatives de connexion sont plus importantes puis x puis commencez à utiliser la commande veille ou simplement à dire que les serveurs ont une charge élevée. P>
Bien sûr, votre public cible pourrait ne pas être grand, mais si c'est dans le domaine public, il est vulnérable, P>
Texte CAPTCHA's sont fissurés facilement ces jours-ci me croire p>
Pour un système anti-spam / inondation, vous pouvez enregistrer des adresses IP (MySQL de préférence) et ajouter une limite de délai de distribution p>
Il existe certaines alternatives très simples, peuvent être très efficaces et sont entièrement transparentes pour (presque tous) SUB> EM> utilisateurs. P> < ol>
Les utilisateurs avec JS ne le voient pas et ira bien. Les utilisateurs sans JS devront simplement suivre l'instruction simple. Les spambots tomberont pour cela et se révéleront. P> li>
Faux-CAPTCHA automatique strong>: Ceci est similaire à ce qui précède. Ajouter un champ d'entrée avec une étiquette indiquant "Ecrivez" Alex "" (par exemple). Utilisation de JavaScript (et sachant que la plupart des robots de spams automatisés ne seront pas exécutés JS), cachent le champ et le peupler avec 'Alex'. Si le formulaire soumis n'a pas le mot magique là-bas, ignorez-le. P>
Les utilisateurs avec JS ne le voient pas et ira bien. Les utilisateurs sans JS devront simplement suivre l'instruction simple. Les spambots ne sauront pas quoi faire et vous pouvez ignorer leur entrée. P> li>
ol> Cela vous protégera de 99,9% des bots de spam automatisés. Ce qu'il ne fera pas, même le moindre, vous sauvegarder contre une attaque ciblée. Quelqu'un pourrait personnaliser leur bot pour éviter le cheympot ou toujours remplir la valeur correcte. P> Concernant le blocage de la force brute: strong> Une solution côté serveur est le seul moyen viable de le faire évidemment. Pour l'un de mes projets actuels, j'ai mis en place un système de protection brute de la force très similaire à ce que vous décrivez. Il était basé sur ce Plugin de protection de la force brute pour CakePHP. P > L'algorithme est assez simple, mais un peu déroutant initialement. P> exécution: p>
sinon, exécutez: p>
Ceci permettra aux utilisateurs de ne réinitialiser que la réinitialisation d'un mot de passe x fois en y des minutes. Modifiez ces valeurs comme vous le voyez. Peut-être que 3 réinitialise en 5 minutes? De plus, vous pouvez avoir des valeurs différentes pour chaque action: pour certaines choses (par exemple: générer un PDF), vous voudrez peut-être le limiter à 10 minutes en 10 minutes. P> P>
Supprimer * de brute_force où expire
x code>, dis-leur d'attendre un moment. Li>
N'essayez pas de mettre en œuvre La plupart des pare-feu (y compris les IPtables sur BSD / Linux) ont un étranglement de connexion. En outre, jetez un coup d'œil à mod_security pour la prévention des attaques DDO / Brute Force. P>
vous devrait concevoir votre application autour de l'idée que ces types d'attaques ne donneront pas à l'attaquant l'accès à l'application - à la fin de la journée, vous ne pouvez pas empêcher une attaque DOS, bien que Vous pouvez limiter son efficacité. P>
Il n'y a pas beaucoup de valeur à s'appuyer sur une adresse IP cohérente de votre attaquant - il y a beaucoup de façons de se déplacer cela. P>
E.g. Gardez une trace du nombre de demandes de réinitialisation du mot de passe entre les connexions par chaque utilisateur. Dans votre formulaire de réinitialisation du mot de passe, répondez (au client) dans htth p>
c. p>