Discussion :

[rawsrc]

Tiens une autre faille :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo "<textarea style=\"text-align:left;\" name=\"txt[]\" rows=\"5\" cols=\"67\" wrap=\"soft\">" . trim($textes[$i]['txt'],"\t") . "</textarea><br/><br/>";

trim($textes[$i]['txt'],"\t"), ne protège rien contre les failles XSS ce qui permet le vol de session et de cookie...

Tu devrais avoir au moins quelque chose dans ce genre htmlspecialchars(trim($textes[$i]['txt'], "\t"), ENT_QUOTES)

[rawsrc]

Si tu dois reprendre tout le code de ton CMS perso, je te conseillerai en attendant de le sécuriser proprement de basculer vers un CMS grand public et open source (c'est pas ça qui manque)

[steph68b]

ok, je rajoute!

si je ne veux pas qu'il m'emmerde je supprime accueil.php... ce que je fais entre 2 modifs du fichier... ensuite je restaure et j'attends de voir s'il passe toujours... ou pas!

[armel18]

- log: non il arrive directement sur accueil.php et y passe son PHPSESSID en $_POST...............

probablement ton site est victime d'une attaque par fixation de session. la fixation de session est le fait qu'un attaquant prenne l'initiative de générer un identifiant de session depuis l’extérieur du serveur alors que c'est au serveur de générer un identifiant de session.dans ton cas l'identifiant de session est transmis par POST( en général c'est via l'url, donc en GET).
Pour faire face à ce type d'attaque il faut s'assurer que l'identifiant de session est bien transmis via un cookie.Cela est possible avec quelques directives apache:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
session.use_trans_sid = 0
session.use_cookie = 1
session.use_only_cookies = 1

avec phpinfo(),tu peux vérifier si ton serveur défini bien ces directives.

Par ailleurs pour vérifier la vulnérabilité de ton site sur des attaques de type injection sql et xss (c'est qui est déjà ton cas) tu peux utiliser un module firefox comme sql-inject-me

[sabotage]

Le problème de fixation de session n'est pas l'origine de l'id de session mais l'utilisation d'un id avec lequelle une personne est connectée (l'id peut avoir été créé de l'exterieur ou par le serveur).
Pour empêcher cela il faut effectivement ne pas accepter des id venant du POST ou GET et surtout régénérer un nouvel ID lorsque l'utilisateur se connecte.

Dans tout le cas, pour usurper une session, il faut que la personne malveillante ait connaissance de l'id. Cela demande un contact avec la machine cliente, par exemple via un mail avec lien.

[steph68b]

salut,

alors déjà pour votre contribution!

j'ai pu échanger directement avec rawsrc samedi, via skype.
-> on a déjà patché plein de choses (dont le .htaccess pour le PHPSESSID justement, upgrade de la version de php, les magic quotes)
-> et il m'a aussi expliqué qq trucs basiques que j'ignorais, tout simplement, les formations ne traitant que très peu des problématiques de sécurité finalement!!

donc pour le moment, même si moi j'ai encore de petites modifs à mettre en place, le site tient bon...... même si le ruskof est revenu à la charge.... aidé aussi par un homologue ricain!