Discussion :

[scamphp]

Bonjour

Pour récupérer des variables en toute sécurité, on doit utiliser des filtres, mais pour les images on fait comment ?

J'ai trouvé des tutos qui explique que l'on peut limiter l'envoi en fonction de la taille, du type de fichier etc...

Si j'ai bien compris le fichier est téléchargé dans un dossier temporaire et si on valide, on le déplacer dans un dossier définitif pour l'enregistrement.

Que doit-on faire pour sécuriser l'upload, car il peut exister des Virus et des script dans les fichiers image.

Pour les mails on nous demande d'avoir un anti-virus... mais sur mon site, je peux faire quoi ?

[scamphp]

Interdire la double extension nom.jpg.php est suffisant ???

[rawsrc]

salut,

je ne vois pas trop l'intérêt de la question...
Si c'est une image, tu l'affiches comme telle c'est à dire que cela sera toujours dans une balise <img src="">.
Tu peux toujours essayer de vérifier que les premier octets correspondent bien à un .jpg ou .png mais après tu ne dois jamais manipuler ce fichier autrement que comme une image.

[scamphp]

Je reformule ma question.

Quand on réceptionne des pièces jointes image, vidéo un peu tout... il arrive qu'un fichier puisse contenir un virus et il ne faut pas l ouvrir en espérant que l anti virus le détecte avant manipulation...

Idem quand on télécharge un fichier.... ou que l on récupère la clé usb de quelqu'un

On risque de récupérer de tout... virus malware, vers, cheval de troie....

Donc quand sur son site on autorise l envoie de fichier il est possible de récupérer un fichier douteux.

Comment pour sécuriser la réception de fichier... avant justement de les manipuler...

[Invité]

Bonjour,

il faut au moins vérifier l'extension (-> définir les extensions autorisées) et le type mime réel du fichier.

• exemple.

[scamphp]

Je suis surpris que cela soit suffisant...

Il existe des anti virus avec des basés de données listant des milliers de virus, cheval de troie, malware....

Alors qu il faut juste vérifier l extension et le Mime...

[CosmoKnacki]

C'est une bonne question.
On ne peut pas vérifier de façon formelle qu'un fichier ne contient pas de code malveillant, que ce soit en vérifiant l'extension (qui n'est qu'une convention), le type mime (qui se bidonne comme on veut), le header via finfo::file (idem) ou encore en utilisant un antivirus (qui même avec une analyse heuristique poussée passera à coté d'une stéganographie un peu élaborée et qui ne pensera pas forcément à mal devant un simple script).

La solution ne consiste pas à vérifier, mais à modifier pour désactiver l'éventuel code malveillant en ré-encodant l'image, en modifiant sa taille, son format, et probablement d'autres actions..., sachant que chacune des ces actions va modifier les octets du fichier de manière à "détruire" l'éventuel code et peut être pratiquée de manière invisible pour l'œil humain.
Ces modifications peuvent être faites par exemple avec la bibliothèque gd (en étant attentif aux erreurs ou aux valeurs par défaut renvoyées par certaines méthodes qui peuvent être un signe de malformation du fichier, donc en lisant bien la doc).
Il existe aussi d'autres bibliothèques que gd comme ImageMagic et gmagic, et sûrement d'autre voies pour le faire, mais quelque soit celle choisie, il ne reste qu'à espérer qu'elle ne contienne pas de faille logicielle exploitable par un image! (Ce qui implique d'être attentif aux mise à jour et aux correctifs de sécurité de la bibliothèque en question).
Bien entendu le fichier en question ne doit pas être accessible depuis l'extérieur avant d'avoir subit ce ré-encodage.

[scamphp]

Les manipulation par GD ou imagick ne sont-elles pas des fonctions qui risque d'exécuter le fichier douteux ?
Cela permet de manipuler l'image en toute sécurité ? (modifications format, taille, compression...).

[CosmoKnacki]

À ma connaissance, deux types d'attaques seraient pensables pour ces bibliothèques:

• la première nécessite qu'un cheval de Troie soit déjà installé sur le système. Celui-ci, surveille un (ou plusieurs) logiciel qui charge des images, et lorsqu'une image est chargée, il cherche dans l'image si le code malveillant s'y trouve et l'exécute. Donc à priori, en partant d'un système sain, ça ne peut pas arriver.
• la seconde exploite une faille logicielle qui fait qu'une partie des données de l'image se retrouve dans une zone exécutable de la mémoire, c'est la technique du buffer overflow. D'où l'importance d'être à jour et d'appliquer les correctifs.

[scamphp]

Merci pour les réponses très constructives...

1°) Et concernant les fichier type PDF ou video c'est quoi la stratégie dans les grandes lignes...

2°) comment les CMS protègent ils les utilisateurs des virus... 90% des sites sont basées sur des CMS type Wordpress... par des gens qui ne sont pas forcement sensibilisés à la sécurité et pourtant tous les sites ne sont pas infectés (ou tous les forums type developpez.net et petites annonces type le bon coin). Ils doivent en voir passer des fichiers douteux plusieurs fois par jours

[CosmoKnacki]

1°) Et concernant les fichier type PDF ou video c'est quoi la stratégie dans les grandes lignes...

Pour les PDFs, c'est essentiellement dû au fait qu'il peut contenir du javascript ou du vbs, mais un scan avec un antivirus à jour (ClamAV) te prémunira des scripts malicieux connus.
Pour les vidéos, c'est exactement la même problématique que pour les images (un trojan déjà présent sur la machine qui cherche un code dissimulé dans la vidéo ou l'exploitation d'une faille logiciel), donc un ré-encodage (avec ffmeg ou libav) comme pour les images.

2°) comment les CMS protègent ils les utilisateurs des virus... 90% des sites sont basées sur des CMS type Wordpress... par des gens qui ne sont pas forcement sensibilisés à la sécurité et pourtant tous les sites ne sont pas infectés

Ça ça reste à prouver! Plaisanterie mise à part, la cible d'un code malvaillant n'est pas forcément le site lui-même ou le serveur qui l'héberge, mais le poste de l'utilisateur. Par contre le site servira de vecteur (comme les ragondins pour la leptospirose).

Pour ce qui est de WordPress précisément, lorsque l'éditeur d'une page introduit une image, il y a un module qui permet d'ajuster sa taille, de la "croper" et autres, donc il est possible de ré-encoder l'image (ce module utilise gd ou imagemagick). Pour ce qui de l'upload de fichier par un usager du site, un module comme wp-file-upload ne fait que des vérifications utiles au processus d'upload mais ne recherche pas les virus dans la foulée (ce n'est pas son rôle). Libre au développeur de faire des vérifications et des modifications supplémentaires soit en les codant lui-même soit en cherchant un module qui s'en charge.

Mise à part, les virus dont il est question dans cette discussion, WordPress est particulièrement vulnérable, car il est répandu, pas forcément à jour, pas forcément sécurisé par les néophytes. La multitude de plugins et de thèmes sont autant de flancs supplémentaires quand ils ne contiennent pas eux-même un code malicieux d'entrée de jeu. De plus il y aura toujours un temps relativement important entre l'exploitation d'une faille de sécurité et sa correction. Bien sûr ça peut s'appliquer aussi à d'autres moteurs de Blog, aux CMS, aux forums ou à de simples composants (PHPMailer en est le parfait exemple avec sa longue tradition de failles de sécurité aux conséquences potentiellement apocalyptiques).