11
votes

PHP: système anti-inondation / spam

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) .

  • Les serveurs Web d'aujourd'hui (Apache, IIS) ont-ils une sorte de défense intégrée contre la force brute?
  • 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.

    • 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)

    • devrais-je utiliser captchas pour des choses comme l'enregistrement / la récupération de mots de passe perdus?

    • est "Texte" CAPTCHAS viable? (Quelque chose comme "Qu'est-ce que 5 Plus 9 Moins 2?")

    • La page ne sera pas utilisée par de nombreux utilisateurs (100-200), dois-je réellement mettre en œuvre toutes ces choses?


0 commentaires

6 Réponses :


5
votes
  1. Oui, stocker une adresse IP, l'accès des derniers accessibles et les heures d'accès dans une base de données iraient bien.
  2. Utilisation de captChas pour le registre / la récupération du mot de passe est conseillé pour que les adresses de messagerie ne puissent être spammées. Aussi pour arrêter la forçage brute.
  3. Oui, les CAPTCHAS TEXT sont possibles, bien que beaucoup plus facilement pour que quelqu'un craque et écrit un script pour automatiser la réponse. Pour un CAPTCHA gratuit, je recommanderais RECAPTCHA .
  4. Cela dépend vraiment de la quantité de sécurité de la sécurité. Je recommanderais certainement d'utiliser un CAPTCHA car ils sont simples à mettre en œuvre.

1 commentaires

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.



-1
votes

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.

reCAPTCHA est en effet une bonne solution.


0 commentaires

0
votes

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.


0 commentaires

-1
votes

Bien sûr, votre public cible pourrait ne pas être grand, mais si c'est dans le domaine public, il est vulnérable,

Texte CAPTCHA's sont fissurés facilement ces jours-ci me croire

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


0 commentaires

21
votes

concernant CAPTCHAS: Je recommanderais de l'utiliser à l'aide de CAPTCHAS à moins que vous n'ayez vraiment besoin. Pourquoi?

  1. c'est moche.
  2. C'est agaçant pour vos utilisateurs. Vous ne devriez pas les faire sauter à travers des cerceaux pour utiliser votre site.

    Il existe certaines alternatives très simples, peuvent être très efficaces et sont entièrement transparentes pour (presque tous) utilisateurs. < ol>

  3. Honeypot champs : ajoutez un champ à vos formulaires avec un nom commun comme "site". À côté de cela, ajoutez une étiquette disant quelque chose à l'effet de "N'écrivez pas dans cette case". Utilisation JavaScript Masquer l'entrée et l'étiquette. Lorsque vous recevez une soumission de formulaire, s'il y a quelque chose dans le champ, rejeter l'entrée.

    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.

  4. Faux-CAPTCHA automatique : 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.

    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.

    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.


    Concernant le blocage de la force brute: 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.

    L'algorithme est assez simple, mais un peu déroutant initialement.

    1. L'utilisateur demande une action (réinitialiser le mot de passe, par exemple)
    2. Run: Supprimer * de brute_force où expire
    3. exécution: XXX

    4. Si le compte est supérieur à x , dis-leur d'attendre un moment.
    5. sinon, exécutez: XXX

    6. Continuez avec la fonction de réinitialisation du mot de passe.

      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.


0 commentaires

2
votes

N'essayez pas de mettre en œuvre tout la logique de votre PHP - plus dans votre pile que vous pouvez la mettre en œuvre, plus il peut être traité efficacement.

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.

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é.

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.

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 exactement de la même manière si l'utilisateur soumet une adresse e-mail inconnue. Enregistrer les adresses e-mail non valides.

htth

c.


0 commentaires