web-dev-qa-db-fra.com

Est-il possible d'exécuter un script php dans un fichier image?

J'ai un site Web de téléchargement d'images php. Les utilisateurs peuvent télécharger des images sur mon site Web. Un utilisateur affirme qu'il peut pirater mon site Web à l'aide d'une image téléchargée.

J'ai ouvert toutes les images qu'il a téléchargées sur mon serveur avec le bloc-notes. La dernière ligne d'une image est:

Àpa@ ;
<?php

echo "test ok";
?>

Peut-il pirater mon site Web en utilisant cette image? Comment empêcher les utilisateurs de télécharger des images comme celle-ci?

web-applicationphpwebserver
18
open source guy

Les téléchargements d'images (tous les fichiers en général) sont très difficiles à sécuriser complètement - en particulier en PHP, qui fournit de nombreux vecteurs d'attaque.

Si vous, par exemple, affichez l'image en appelant

require($someImage);

et cette image a PHP à l'intérieur (comme celle que vous avez publiée), elle peut être interprétée et exécutée comme telle.

Je suppose que s'il prétend être propriétaire de votre site, il l'a probablement. L'image que vous avez fournie en elle-même ne fera rien sauf imprimer "test ok", mais ce code pourrait facilement être échangé contre une partie qui donne un accès non autorisé (même totalement illimité) à votre site et à votre serveur.

Pour vous assurer que le fichier téléchargé sur votre site est bien une image, retraitez-le à l'aide de Gd (ou Imagick) et enregistrez l'image traitée. C'est une mauvaise pratique de sauvegarder l'image d'origine, en particulier en utilisant le nom du fichier d'origine, car cela ouvre de nombreuses autres attaques (par exemple, traversée de répertoire et écrasement de fichier).

Plus d'informations: https://www.owasp.org/index.php/Unrestricted_File_Upload

13
GBC

Oui, votre serveur pourrait exécuter le code PHP dans un fichier image s'il n'est pas configuré correctement:

http://www.phpclasses.org/blog/post/67-PHP-security-exploit-with-GIF-images.html

Un exemple de cela est image.gif.php. Un fichier peut être à la fois une image valide et un script PHP valide, il ne suffit pas de simplement vérifier la taille de l'image ou d'autres propriétés . Il ne suffit pas non plus de supprimer les métadonnées , un GIF non compressé peut contenir PHP comme données d'image (bien que cela puisse être indécent), PNG prend en charge morceaux de données arbitraires .

La faille accepte les téléchargements avec une vérification de l'intégrité insuffisante, essayant spécifiquement d'empêcher les noms de fichiers indésirables (par exemple .php) En utilisant une expression régulière non ancrée comme \.(png|gif|jpg|jpeg) (pas d'ancre $) , et permettant à ces images d'être servies à partir d'un répertoire avec le traitement PHP activé. La meilleure pratique est que vous ne devriez probablement jamais utiliser tel quel le nom de fichier fourni par l'utilisateur.

Ce sont des échecs assez classiques validation des données et validation des entrées .

Si vous suivez les instructions d'installation PHP (pour Apache 2) vous aurez quelque chose comme ça dans votre configuration Apache:

<FilesMatch "\.ph(p[2-6]?|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>

Notez l'ancre $, Cela empêchera file.php.gif D'être interprété par PHP. (Ce qui manque dans ces instructions est de s'assurer que PHP est limité par un contexte <Directory> Contenant uniquement du code de confiance et non accessible en écriture par l'utilisateur du serveur Web .)

Si vous ne suivez pas ces instructions et utilisez à la place mod_mimeAddType (ou AddHandler):

AddType application/x-httpd-php .php      # STOP!

Cela peut provoquer le même problème car mod_mime Peut faire quelque chose que vous n'attendez pas avec plusieurs extensions. Voir http://blog.dynom.nl/archives/Be-careful-with-double-extensions_20081024_25.html (merci à Hendrik Brummermann pour l'avoir signalé) . Ce risque peut être atténué avec un contexte <Directory> Correctement configuré pour autoriser uniquement le code approuvé.

Ce document (PDF) est un peu ancien, mais il couvre bien les atténuations: http://www.net-security.org/dl/articles/php-file-upload.pdf

Une autre source possible de problèmes est les instructions include/require non sécurisées (également couvertes dans ce PDF) qui permettent à un attaquant de include télécharger du contenu en modifiant les chaînes de requête ou les en-têtes de requête HTTP.

Voir aussi la récente question connexe: Risques d'un PHP formulaire de téléchargement d'image (bien que je ne pense pas qu'il soit correct de s'appuyer sur getimagesize pour vérifier les images), et tilisez PHP pour vérifier la présence de logiciels malveillants dans le fichier image téléchargé? (qui contient un ensemble utile de liens).

20
mr.spuratic

Je vais supposer que vous utilisez LAMP (et une réponse pour d'autres configurations php serait très similaire).

Très probablement, son code ne peut rien faire pour votre site.

Supposons qu'Apache diffuse des fichiers sur /var/www sur votre serveur. Dis que quelqu'un visite index.php sur votre site Web.

  1. Apache recevra qu'ils recherchent /index.php
  2. Apache recherchera le fichier /var/www/index.php

  3. Si Apache exécute mod_php, il vérifiera si index.php correspond d'une manière ou d'une autre à une règle du fichier de configuration mod_php. Votre fichier de configuration mod_php (probablement à /etc/Apache2/mods-available/php5.conf) est très probablement un surensemble de cet exemple minimal que j'ai créé ci-dessous:

    <IfModule mod_php5.c>
    <FilesMatch ".+\.ph(p[345]?|t|tml)$">
        SetHandler application/x-httpd-php
    </FilesMatch>
</IfModule>
    • Si le nom du fichier correspond, Apache exécutera le fichier via un interpréteur php, créant une page Web qu'il servira à l'utilisateur.
    • Si le nom du fichier ne correspond pas, Apache le servira simplement à l'utilisateur.
    • (Ces détails ignorent de nombreux morceaux d'Apache que je ne pense pas pertinents ici)

Supposons qu'un utilisateur télécharge une image, par exemple evil_image.png, et il contient du code arbitraire PHP.

Supposons également que vous le diffusiez aux utilisateurs de quelque part, par exemple à /images/evil_image.png (donc dans votre système de fichiers, /var/www/images/evil_image.png).

Lorsque quelqu'un essaie de récupérer cette image en accédant à votre site Web à /images/evil_image.png, Apache exécutera les étapes décrites ci-dessus. À l'étape 3, /images/evil_image.pngne correspondra pas au modèle à partir de votre fichier de configuration, donc vous n'exécuterez pas le code en php. Vous servirez simplement l'image à l'utilisateur.

L'utilisateur recevra le fichier image qui contient le texte spécialement conçu. Ce qui est important, c'est que votre serveur n'ait pas essayé d'exécuter le code, le rendant inefficace.

Je ne dis pas qu'il est impossible d'exécuter ce code. Je vous dirai que vous devez cruellement manquer de configurer votre serveur Web pour que ce code soit exécuté.

1
David Mah