TutorielsVous débutez ? C'est ici qu'on commence !
Mon compte
Recherche
Livre d'or
PublicitéVous devez être inscrit pour pouvoir poster des messages
| Page : 2 1 Précédente | |||||||
| Pseudo | Commentaire | ||||||
|---|---|---|---|---|---|---|---|
| Page : 2 1 Précédente | |||||||
tommy009
|
# Posté le 02/09/2008 à 10:18:59 - Ce membre n'a pas mis de note | ||||||
viv@GNUnux:~$![]() Groupe : Membres |
Mais pourquoi vous allez aussi loin les gars ?? Pour contourner sa protection avec Firefox, il faut paramétrer le navigateur pour que, dès que l'on clique sur "Effacer mes traces", il efface (entre autres) les sessions et les cookies (j'ai eu un peu de mal à comprendre pourquoi mon script merdait avec les cookies au redémarrage du navigateur : il efface tout (sur ma demande en plus, hum ) !). Essayez, vous verrez ! Merci Mozilla. ![]() Cependant, ce tutoriel est plutôt bien fait : il nous montre une première approche de la sécurité et nous invite à innover pour la protection de notre (nos) site(s). Bravo à toi et continue à rédiger ! Code : Console
|
||||||
Utopi@
|
# Posté le 28/08/2008 à 19:39:11 - Ce membre n'a pas mis de note | ||||||
Qui peut le plu peut le moinss![]() Groupe : Membres |
Merci pour ces critiques positives ! Je suis tout à fait d'accord que mon script n'est pas infaillible et c'est d'ailleurs pourquoi la sécurité informatique me passionne : on doit toujours évoluer et se remettre en question car un script infaillible n'existe pas et n'existera jamais .Au fait, pour ceux qui ont été intéressé par ce premier tuto ils vont être servi : un second attend d'être validé et un troisième est en préparation .Merci .
Don't think you are, Know you are ... |
||||||
granarc
|
# Posté le 28/08/2008 à 13:38:41 - Ce membre a mis la note : 18 | ||||||
I am mad...![]() Groupe : Membres |
Bon tuto, bravo ! On sent que tu as vraiment bien examiné le problème sous tous ses angles, et que tu as pris cœur à réaliser ce tuto. @ceux-qui-ont-fait-des-remarques : C'est vrai que l'on pourrait faire encore des tas de choses pour améliorer la sécurité, et c'est aussi vrai que ce script n'est pas parfait, mais il ne pouvait pas tout faire non plus, et puis il n'est pas un grand programmeur qui a pour but de réaliser une sécurité infaillible (je pense que peu de gens qui lisent ce tutoriel ont besoin d'une sécurité aussi grande sur leur site
)Je pense que son seul but était de montrer comment raisonner pour sécuriser un formulaire (càd en inspectant toutes les solutions possibles pour le pirater) et je pense qu'il a réussi |
||||||
Awaken
|
# Posté le 28/08/2008 à 11:44:36 - Ce membre n'a pas mis de note | ||||||
![]() Groupe : Membres |
Qu'est ce qui empêche l'utilisateur d'effacer le cookie et recommencer ? Le mieux c'est encore d'enregistrer l'ip dans une table, mais là encore c'est falsifiable avec un proxy. Donc en gros il n'y a pas de méthode vraiment efficace, à part peut-être considérer un certain nombre de tentatives pendant un laps de temps pour tout le monde
The greatest trick the Devil ever pulled was convincing the world he didn't exist. |
||||||
robocop
|
# Posté le 28/08/2008 à 10:45:41 - Ce membre a mis la note : 14 | ||||||
|
Groupe : Membres |
Tutoriel intéressant par certains points. Je trouve qu'il y a des choses complètement hors sujet (comme le truc du md5 et du salage), car avec le brut force, le hacker ne s'occupe pas du md5. D'autres part, toutes les protections sont du coté utilisateur, donc, rien ne lui empêche de supprimer ses cookies et toussa. Il faudrait passer par la bdd. Je trouve que la meilleur solution proposée est encore le sleep(1) : ça emmerde bien le bot, et ça reste presque invisible des utilisateurs. 14 pour moi. |
||||||
luc@s
|
# Posté le 27/08/2008 à 22:49:28 - Ce membre a mis la note : 10 | ||||||
|
PPHP Groupe : Membres |
nan il est super merci, et pas compliqué du tout
Code : PHP
|
||||||
Utopi@
|
# Posté le 26/08/2008 à 18:50:29 - Ce membre n'a pas mis de note | ||||||
Qui peut le plu peut le moinss![]() Groupe : Membres |
Bonjour à tous, Suite à vos nombreuses remarques j'ai développé une petite classe de connexion qui permet de controler le bruteforcing. Fichier lib/classes/connexion.class.php : Code : PHP
Classe de connexion par formulaire : Soit PDO2 une classe héritée de PDO (PHP Data Object) qui permet de tracer les requêtes. Code : PHP
Exemple d'utilisation : Soit $tpl un moteur de template. Code : PHP
Ce code est peut-être un peu compliqué à assimiler pour un zér0 mais je suis sûr qu'il pourra servir à certains .
Don't think you are, Know you are ... |
||||||
Loufute
|
# Posté le 14/08/2008 à 00:40:45 - Ce membre n'a pas mis de note | ||||||
|
Groupe : Membres |
J'avais une question... Pour mon site, j'utilise deux choses... De une, un code "image aléatoire" pour le formulaire (je ne sais plus le nom exact...), donc normalement, un robot pas trop puissant ne sait pas l'entrer... D'autre part, j'utilise un système de "blocage de compte"... Je m'explique : au bout de 3 tentatives erronées, le compte est bloqué et doit être réactivé par email... Je pense que cela peut beaucoup bloquer un pirate... Cependant, n'ayant aucune base là-dedans, je me demandais si ces deux méthodes étaient efficaces, ou tout du moins utiles ? Merci d'avance ! |
||||||
blapecool
|
# Posté le 17/07/2008 à 19:35:11 - Ce membre a mis la note : 19 | ||||||
|
plouf ! Groupe : Membres |
Super Tuto Moi j'ai pas voulu me complique la vie pour l'admin j'endor mon scrit pendant 5 sec Et hop Ta note : Secret (cliquez pour afficher) 19 Quand il y a du noir il y a de l'espoir !!! Citation : L'intelligence, c'est comme les parachutes : quand on n'en a pas on s'écrase !! |
||||||
luc@s
|
# Posté le 17/07/2008 à 14:13:45 - Ce membre a mis la note : 10 | ||||||
|
PPHP Groupe : Membres |
Ton tuto est complet mais il y a des erreurs. L'utilisation des cookies et des sessions es insuffisante. Inutile même. Rien ne vaut une BDD qui stocke l'adresse IP et qui la bloque en complément de la protection dont tu parles. Il faut aussi faire un sleep(2); pour ralentir le script, le min sera de 1 tentative toutes les 3-4 secondes, très lent donc. 10/20 Code : PHP
|
||||||
nah0y
|
# Posté le 23/06/2008 à 18:40:03 - Ce membre n'a pas mis de note | ||||||
|
Reproduire le hasard Groupe : Membres |
Salut, Juste un petit message pour te dire que tu as fait une excellente présentation de la méthode par force brute que je connaissais de nom et qui m'a été extrêmement bien expliqué par ton tutorial, je n'ai pas lu la suite car je n'en ai pas besoin pour l'instant, en tout cas c'est un 20/20 pour la partie explicative de cette méthode
|
||||||
virtual_spirit_black
|
# Posté le 23/06/2008 à 15:29:23 - Ce membre a mis la note : 3 | ||||||
|
Groupe : Membres |
Je le répéte il faut combiner astucieusement les deux techniques Bloquage sur IP + Compte. Les deux doivent êtres liés. j'ai exlpiquer pourquoi. Et je rajouterais qu'avec un systéme bidon de simple bloquage par teste sur un compt sans prendre en compte l'IP, on laisse un moyen simpas d'mpecher n'importe quel utilisateur du site de se connecter en " floodant " et là rien à foutre des delais de 1s en plus, le seul but c'est de bloquer pour que la vrai personne ne puisse pas se connecter. Et li'dée du stoquage dans un fichier est carrement crade ! Imagine un site avec 10 000 comptes. t'as 10 000 fichiers avec des block de 32Ko sur ton disque dure, tu perds 320 000ko -> 320 Mo ... Huhu imagine un site comme skyblog...Et si c'est des fichiers temporaire, ça veut dire que tu va l'effacer. mais quand ? avec un tache cron ? c'est ridicule dans un systéme de protections, suffit d'arriver à trouver quand tu execute la tache et y'a encore moyen de bidouiller pour faire des choses simpas. Et je le repete CAPTCHA sa suxx maintenent, c'est dépassé et ça fait chier les utilisateurs. |
||||||
Laurent
|
# Posté le 23/06/2008 à 04:34:38 - Ce membre a mis la note : 19 | ||||||
![]() Groupe : Membres |
Hello! Merci beaucoup pour le tutoriel! Je ne me considère plus comme un novice du PHP et de la programmation depuis un petit moment, mais ce tutoriaux m'aura quand même appris pas mal de trucs. Je pense notamment au salage des mots de passes, je ne connaissais pas ça, et c'est quand même assez astucieux ^^. Je risque de répéter un peu ce que les autres ont dit plus haut, mais je me le permet quand même (disons que j'ai survolé les commentaires). Quelques notes cependant :
Je propose la technique alternative suivante Tout d'abord, on limite les tentatives de connexions par nom d'utilisateur. À chaque fois qu'une tentative est fait par un utilisateur de se connecter avec un nom en particulier, on incrémente un compteur, peu importe le client qui le demande. On ne peut malheureusement pas utiliser les cookies ou les sessions pour ça (qui sont unique à chaque client), alors il faut stocker le tout quelque part sur le serveur. En PHP, on n'a pas accès à ensemble de variables partagées gardées en mémoire entre les exécution (contrairement à Java ou ASP.NET), alors il faut faire quelques contorsions. On peut stocker le tout dans un fichier temporaire nommées selon le nom d'utilisateur. C'est un peu comme le mécanisme de session de PHP (Les session PHP sont stockée dans un fichier sur le serveur), sauf qu'il est en fonction du nom d'utilisateur au lieu du cookie de session de PHP. On stocke le compteur la dedans. Sinon, on peut stocker le tout dans la base de données. Cette technique à l'avantage d'être un peu plus confortable. De plus, vous avez les protections de MySQL contre la corruption de données, ce qui vous évitera du code supplémentaire pour assurer que vos fichiers n'ont pas été corrompus (genre reboot d'Apache en plein milieu de l'écriture d'un fichier). Pour booster les performances, vous pouvez utiliser le moteur de stockage "MEMORY" de MySQL. La table ne sera pas enregistrée sur le disque dur, elles sera gardé en mémoire en permanence. On peut se le permettre de perdre l'information qu'elle contient en cas de redémarrage du serveur car il ne s'agit pas d'information très critique. La technique par fichier est selon moi plus rapide, la technique par MySQL est plus sur et relativement plus facile, alors il faut choisir. Néanmoins, avec l'utilisation d'une table MEMORY, je ne suis pas trop sûr des performances, alors je conseille de faire les tests vous même pour voir ce qui est le meilleur. Note que pour un petit perso avec un forum et système de commentaire de news, ne vous cassez pas trop la tête, prenez MySQL. EDIT : certains ont suggéré un système de CAPTCHA, ce qui est une excellente idée. Néanmoins j'irais taper le concepteur du site qui me force à rentrer un CAPTCHA illisible chaque fois que je me logue. Mieux vaut réserver les CAPTCHAS pour l'inscription au site. Be kind, for everyone you meet is fighting a hard battle. (Platon) Laurent |
||||||
virtual_spirit_black
|
# Posté le 22/06/2008 à 18:11:56 - Ce membre a mis la note : 3 | ||||||
|
Groupe : Membres |
Wooo Alors comme déjà dit tous ce que tu à fait ne sert absolument à rien. Pour les cookies et sessions ça à déjà été expliqué. Donc je vais juste expliquer pour le sleep(1); En rajoutant la gestion des threads dans le programme ton astuce ne sert plus à rien. Suffit de lancer 100 threads parralèles et on se retrouve avec 100 teste par secondes. même en attandant 1 seconde pour chaques. Et cette methode permet aussi d'aller plus vite que de faire simplement à la suite. La seule methode fiable c'est : 1) Limite dans la BDD sur une ip : plus de 10 tentative par minutes et on est est banni pour 10 minutes. On reduit largement le nombre de possibilité, il faut attendre 10 minutes pour tester 10 possibilités. soit au maximum 10 * 6 = 60 testes à l'heure En reprenant ton calcul on tombe sur : N = 60*24*365 = 525 600 On pourrait imaginer une fonction exponentielle, pour gerer ça encore mieux mais c'est pas indispensable. 2) Limite dans la BDD sur un compte : on peut reprendre le même systéme que pour le bloquage sur IP. L'avantage des deux methodes c'est que si un pirate posséde un resaux de 500 PC zombie qui peuvent faire des testes alors il est grillé par la détéction par Compte ( ou si il se sert de proxy ). On peut aussi brute forcer le compte et non plus le mot de passe, sur 30 000 inscrits on peut facilement suposer qu'un boulet aura mit un mot de passe comme "admin" " roxxor " ou " linux" ( après sa depent du site, mais y'a toujours un mot de passe qui ressort ). Il lui suffit de tester le mots de passe avec tous les comptes et c'est bon il en aura forcement au moins un. Et là la détéction par IP protége de ça. Voilà. C'est un systéme qui me parrait assez securisé dans le cas d'un simple petite site sans grand danger. Dans le cas d'un service hyper securiser comme une banque, on peut imaginer un systéme qui se base sur une moyenne de connection par minutes suivant le moment de la journée et de l'année. avec des estimation. Si on depasse largemtn cette moyenne, on peut suposer qu'un pirate à trouver un moyen de contourner les precedents systéme et donc desactiver temporairement la page de login le temps de comprendre d'où ça viens et de contrer ça. Et sion en ce qui concerne les captcha c'est de plus en plus ineficaces contrairement ç ce qu'a dit je ne sais plus trop qui :-D. je m'ettalerais pas là dessus, mais y'a plusieures methodes simples pour les contourners : Petit chinois payer 1$ la journée, robot qui lisent le code, redirections des captcha sur un site fake ) Et un dernié truc, pour le grain de sel MD5, je connseillerais plutôt d'utiliser un grains de sel qui ne depent pas de toi, mais de l'utilisateur genre : Son nom, ça date de naissances. un truc qui ne change pas ( et que l'user ne peut pas changer ). ça oblige à avoir toutes la BDD et pas seulement les hashs (qui dans certains cas peuvent être facilement recupérer car ils sont dans les cookies ). Et passer ta chaine au sha1, je vois absolument pas l'utilité. Les deux SHA est calculer à chaques demande de login + chaques enregistrement. ça fait au finale pas mal de calcul completement inutile qui bouff des ressources pour rien. t'as cas faire le hash de ta chaine que tu veux mettre en grain de sel, et la rajouter en claire directement. genre ton truc ça devient : Code : PHP
à la place de : Code : PHP
Voili Voilà, j'ai mis 3, c'est proportionel au niveaux de securité. Au mieux ça evitera à un ou deux gamins qui tuilise un logiciel tous fait de brute forcer, mais pas plus. |
||||||
webshinra
|
# Posté le 22/06/2008 à 14:26:52 - Ce membre n'a pas mis de note | ||||||
en plus, j'aime pas les nains![]() Groupe : Membres |
un système basé sur les sessions ne sert a rien, en effet, un bot codé par un meme qui a un minimum de cervelle élimineras les infos de sessions (et donc, dans ton cul), la seul technique "a peu prés" fiable, c'est l'ip. (et sinon, un truc qui m'amuse avec les systeme anti brute force, c'est la technique de ssh : au dessus d'un certain nombre d'essais depuis la meme connexion, il répond que le mot des passe est faux meme si il est juste) |
||||||
Coyote89
|
# Posté le 22/06/2008 à 10:32:09 - Ce membre n'a pas mis de note | ||||||
Des chips !!![]() |
Citation : Krankkatze Btw, le dé-hashage ça existe avec le md5, et ça marche très très bien. Le md5 est très peu sécurisé, on dirait que tu n'as même pas lu l'article vers lequel tu nous envoies. Si tu pouvais éviter de dire n'importe quoi, ou, à défaut de dire quelque chose de constructif, le dire d'une manière moins brute (aucun jeu de mot pourri avec le titre du tuto), ça passerait mieux. D'une, utopia a bien précisé dans son tutoriel que l'utilisation du salage était recommandée, ce qui complique amplement la tâche. Il a également évoqué l'utilisation d'autre algos, type sha1(). De deux, dire que "le dé-hashage ça existe avec le md5, et ça marche très très bien", ça montre d'une part ton manque de connaissances et/ou de pratique (oui oui, les rainbow tables, on sait...), et d'autre part ton hors-sujet. Le tuto d'utopia est clair : il traite l'attaque par force brute, il ne parle pas de protections contre le piratage d'une base de données. Et si le robot ou l'utilisateur en face n'a pas procédé à ce "piratage", ce qui correspond à peu de chose près à 100% des cas, le problème reste le même, il ne sait pas sur quelle signature il doit tomber et il lui faudra un nombre considérable d'essais pour trouver le bon mot. Bref, à l'avenir, merci de t'en tenir au sujet du tutoriel. |
||||||
katagoto
|
# Posté le 22/06/2008 à 10:20:05 - Ce membre a mis la note : 10 | ||||||
Hard than a rock![]() Groupe : Membres |
Niveau probabilité, le MD5, le SHA1 et tout les autres moyens de hachage et cryptage prenne en compte la casse, donc nous avons 26*2 (lettre majuscule + minuscule) + 10 (chiffres) + 20 variantes et carctères spéciaux = 82 Donc 82^8 possibilités à condition que le hackeur sâche qu'il n'y a que 8 caractères... Sans compter les collisions, c'est pas mal je trouve
Bonne journée et bon code, Katagoto _______________________________________ Vive PHP, PostGreSQL, la POO, PDO, AC/DC et le C++ |
||||||
Ishimaru Chiaki
|
# Posté le 22/06/2008 à 08:41:29 - Ce membre n'a pas mis de note | ||||||
25 frickin' years !![]() Groupe : Membres |
Je viens poster une remarque au sujet de ton code XHTML du formulaire, puisqu'un détail m'a sauté aux yeux : Code : HTML
Tes labels et input ne sont pas entourés d'un paragraphe et ceci n'est pas valide puisque ces éléments sont de type inline. Voici le code correct : Code : HTML
Connaissances
Communautés de gimpeurs: Gimp-Attitude | Projet-Gimp | Tuto-Gimp Des ableaux sous OOo Writer | Pourquoi éviter les menus en Flash |
||||||
Krankkatze
|
# Posté le 22/06/2008 à 01:49:10 - Ce membre n'a pas mis de note | ||||||
Ob-la-di, Ob-la-da![]() Groupe : Membres |
Ton cookie bidon il sert à rien, parce qu'on peut coder un bot qui enregistre les cookies bidons et pas les autres.
|
||||||
utb_diablo
|
# Posté le 20/06/2008 à 22:19:28 - Ce membre a mis la note : 5 | ||||||
-uTb#`diablo 4 ever ;)![]() Groupe : Membres |
Citation : Pas de titre Et puis si ton bot n'accepte pas les cookies on peut directement le mettre hors course avec un cookie bidon comme je l'ai indiqué deux ou trois posts auparavant ![]() Un bot se ferait surement avoir oui, mais si je suis derrière pour adapter mon code en consequence, ce n'est pas un cookie qui va me gener, je répète que dans le cas d'un formulaire de connection (l'user n'est donc pas encore identifié) ton système peut être outrepassé, non pas parce qu'il est mauvais, mais tout simplement parce que le problème réside dans le fonctionnement même de php et de sa gestions des sessions (attention, je ne dis pas qu'il est mauvais !! Bien au contraire). Les cookies étant (à priori) le seul moyen utilisé dans ton système pour distinguer un user d'un autre, un soft bien codé peut très bien simuler une infinité de visiteur jusqu'à trouver ton mdp : il est si facile de manipuler les cookies ![]() Citation : Pas de titre Allez, un petit CAPTCHA bien construit en plus et à moins d'être un génie du hacking je ne vois pas comment tu fais... Citation : Pas de titre Par ailleurs si je rajoute la fonction sleep() comme je l'ai indiqué en technique complémentaire : je ne vois vraiment pas comment tu comptes bruteforcer le formulaire ! Tu vas entrer une tentative par seconde ? Imagine que mon mot de passe contienne 10 caractères composé de chiffres et de lettres. Exactement !! Pourquoi s'encombrer d'un système utilisant à foison des cookies, de sessions et de requêtes SQL alors que des techniques basiques existent ? La technique du sleep() est très utilisée en informatique, je prends l'exemple de la majorité des services que l'on trouve habituellement sur un serveur : ssh, ftp, imap, pop3 et j'en passe, Tu remarqueras que les tentatives de bruteforce (traditionnelles) sont complètement inutiles contre ce genre de serveurs, et pour cause !! L'emploi du système dit de "delay", qui consiste tout bonnement à faire dormir le code quelques instants avant de délivrer une réponse négative à une tentative de connection, est une solution efficace pour considérablement réduire le nombre de password testés à la seconde. Le captcha n'est plus à présenter, tellement il a fait ses preuves en tant que système anti-bot. C'est dans cette optique là que je trouve ton système un peu encombrant alors qu'il suffirait d'un captcha et d'un système de delay pour contrer efficacement et sans le moindre risque (disons minimes), les tentatives de brute-force. Ou si vraiment l'envie de créer un système de bannissement, s'il te plait, contente toi de bannir l'ip ce sera plus simple et beaucoup plus efficace. (mais pas infaillible)
Ils ne savaient pas que c'était impossible, alors ils l'ont fait ... To Be Single Is Like Being In A Huge Candy Store ... [Barney Stinson] You can find my software right here => ftp://serv-diablo.no-ip.org/Source Recherche offres de télétravail /Q me |
||||||
Utopi@
|
# Posté le 20/06/2008 à 18:21:27 - Ce membre n'a pas mis de note | ||||||
Qui peut le plu peut le moinss![]() Groupe : Membres |
Salut, Tout d'abord merci de tes explications : c'est toujours plus constructif de débattre que de se faire traiter son tuto de grand n'importe quoi. En lisant ta méthode d'attaque j'ai vu qu'il y avait un petit problème au niveau du script du traitement du formulaire. Néanmoins, ce script si il est convenablement intégré sur une page web il est bien sécurisé. Je m'explique, déjà en temps normal tu ne vois pas la méthode de protection mise en place donc ton attaque se construit à tâtons et l'admin à le temps de te repérer à faire tes petits essais dans ton coin. C'est un des principes mis en place dans "les pots de miels" : véritables leurres à pirates .Par ailleurs si je rajoute la fonction sleep() comme je l'ai indiqué en technique complémentaire : je ne vois vraiment pas comment tu comptes bruteforcer le formulaire ! Tu vas entrer une tentative par seconde ? Imagine que mon mot de passe contienne 10 caractères composé de chiffres et de lettres. Petit calcul : 26 lettres majuscules + 26 lettres majuscules + 10 chiffres (allez je suis sympa je ne compte pas les caractères spéciaux) il y a donc 62^10 possibilités. Tu me préviendras dans quelques centaines d'années ce que tu auras trouvé .Et puis si ton bot n'accepte pas les cookies on peut directement le mettre hors course avec un cookie bidon comme je l'ai indiqué deux ou trois posts auparavant .De plus, je pense que pour accéder à un formulaire qui donne accès à une administration il faut déjà s'être loggé sur le site ou avoir passé un .httaccess : donc si tu renvois une en-tête avec une session vide tu es automatiquement redirigé vers une erreur 404 ou la page d'accueil. Donc ta méthode peut marcher même si certains points me semblent incorrects mais pas sur un pannel correctement intégré. Si une personne implémente cette technique pour lutter contre l'attaque par force brute c'est déjà qu'elle a mis d'autres protections en place... Allez, un petit CAPTCHA bien construit en plus et à moins d'être un génie du hacking je ne vois pas comment tu fais... ++ Don't think you are, Know you are ... |
||||||
utb_diablo
|
# Posté le 20/06/2008 à 17:13:41 - Ce membre a mis la note : 5 | ||||||
-uTb#`diablo 4 ever ;)![]() Groupe : Membres |
Mettons que je veuille bruteforcer un formulaire utilisant ta méthode de "protection"... Je me connecte, sans envoyer de cookie pas avec mon browser biensur ![]() Un petit script C, voir même php (les sockets, ya que ca de vrai :p) et une bonne connaissance du protocole HTTP suffit à outrepasser ton système 1 -> ton session_start() démarre une nouvelle session, et le serveur me renvoie son identifiant (HTTP Set-Cookie) 2 -> j'exécute, mettons 10 tentatives d'intrusion sur ton formulaire, en utilisant le cookie reçu en 1 3 -> ton script php me bloque :/ zut alors, je suis piégé ! 4 -> mais tonton Kévin vient me dépanner et me conseille de renvoyer une requête SANS cookie 5 -> bim, ton script php reçoit une requête sans cookie de session, comme en 1, il créé une nouvelle session toute jolie jolie ! 7 -> résultat : un $_COOKIE['marqueur'] non défini, de même qu'un $_SESSION['nombre'] non défini non plus ![]() 8 -> je recommence mes tentatives de bruteforce 9 -> To be continued ... Un peu de lecture pour la route ? http://fr2.php.net/manual/fr/function.session-start.php Citation : http://fr2.php.net/manual/fr/function.session-start.php session_start() crée une session (ou restaure celle trouvée sur le serveur, via l'identifiant de session passé dans une requête GET, POST ou par un cookie). ++ ps : si j'ai mis cette note, c'est pas pour être méchant, c'est juste pour bien te faire comprendre que ton système est loin d'être efficace. N'y vois rien de personnel
Ils ne savaient pas que c'était impossible, alors ils l'ont fait ... To Be Single Is Like Being In A Huge Candy Store ... [Barney Stinson] You can find my software right here => ftp://serv-diablo.no-ip.org/Source Recherche offres de télétravail /Q me |
||||||
Utopi@
|
# Posté le 19/06/2008 à 20:23:34 - Ce membre n'a pas mis de note | ||||||
Qui peut le plu peut le moinss![]() Groupe : Membres |
Oups tu as raison : ça m'apprendra à taper trop vite .Enfin bon, le principe est là. Don't think you are, Know you are ... |
||||||
Pimi78
|
# Posté le 19/06/2008 à 20:19:25 - Ce membre n'a pas mis de note | ||||||
|
Salut tout le monde ^^ Groupe : Membres |
Tu as bien du 9 chiffres ? Pourtant pour moi il y en a 10 (0, 1, 2, 3, 4, 5, 6, 7, 8, 9) Et aussi 26+9=35 non 34 !!
|
||||||
Utopi@
|
# Posté le 19/06/2008 à 19:19:22 - Ce membre n'a pas mis de note | ||||||
Qui peut le plu peut le moinss![]() Groupe : Membres |
le signe ^ représente la puissance en mathématique .
Don't think you are, Know you are ... |
||||||
matheod
|
# Posté le 19/06/2008 à 18:10:52 - Ce membre n'a pas mis de note | ||||||
|
<? echo $citation; ?> Groupe : Membres |
C'est quoi les ^ ?
|
||||||
Utopi@
|
# Posté le 19/06/2008 à 16:12:09 - Ce membre n'a pas mis de note | ||||||
Qui peut le plu peut le moinss![]() Groupe : Membres |
Ca ne donne pas une infinité de possibilité : Démonstration : Tu as 26 lettres dans l'alphabet (a, b, c, d...) et 9 chiffres (0, 1, 2, 3..). Tu as donc 34 caractères différents. Je ne prends pas les lettres majuscules mais ça reste le même principe. Imaginons que tes deux mots de passe fassent chacun 5 caractères de long. Pour chacun tu as donc 1 chance sur 34^5 de trouver le bon. En tout tu as donc : 34^5*34^5 = 34^10 possibilités. Ce nombre n'est donc pas infini et tout a fait attaquable par force brute .
Don't think you are, Know you are ... |
||||||
matheod
|
# Posté le 19/06/2008 à 13:58:35 - Ce membre n'a pas mis de note | ||||||
|
<? echo $citation; ?> Groupe : Membres |
Citation Si il y a 2 champs pour deux mots de passe différents + un champ pour le pseudo et aucune protection contre l'attaque par force brute c'est tout à fait envisageable de trouver les 2 passes. Certes, le temps pour trouver les clefs sera bien plus long mais finira toujours par fonctionner ![]() Par ailleurs pourquoi s'embêter avec 2 passes à retenir alors qu'un seul suffit si une défense est mise en place ? Ah bon ? Car ca donne une infini de possibilité ... Car comme il faut que les deux soit bon et sachant que les deux sont sur la meme page et si un des deux passent pas bon ca bloque ... Ex : Imaginons qu'il n'y ai que 3 lettre dans notre alphabet et aucun autre symbole : Il va esseyer : a dans le premier champs et a dans le deuxième, a dans le premier champs et b dans le deuxième, a dans le premier champs et c dans le deuxième, b dans le premier champs et a dans le deuxième, b dans le premier champs et b dans le deuxième, b dans le premier champs et c dans le deuxième, c dans le premier champs et a dans le deuxième, c dans le premier champs et b dans le deuxième, c dans le premier champs et c dans le deuxième, donc avec 26 lettre et plein de symbole est des long mots de passe de plus d'une lettre ca va être long |
||||||
Utopi@
|
# Posté le 19/06/2008 à 11:28:21 - Ce membre n'a pas mis de note | ||||||
Qui peut le plu peut le moinss![]() Groupe : Membres |
Merci pour ton commentaire cypher666, Bon pour les autres qui considèrent que l'astuce défensive par les cookies est inutile je vais vous donner un complément. Etant donné que ce dispositif doit être mis en place dans un panel d'administration, donc seuls des gens de confiance (admins, modérateurs ...) ont accès à cette partie, il vous suffit de créer un cookie "bidon" : de tester si il a bien été créé et dans le cas contraire vous quittez le script avec un exit(). Voilà donc si vous n'acceptez pas les cookies vous êtes directement mis hors d'état de nuire. Bien entendu, tous vos formulaires ne peuvent pas être protégés de la sorte car certains navigateurs bloquent les cookies. Je pense que je vais donc vous présenter une autre technique très efficace de protection de formulaire dans un prochain mini-tuto. En espérant que ça plaise au plus grand nombre .
Don't think you are, Know you are ... |
||||||
cypher666
|
# Posté le 19/06/2008 à 10:45:11 - Ce membre a mis la note : 19 | ||||||
Heu....![]() Groupe : Membres |
Superbe tutoriel, intéressant de par ces astuces, et la multiplicité des techniques utilisée, améliorant le potentiel défensif. Quand aux autres commentaire, il faut lire le tuto en entier pour le comprendre Je met 19 car j'aime aps mettre 20 et que rien n'est parfait. Par contre, je t'encourage (vivement) continuer de faire des tuto sur la sécurité, car tu s 'air de t'y connaitre et d'avoir de bonnes sources ![]() Bonne chance
Site non officiel de mon lycée A VOIR!!! Quand vous allez sur un site amateur, cliquez sur les publicités, ça rapporte de l'argent au webmaster et vous ça ne vous coûte rien ![]() |
||||||
Vous devez être inscrit pour pouvoir poster des messages
Changer de design |
En savoir plus |
Plan du site |
Politique d'accessibilité |
Règles |
RSS tutoriels |
RSS news
Édité par Simple IT SARL :
Nous contacter
| Notre blog | Revue de presse | Publicité
Y'a plus rien à lire, faut remonter maintenant !
Hébergement web - Correction de tutoriels - Créer un site
Vous souhaitez apparaître ici ? Contactez-nous.
377 Zéros connectés |
8 requêtes |
0.0528s (0.039s)
