[Merci à vous tous pour votre aide et votre réactivité.]

Merci encore CommComm.

Donc petite explication :

... [J'ai viré le topo car avec ce que tu indiques on peut encore prendre la main. Et il y a peut-être d'autres moyens, donc silence...]

Affaire bouclée.

Merci à vous tous pour votre aide et votre réactivité. J'ai corrigé du mieux que j'ai pu la faille ... [même chose].

Quand je passe à Mellé, je m'arrête pour me faire offrir une bière

Pas de soucis Même deux

Merci CommComm, en effet, c'était très sympathique...

sur la page admin.php, un brute force est largement possible non ?

Oui, le bruteforce est possible, et les mots de passes n'étaient pas extrêmement complexes (je les ai changés au cas où). Il aurait peut être pu dans ce cas modifier la table user en utilisant les fonctions d'upload image / pdf. Je ne mets en sécurité sur l'upload qu'un test sur l'extension du fichier, mais il me semble avoir vu une épreuve ici qui démontrait que ce n'était pas suffisant

Oui, c'est une possibilité.

Oui mais dans tous les cas, c'est ça qui m'échappe :

- Il a modifié une entrée dans la table user. La seule manière de la faire étant de modifier directement la base de données. (Base qui a un login / mot de passe différent de "root" / "")
- Pourquoi chercher la page d'administration si il a réussi à accéder à la base...

Bonjour à vous et merci de vous pencher sur mon problème.

Concernant les logs, le peu de log auquel j'ai accès ne m'a pas révélé d’incohérence, (log ftp et messages d'erreurs).

La version de PHP est le 5, Apache je n'en suis pas sur donc je ne dirai pas de bêtises. L'Os est Linux.

En regardant les stats, je vois qu'il a galéré a trouver la page d'administration. Dans les pages demandées qui ont un répondu un code 404, on trouve par exemple :

/administrator/account.asp
/db/scripts/setup.php
/user.php
/authuser.asp
/bb-admin/login.php

etc...

Bonsoir, et merci pour ta réponse.

Le site est ***.

C'est un site d'information pour une petite commune, qui n'est pas censée drainer beaucoup de trafic. Il faut vraiment en avoir envie pour tomber dessus.

Je vais essayer de répondre à tes questions du mieux possible :

- comment est gérée la session dans les pages ?

Lorsque le formulaire d'identification est soumis, je fais une requête mysql pour vérifier que le couple login / mot de passe correspond. Si oui, j'affecte une valeur à une variable $_SESSION. Cette variable me permet de déterminer si l'utilisateur qui navigue sur les pages d'admin est identifié ou pas.

- peut-être une attaque par dictionnaire sur l'authentification ?

C'est possible, mais dans ce cas, comment a-t-il modifié la table user alors qu'il n'y a aucun moyen de le faire sur le site ? Il faut forcément passer par la base de donnée.

- as-tu une page d'admin de la base style phpmyadmin ? Est-il à jour, facile à trouver ? L'authentification forte ?

Il y a l'interface de gestion du serveur mis en place par l'hébergeur. Il est à jour et pas facile à trouver. Le mot de passe permettant d'y accéder est composé de chiffres et de lettres majuscules minuscules qui ne forment pas de mot (genre Uf21sTD5x)

- stockes-tu autre chose dans ta base, qui serait un vecteur d'injection ? La langue ? Le user-agent ? etc.

Non, la seule injection dans ma base que je fais à partir du front office est une inscription à la newsletter : 3 champs textes, nom / prénom / email. Il n'y avait pas de modification dans cette base.
Toutes mes autres tables concernent le contenu du site (texte, titre, image en gros).

Bonjour à tou(te)s.

J'ai récemment eu la désagréable surprise de voir un de mes sites hackés. (Gentillement, juste un texte effacé et deux ajouts pour marquer le passage du hackeur).
Conscient donc que ce site avait des problèmes de sécurité, j'ai donc cherché à comprendre comment il s'y était pris.

Tout d'abord le hackeur est dr.Skain, si il y en a qui connaissent...

Ma page permettant d'accéder à l'administration s'appelle admin.php, ma table stockant les utilisateurs s'appelle user avec les champs id / login / password. Jusque là, je lui ai bien facilité le travail.
Toutes les données passant dans ma requête d'identification sont "sécurisées" avec la fonction mysql_real_escape_string. Le mot de passe est en md5.
Je n'ai aucun upload de fichier possible à partir du front office.

Je ne pense pas à une injection SQL, car dans la base de donnée, la première entrée de la table user avait été modifée par le hackeur.
Le hic, c'est que je n'ai aucune requête dans mon site qui modifie cette table. La seule opération qui se fait dessus est l'identification, donc juste une consultation.

Si vous avez des idées sur la méthode utilisée et sur les développement à faire pour éviter que cela ne se reproduise, je vous en serais très reconnaissant

Merci d'avance.

Non, tu auras cette phrase dès que tu essaieras d'aller dans un dossier où tu n'as pas besoin  d'être. C'est juste la page index du dossier qui empêche l'internaute de se balader un peu partout

Pas trop de rapport avec l'épreuve donc