Forum d'entraide PHPFrance

Bonjour tout le monde ...

Actuellement, je redéveloppe mon site. Tout ce qui est formulaire est, pour le moment, fait par javascript, avec une demande token (clé unique) puis la transmission de ce token avec les données du formulaire. Peu de risques pour les bots donc ...

Pour des raisons d'éthique & esthétique, je me refuse au captcha même si c'est bien la solution ultime à mon sens (bloque les bots et les hackers (voir la suite).

Mais voilà, si une personne mal intentionnée crée un script qui reproduit ce que fait JavaScript (en AJAX), alors la sécurité n'est plus assurée.

Quelles sont les éventuelles solutions ? Un système anti force brute pour la zone de connexion (en identifiant le login attaqué) ? Un système de comptage de nombre de mails envoyés par minute et par heure pour les inscriptions et le formulaire de contact ? Au risque de pénaliser les autres le temps de l'attaque ?

Merci d'avance.

Hello,

Tu peux appliqué tes dernières sécurité par IP, c'est déjà ça de fait !

Bonjour,
si vous ne souhaitez pas mettre en place un captcha, vous pouvez utilisez une demande de réponse textuelle à un problème. Même principe que le captcha mais plus accessible.

Par exemple :
indiquez combien font 45 -13 : <input text>
Quel est la couleur du cheval blanc d'Henri IV : <input text>

La demande étant bien évidement aléatoire

Quel est la couleur du cheval blanc d'Henri IV : <input text>

c'est une question piège celle la, personne comprend la vrai blague

http://www.carrefour.fr/contact/question/
http://www.fnaim.fr/mon-projet/inscription.html

Et j'en passe ... aucun ne possède de captcha. Pourtant, si je traffique un script, il devrait y avoir moyen des les flooder, que ce soit en email ou en inscription ... sans parler des adresses e-mail en clair (mais là ils sont fous c'est le nature ...).

Sinon un mini captcha résoudrait TOUUUUUSSSS mes problèmes ... mais d'un, ça m'oblige à redimensionner mes cadres (lol), et deux je ne sais pas ...

alllleezz

Non mais déja je doute qu'une personalité comme Henry IV n'ait qu'un seul cheval.

salut

perso, je suis aussi un peu ... skyzo !... et pour mettre bagarré avec un casse-Noisette sur un de mes site, j'ai fait un truc qui jusqu'ici fonctionne !

cryptage des noms des champs avec une variable conservée en session ... puis décryptage à l'upload pour extraire les données ...le temps qu'i mette en place sont script ... ben il ne fonctionne plus !...

pour contrer les IP, il faut déjà interdire les upload de formulaire par proxy .. ça vire plein de chieurs et pour les autre, tu les blackLists ... !


@++

Oui mais s'il fait en sorte que son application renouvelle la page à chaque fois pour connaitre le nom des champs ? Moi c'est le même problème, il est obligé d'appeler une page qui renseigne un token et de poster le formulaire avec le token, sinon ça ne fonctionne pas. Un bot classique n'y arrivera pas, mais un mec qui étudie le principe, peut développer un outil. En gros, tout ce qu'un ordinateur utilisateur reçoit pour être capable de faire une action, l'ordinateur du sale mec aussi le reçoit ... par contre l'ordinateur est incapable de déchiffrer les captcha (les vrais ...) alors qu'il est tout à fait possible de hacker un algorithme.

non ?

Salut ,

tu rends tes formulaires uniques ,
si tu peux , tu obliges l'utilisateur à être logué pour poster ,
tu met une limitation de post de formulaire ( en session , cookie ou en base ) par user ou ip
si ce sont des commentaires , tu peux aussi faire passer le contenu via des anti-spam en ligne .. très performants ( plus un spam depuis que j'utilise ce systéme ).

Une autre astuce qu'un internaute a mis en com sur mon blog :

Une autre solution très facile à mettre en place consiste à ajouter un champs input que l'on affiche pas.
Si il est transmis rempli c'est forcément envoyé par un robot.

Apres , il ne faut pas être parano ,
L'intérêt de faire du flood et très bof , les requêtes multiples , sur la même url avec la même ip sont tres simplement détecté et bloquées

Ch.

Bon alors je réitère ma question, comment bloquer les attaques de types DOS (mais pas à faire planter php mais à flooder la bdd ou les emails) .. je m'en fiche des robots, j'avais un site d'annuaire, je recevais des sites bidons c'est pas grave, ce qui serait gênant c'est qu'une personne s'attaque au site donc les input c'est pareil, il peut choisir de ne pas les remplir par son logiciel.

J'avais pensé un moment à vérifier le temps qui s'écoule entre l'ouverture d'un formulaire et sa soumission pour déjà ralentir le mal ... car un formulaire met au moins qq secondes pour être rempli ... sauf que j'ai un formulaire de login, et là je ne peux pas exiger 10 secondes si la personnes est très rapide à rentrer ses identifiants. Mais c'est une idée.

Ensuite, j'avais pensé à un registre des actions, qui vérifie qu'une action n'a pas été effectuée plus de 10 fois dans une minute par exemple, et 60 fois dans une heure, voire moins. Ce qui est largement suffisant pour un site comme le mien qui n'a pas vocation à être visité par plus de 50 personnes par jour.

Ce qui fait en gros, pour la seconde solution, un flood max (flood d'email ou d'enregistrements de compte) de 60 par heure. Ca reste beaucoup, d'autant qu'une fois l'attaque détectée, on ne peut que tout couper, et si le mec continue, rien à faire (contrairement aux captcha qui isole l'utilisateur). Peut-être couplé avec le vérificateur de temps, ça peut déjà ralentir ...

Après, les Ip ... entre les ipv6 et les proxys à gogo ... l'ip n'est pas fiable.


Bon après, il faut que la mesure de sécurité soit proportionnelle au besoin. Ce n'est pas le site de la maison blanche, mais j'aimerais faire le tour de tout ce qui m'est possible de faire

Attaque DOS => cela se fait plus au niveau du serveur qui en général banni l'IP temporairement (ce qui est quasi inutile en cas de DDOS)
pour rappel, une ip n'est pas nécessairement fixe ... et peux représenter plusieurs utilisateurs...


Sinon des solutions existe :
- ajout d'un token (un input hidden avec un jeton généré aléatoirement que tu relie a une session php ou un cookies en db)
- ajout d'un temps maximum et minimum pour poster le formulaire

le coup du registre des actions est intéressant mais lourd, non?



En sécurité, le but est toujours de ralentir l'attaquant, tu ne sais jamais totalement l'arrêter. Bref, mets des embuches mais si tu veux parer des attaques, alors c'est du côté serveur qu'ils faut regarder...

Un fichier .htaccess peut déjà beaucoup (je recommande de lire ceci : http://www.askapache.com/htaccess/htaccess.html )

sinon il y a ceci : http://fr.php-firewall.info/ mais j'ignore ce que cela vaut ...

Les attaques de types DDOS , sont normalement arrêtées par le firewall , sinon, comme je l'ai précisé plus haut , le serveur web que tu utilises posséede souvent des outils pour empêcher /detecter et bloquer les requetes abusives :

Apache : mod_evasive
Nginx : http Limit Zone et http limit request

alors qu'il est tout à fait possible de hacker un algorithme.

sauf si l'algo est à paramètres aléatoire eux-meme stockés exclusivement en Session ...
il ne peux pas faire suivre les session ... si ?

Salut,

j'utilise pour ma part un champs invisible et vide que j'appelle name, et si dans le retour il est rempli, c'est un spam ! ça marche plutôt bien !

Oui très bien mais ça c'est un problème de spam, ça n'a aucune efficacité contre un hackeur.