Protection contre le hacking sur mes upload

Bonjour,

Dans le backoffice de mon site, il y a la possibilité d'uploader des images pour illustrer les pages du site.
Le soucis c'est que des hackers réussissent à accéder à l'upload et téléchargent des images qui ne le sont pas en fait mais ce sont des PHP renommés en .gif ou en .jpg, ils connaissent le chemin où sont les fichiers uploadés et appellent juste donc la fausse image pour lancer le PHP.

Comment vais-je me protéger? Je me demande même comment ils arrivent à exécuter ce fichier php renommé en jpg

[magicbisous-nours]

Au moment de l'upload tu vérifies comment le type de fichier ? par l'extension ?
Si c'est le cas tu peux tester par le MIME TYPE du fichier uploadé.
Tu as une fonction en PHP appelée finfo qui devrait pouvoir t'aider :
http://fr.php.net/manual/fr/function.finfo-file.php

Oui c'est ça, je testais l'extension! Mais bon tester le contenu du fichier ralentirait aussi le site

Je pense que je dois aussi chercher les moyens pour que le hacker ne puisse pas accéder au formulaire d'upload. Le soucis c'est qu'il faut s'authentifier pour ouvrir le formulaire mais pour l'upload il n'y en a pas puisque j'utilise un code tiers

[magicbisous-nours]

Tester le type MIME est plutôt rapide.... Je l'utilise sans voir de ralentissement (même si j'avoue que mon script n'est pas très long et mon traitement ne fait pas grand-chose)...
De plus en testant le type MIME tu ne lis pas le fichier complet mais des informations que le fichier détient (un peu comme un header d'une requête HTTP pour simplifier)...
Au pire essaye et si tu vois une perte de perf' trop importante reviens sur ta version précédente...

[Helfima]

tu n'as pas le choix faut tester le type MIME comme dit plus haut une extension de fichier n'a aucune valeur sure

Le fond du problème n'est pas vraiment que le hacker upload un faux jpg ou gif mais qu'il accède au script d'upload sans s'authentifier

L'authentification est gérée par une classe php qui crée une variable globale $GLOBAL["user"], or j'utilise un code tiers (ajaxfilemanager) pour l'upload d'image donc je me me demande comment peut-on l'utiliser dans ajax_file_upload.php de AjaxFileManager for TinyMCE???

Envoyé par Helfima

tu n'as pas le choix faut tester le type MIME comme dit plus haut une extension de fichier n'a aucune valeur sure

Même ça, il y a déjà une technique pour le contourner par les hackers, de plus le plus drôle: http://www.phpclasses.org/blog/post/...IF-images.html

Ce que je cherche aussi c'est comment interdire l'exécution de scripts dans un répertoire par htaccess ou autre?
En effet, je suis victime du hack avec un upload d'un fichier "pic.php.gif", je ne comprends pas comme le hacker arrive à exécuter ce fichier moitié GIF moitié PHP

[magicbisous-nours]

essaie de mettre les permissions sur ton fichier à 666 (c'est à dire en lecture/écriture mais pas en exécution) mais je ne suis pas sûr que ça fasse grand-chose...

[Helfima]

Envoyé par Lucas Panny

Bonjour,
téléchargent des images qui ne le sont pas en fait mais ce sont des PHP renommés en .gif ou en .jpg, ils connaissent le chemin où sont les fichiers uploadés et appellent juste donc la fausse image pour lancer le PHP.

1) un fichier ne se terminant pas par .php ne devrai jamais être exécuté, sinon il y a un gros problème de réglage sur le serveur
vérifier la liste des extensions exécutables

2) test du type mime

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
/**
* @filesource image.gif.php
* @author helfima
* @version 1.0
* Date 19 janv. 2011
*/
 
Header('Content-Type: image/gif');
 
$filename = 'test.txt';
$somecontent = "Ajout de chaîne dans le fichier\n";
 
$fp = fopen($filename, 'w');
fwrite($fp, $somecontent);
fclose($fp);

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
/**
* @filesource fileinfo.php
* @author helfima
* @version 1.0
* Date 19 janv. 2011
*/
 
$finfo = new finfo(FILEINFO_MIME); // Retourne le type mime
 
if (!$finfo) {
    echo "Échec de l'ouverture de la base de données fileinfo";
    exit();
}
 
/* Récupère le mime-type d'un fichier spécifique */
$filename='C:/portal/src/test/image.gif.php';
if(file_exists($filename)){
	echo $filename.' existe!<br>';
}
echo 'mime-type: '.$finfo->file($filename);

resultat de fileinfo.php

C:/portal/src/test/image.gif.php existe!
mime-type: text/x-php; charset=iso-8859-1

conclusion: le fichier retourne bien le bon type et ce quelque soit le code dedans par conséquent quand tu upload le fichier a toi de tester le type mime avant la copie dans un répertoire tant qu'il se trouve dans le temp du serveur comme cela fini le problème

ps: si un hacker a déjà déposé des fichiers il faut
bloquer ton site
faire le ménage de fichier intrus
changer tous les passwords

voila j'en sais pas plus
bon courrage

[nextdev]

Salut, il faut que tu arrive a mettre un test de la fameuse variable $GLOBAL["user"] avant que l'upload ne commence.

Tester le type mime, c'est bien aussi et te le conseil, mais ça n'empechera pas l'intrus d'uploader.

[Helfima]

regarde ceci http://php.net/manual/fr/security.globals.php

[nextdev]

Envoyé par Helfima

regarde ceci http://php.net/manual/fr/security.globals.php

Aucun rapport... et puis register globals activé ou non, ça n'empèche pas d'utiliser le tableau GLOBALS et sa porté.

Envoyé par nextdev

Salut, il faut que tu arrive a mettre un test de la fameuse variable $GLOBAL["user"] avant que l'upload ne commence.

Tester le type mime, c'est bien aussi et te le conseil, mais ça n'empechera pas l'intrus d'uploader.

Oui, le test du type MIMI ne l'empêchera pas, c'est pour ça qu'il uploade un fichier d'extension .php.gif qui contient effectivement du code binaire gif terminé par point-virgule suivi de code PHP malicieux

La portée de $GLOBAL["user"] n'atteigne pas en fait le code tiers d'upload d'image. Donc je remets la classe d'authentification utilisée par mon site dans le code de l'upload donc un 2ème formulaire de connexion lors de l'upload, c'est le mieux qu'on puisse faire

[nextdev]

Un bon moyen serait d'avoir un $_SESSION['user'] plutot que $GLOBAL afin de le récupérer facilement sur les pages appelées lors de l'upload.

Envoyé par Helfima

1) un fichier ne se terminant pas par .php ne devrai jamais être exécuté, sinon il y a un gros problème de réglage sur le serveur
vérifier la liste des extensions exécutables

............................

ps: si un hacker a déjà déposé des fichiers il faut
bloquer ton site
faire le ménage de fichier intrus
changer tous les passwords

voila j'en sais pas plus
bon courrage

Je résume donc:
- ce n'est pas un soucis de passwords découverts
- le hacker upload bien un fichier pic.php.gif et il arrive à l'exécuter mais je ne sais pas COMMENT ???

nextdev>
Effectivement c'est de la session, de plus je n'aime pas trop le $_SESSION['user'] car je suis sur du mutualisé

Code :

1
2
3
4
5
6
7
8
9
10
11
 
class MonsiteUser{
        public static function GetInstance() {
            // CLASSIC
            if (empty($_SESSION["monsite" . session_id()])) {
                $_SESSION["monsite" . session_id()] = new MonsiteUser;
            }
            return $_SESSION["monsite" . session_id()];
        }
.................
$GLOBALS["user"] = MonsiteUser::GetInstance();

[magicbisous-nours]

Pour résumer ce qui a été dit :
- Vérifie la conf de ton serveur (httpd.conf pour apache)
- Lors de l'upload vérifie le type MIME du fichier uploadé et refuse tout ce qui n'est pas une image
(un simple

Code :

1
2
3
4
 
if(substr($t_mime,0,5) == 'image') { 
// ton code qui gère les fichiers images (redimensionnement, déplacement, etc...)
}

suffira)

[nextdev]

Effectivement c'est de la session, de plus je n'aime pas trop le $_SESSION['user'] car je suis sur du mutualisé

Béh sans stocker l'info que l'user est deja logger, c'est sur que tu devras lui redemander. Au pire tu rajoute juste $_SESSION['user_is_logged']=1 (en parallèle a ton GLOBAL['user']) que tu controle dans la page d'upload

Pourquoi ne pas utiliser la session, es tu chez ovh ?

[gene69]

c'est quoi le problème des sessions chez OVH? chez moi tout fonctionne à merveille.

je suis un peu déçu parce que le titre du message était croustillant et que la solution est plutôt standard.

[ABCIWEB]

Et tu as pensé à faire un getimagesize lors de l'upload de tes images ? Normalement ce test est assez restrictif et comme vous n'en avez pas encore parlé...

[nextdev]

Il n'y a justement pas de problème chez ovh, et d'ailleurs le répertoire /tmp/ ou sont stocké les sessions par défaut n'est plus accessible sur leurs serveurs.

Donc leur config de base en mutualisé ne pose a priori plus de risque, ou pas plus qu'un dédié.