Discussion :

[redah75]

Bonjour a tous, j'espere que je poste dans la bonne rubrique.
il y a quelques mois notre site a ete pirate et je vois constament des dossiers et milliers de fichiers .html qui sont crees sur le serveur. il y a meme des fichiers .php dont je suis proprietaire qui ont ete modifiés....
ces fichiers contiennent essentiellement de la pub sur la Viagra...
du coup on a ete retiré de l'indexation chez google et je ne sais trop quoi faire
selon notre hebergeur (ovh) il s'agit d'une faille de script PHP.

avez vous une idee svp??

Merci de votre precieuse aide

Reda

[_Mac_]

Ils ont sûrement raison, surtout si c'est un serveur mutualisé. Est-ce que ton site permet d'uploader des fichiers ? Si oui, il faut contrôler ces scripts, c'est souvent la premier porte d'entrée. Après, regarde tout ce qui permet d'écrire des trucs sur le disque.

[redah75]

Merci _MAC_ pour ta reponse.

on est sur un serveur dedié. OVH me demande de regarder dans les logs afin de voir la source de ce piratage mais je ne pense pas avoir les connaissances suffisantes pour ce genre de tache!!

oui, j'ai un script qui permet l'upload de fichiers mais qui est reserve au personnel de la societe et qui normalement est bien securisé!!

pourrait il s'agir du fait que register_globals sont a "on" ?

aurais tu une solution pour ce probleme?

Merci

[_Mac_]

le register_globals à on est une très mauvaise idée, à proscrire absolument.

Pour le script d'upload, il est impératif de le vérifier (s'assurer entre autre qu'on ne peut pas uploader n'importe quel type de fichier et qu'on ne peut pas les mettre n'importe ou) et de vérifier la sécurité : tu dis qu'il est réservé au personnel, mais comment est-ce vérifié ? S'il s'agit d'une sécurité par session (et pas par .htaccess), vérifier qu'on ne peut pas contourner la sécurité, i.e. vérifier sur chaque page le login de la personne, etc.

C'est un serveur dédié donc OVH est clairement hors de cause : si c'est un problème avec le serveur Web, vu que c'est toi (ou quelqu'un d'autre de la société) qui l'a installé, c'est ta responsabilité.

OVH suggère d'aller voir dans les logs d'accès d'Apache s'il y a des URL bizarres qui sont appelées et voir depuis quelle IP. Ca identifiera (mouais...) le PC depuis lequel l'attaque a été faite et surtout comment elle a été faite : c'est ça qui te permettra d'identifier la porte par laquelle le pirate est passé.

[redah75]

je sais que register_globals à on est une mauvaise chose, mais le nouveau site sur lequel je travail fonctionnera bien à off.
en parlant des register_glob, la difference entre on et off mis a part la securite se resulte en l'appellation des variables : $_POST['variable'] au lieu de $variable, c'est ca?

concernant les pages reserves au personnel, elles sont securisées par session et il y a une verification dans CHAQUE page:

Code :

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

1
2
if($_COOKIE['staff_info'][logedin] != 1 || !$_COOKIE['staff_info'][id])
redirection vers la page d'indentification

concernant l'upload des fichiers: je rejete l'upload si le fichier n'est pas un .gif, .jpg, .doc et .pdf et c'est moi qui impose le chemin d'enregistrement du fichier...

quant aux fichiers logs, je ne saurai faire les demarches et retrouver la porte par la quelle la faille a ete identifiee.
aurais tu des liens et/ou des tutos pour ca??

[_Mac_]

en parlant des register_glob, la difference entre on et off mis a part la securite se resulte en l'appellation des variables : $_POST['variable'] au lieu de $variable, c'est ca?

A ma connaissance, oui. C'est $_POST ou $_GET, selon le cas.

[quote=redah75;4811382]concernant les pages reserves au personnel, elles sont securisées par session et il y a une verification dans CHAQUE page:[/code]
$_COOKIE, c'est tout sauf utiliser les sessions !!! Attention, c'est franchement pas terrible cette façon de faire car un cookie ça se forge particulièrement bien. Le cookie contient de surcroît des données en clair (logedin et id), c'est trop évident à quoi ça sert. Avec l'extension Firefox qui va bien, je me fais passer pour n'importe qui sur ton site en créant un en-tête HTTP comme suit :

Code :

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

Cookie: staff_info[logedin]=1; staff_info[id]=1

Il faut utiliser les sessions ($_SESSION) et surtout pas les cookies directement, c'est extrêmement dangereux. A tous les coups, c'est en passant par là que le pirate a agi.

concernant l'upload des fichiers: je rejete l'upload si le fichier n'est pas un .gif, .jpg, .doc et .pdf et c'est moi qui impose le chemin d'enregistrement du fichier...

Comment vérifies-tu le format du fichier et comme imposes-tu le chemin d'enregistrement du fichier ?

quant aux fichiers logs, je ne saurai faire les demarches et retrouver la porte par la quelle la faille a ete identifiee.
aurais tu des liens et/ou des tutos pour ca??

Non, je n'ai pas de lien pour faire ça. J'irais droit au but : ouvrir le fichier de log dans un éditeur de texte et regarder s'il y a des URL qui me semblent bizarres qui traînent. Pour savoir quel fichier de log consulter, je regarderais la date de dernière modification des fichiers piratés.

[redah75]

Il faut utiliser les sessions ($_SESSION) et surtout pas les cookies directement, c'est extrêmement dangereux. A tous les coups, c'est en passant par là que le pirate a agi.

Tu as raison, j'ai clairement deconne sur ce coup la!! je ne peux malheureusement rien faire pour l'instant, j'ai pas trop le courage de recoder mes scripts mais je mets tout de suite une protection .htaccess pour regler ce probleme!!

Comment vérifies-tu le format du fichier et comme imposes-tu le chemin d'enregistrement du fichier ?

j'ai mis en place une fonction PHP:

Code :

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

1
2
3
4
5
6
$type = $_FILES[$name_field]['type'];
  if($type == "application/pdf") // pour les .pdf
 {
  if(!move_uploaded_file($tmp_pdf, $path_pdf)) $er_pdf = 8; // erreur de copie
 }
 else $er_pdf = 13; // le fichier n'est pas au bon format

Non, je n'ai pas de lien pour faire ça. J'irais droit au but : ouvrir le fichier de log dans un éditeur de texte et regarder s'il y a des URL qui me semblent bizarres qui traînent. Pour savoir quel fichier de log consulter, je regarderais la date de dernière modification des fichiers piratés.

je vais voir ce que je peux faire

[_Mac_]

Que vaut ou comment est calculé $path_pdf ? Le fait de vérifier le content type est une chose, mais une fois de plus, ça se truque car c'est une information envoyée par le navigateur

[redah75]

Que vaut ou comment est calculé $path_pdf ?

de cette maniere: $path_pdf = "../chemin/";
tu veux encore me demoraliser?????

je viens de mettre en place une protection .htaccess mais je viens de me rendre compte que le hacker a egalement pu acceder et inserer des fichier et dossiers a un dossier deja securisé par .htaccess et .htpasswd. comment est ce possible?

[_Mac_]

Ben c'est pour ça que je demande comment $path_pdf est calculée : pas besoin de demander une page d'un dossier pour créer ou modifier un fichier de ce dossier. C'est bien ce que tu fais avec ton script : le fichier est uploadé dans un certain répertoire temporaire et tu déplaces le fichier dans un répertoire cible qui n'est pas celui dans lequel se trouve le fichier d'upload. Mais vu la façon doit $path_pdf est définie, ce fait reste un mystère. Pourquoi passer par une variable $path_pdf et ne pas appeler directement move_uploaded_file($tmp_pdf, "../chemin/") ? Tu es sûr que $path_pdf n'est pas modifiée juste avant son utilisation dans move_uploaded_file ?

[Invité]

Bonjour,
J'ais réglé définitivement ce type de probléme sur des forums, avec simplement l'URL et quelques fichiers que je ne peut capter moi-même.

C' est sans garantie, mais mets moi ton URL en Message Privé, ou ici
en MP je te donnerais mon adresse mail. tu pourras ainsi m'envoyer zipé les htaccess (par les password je n'en ais pas besoins)

Si tu as un excelent antivirus et que ton site ne fais pas 10Gigas tu as intéret a tout recharger sur ton micro dans un répertoire provisoir et le scaner. une fois la bréche ouverte les hackeurs se créent une porte (souvent dans une feuille de style ou autre ) bien sur inutile de scaner ta version a toi si elle est déjas sur ton micro !!

Voila a toi de voir, mais ce n'est qu'une piste.

[redah75]

Pourquoi passer par une variable $path_pdf et ne pas appeler directement move_uploaded_file($tmp_pdf, "../chemin/") ? Tu es sûr que $path_pdf n'est pas modifiée juste avant son utilisation dans move_uploaded_file ?

l'upload du fichier est dans une fonction qui sert a uploader des fichiers depuis plusieurs pages web, ainsi je passe la variable $path_pdf en parametre...

Bonjour,
J'ais réglé définitivement ce type de probléme sur des forums, avec simplement l'URL et quelques fichiers que je ne peut capter moi-même.

C' est sans garantie, mais mets moi ton URL en Message Privé, ou ici
en MP je te donnerais mon adresse mail. tu pourras ainsi m'envoyer zipé les htaccess (par les password je n'en ais pas besoins)

Si tu as un excelent antivirus et que ton site ne fais pas 10Gigas tu as intéret a tout recharger sur ton micro dans un répertoire provisoir et le scaner. une fois la bréche ouverte les hackeurs se créent une porte (souvent dans une feuille de style ou autre ) bien sur inutile de scaner ta version a toi si elle est déjas sur ton micro !!

Voila a toi de voir, mais ce n'est qu'une piste.

Merci pour ta reponse, je vais faire une sauvegarde de mes fichiers web et formater le serveur et changer tous les codes, j'espere que cela resoudra un peu le pribleme!!


j'ai une petite question concernant les register_glob, si c'est a off, ca nous oblige de traiter les variable de cette maniere: $_POST, $_GET, mais faut il toujouts les verifier avec if(isset($_POST)) ... ??
comment declarer une variable qui sera utilisee au sein de la page web? $variable = "valeur"; suffira??

[Invité]

Oh oui je penses comme MAC register_glob est un trou béant pour les hackeurs !
Alors oui il faut contrôler, du reste je vais (pour bien connaitre le sujet)
te donner ma méthode OUI je sais ça va te faire du travail, mais tu le vois bien ça vaut la peine pour éviter tes ennuis !
en téte de toutes mes pages PHP je traites toujours mes sessions cookies post et get .......... ça me crée une variable (que je peux laisser du même nom que mon post session ou get,) et aprés je n'utilises plus que cette variable ce qui est bien plus facile !

Code :

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

1
2
3
4
5
6
7
8
<?PHP
if (isset($_POST["avi"])) $avi=htmlentities(trim($_POST["avi"]));
    else $avi="";

//======== ensuite un simple
if ($avi!="") // ======existe
?>

[_Mac_]

L'autre technique consiste à créer une fonction qui récupère la valeur dans $_POST ou $_GET ou renvoie "" si rien n'est trouvé :

Code PHP :

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

1
2
3
4
5
6
7
8
9
function get_param($name) {
    if (isset($_POST[$name])) {
        return $_POST[$name];
    }
    if (isset($_GET[$name])) {
        return $_GET[$name];
    }
    return "";
}

[redah75]

oh lala, je suis competement perdu, a quoi servent les codes que vous avez mentionne?? est ce pour eviter de mettre a chaque reprise $_POST['']... ?? si oui, je vois pas trop comment ca marche, si vous pouvez m'eclairer un peu svp!!

[Invité]

Si tu a un imput avi et que tu valide ton FORM
alors tu récupéres l'imput avi comme cela

Code :

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

1
2
3
4
5
6
7
8
9
10
11

<?PHP
if (isset($_POST["avi"])) $avi=htmlentities(trim($_POST["avi"]));
    else $avi="";
//========= tu peux de ce fait traiter ton control propre a cette valeur
//======== ensuite un simple
if ($avi!="") // ======existe

// Etc ...
?>

Oui tu as intéret a perdre l'abitude de réutiliser POST partout car si non, il te faut TOUT recontroler, tu comprends bie que si $avi est hyper controlé tu peux l'utiliser partout ensuite.

[redah75]

ahhh, le nom de la variable avi est choisi a tout hasard, je pensais que c'etais quelque chose de specifique...

pas mal pense ca
mais si j'ai un formulaire d'une 15ene ou 20 ene de champs, comment faudrait il faire?
le htmlentities est obligatoire???

[Invité]

ahhh, le nom de la variable avi est choisi a tout hasard, je pensais que c'etais quelque chose de specifique...
pas mal pense ca
mais si j'ai un formulaire d'une 15ene ou 20 ene de champs, comment faudrait il faire?
le htmlentities est obligatoire???

Non htmlentities n'est pas obligatoire, c'est selon ce que tu attends comme données par contre le trim OUI !
Si tu as 100 $_POST $_FILE $_GET $_SESSION $_COOKIES tu fais pareil, mais tu vois c'est fait une fois pour toute et cela te permets dés le début de ta page d'avoir tout maitrisé.

Mieux encore, comme a ce moment précis tu n'as encore généré aucun header (tu n'as encore rien envoyé coté visiteur) tu peux encore faire un header de redirection !

Cela veut dire que ta page est sous control et aprés tu utilises que des variables sans risque !

[redah75]

Si tu as 100 $_POST $_FILE $_GET $_SESSION $_COOKIES tu fais pareil

ummm, pas tout a fait convaincu, je pense qu'il doit y avoir une sorte de boucle du genre:

Code :

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

foreach($_SESSION ou $_POST as $cle => $nom) { ... }

Mieux encore, comme a ce moment précis tu n'as encore généré aucun header (tu n'as encore rien envoyé coté visiteur) tu peux encore faire un header de redirection !

excuse moi mais là encore j'ai un peu de mal a suivre

[Invité]

ummm, pas tout a fait convaincu, je pense qu'il doit y avoir une sorte de boucle du genre:

Code :

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

foreach($_SESSION ou $_POST as $cle => $nom) { ... }

excuse moi mais là encore j'ai un peu de mal a suivre

Non parceque le but de ma méthode (longue je te l'accordes)
est que je traite cas par cas les contrôles complémentaires (les plus importants) en fonction de chaque variable !