Sécurité

devlop78
Invité n'ayant pas de compte PHPfrance

02 juin 2010, 03:55

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.

Eléphant du PHP | 314 Messages

02 juin 2010, 09:04

Hello,

Tu peux appliqué tes dernières sécurité par IP, c'est déjà ça de fait !
Cordialement,
Julien - http://laravel.fr/

Eléphant du PHP | 217 Messages

02 juin 2010, 09:07

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

ViPHP
ViPHP | 5462 Messages

02 juin 2010, 10:01

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 :mrgreen:

devlop78
Invité n'ayant pas de compte PHPfrance

02 juin 2010, 15:06

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

ViPHP
ViPHP | 3300 Messages

02 juin 2010, 18:48

Non mais déja je doute qu'une personalité comme Henry IV n'ait qu'un seul cheval.
Fait du php depuis que ca existe ou presque :)

Mammouth du PHP | 661 Messages

03 juin 2010, 18:59

salut :D

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


@++

devlop78
Invité n'ayant pas de compte PHPfrance

03 juin 2010, 19:40

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 ?

ViPHP
ViPHP | 1136 Messages

03 juin 2010, 21:02

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.

devlop78
Invité n'ayant pas de compte PHPfrance

04 juin 2010, 01:00

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

Eléphant du PHP | 142 Messages

04 juin 2010, 01:23

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

ViPHP
ViPHP | 1136 Messages

04 juin 2010, 07:45

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

Mammouth du PHP | 661 Messages

04 juin 2010, 08:11

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 ?

Eléphant du PHP | 314 Messages

04 juin 2010, 10:04

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 !
Cordialement,
Julien - http://laravel.fr/

devlop78
Invité n'ayant pas de compte PHPfrance

04 juin 2010, 13:56

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