Bonjour !
J'ai regardé un peu le code que tu essayes de modifier, et franchement,
il est bien pourri : mal structuré, peu lisible, aucun cas de la
sécurité... Tu ferais peut-être mieux de tout reprendre.
Plus spécifiquement, pour ton problème de fichier temporaire que tu veux
effacer, la meilleure solution est sans doute de ne jamais le créer. Tu
peux t'inspirer de ce qui est fait dans thomascube/vcfconvert, qui est
un code autrement mieux écrit. Au lieu d'écrire le résultat dans un
fichier que l'utilisateur devra ensuite télécharger, tu l'envoies
directement au client :
header('Content-Type: text/vcard');
header('Content-Disposition: attachment; filename="contacts.vcf"');
for ($i = 0; $i < $vcard_count; $i++) {
print "BEGIN:VCARD\n";
...
print "END:VCARD\n"
}
exit;
Deuxième solution (mais qui est moins bien), tu fais comme l'auteur de
csv2vcf : tu utilises cron
« everyday at midnight the uploaded files will be securely deleted
(cronjob). » [1]
Remarque que c'est une solution pourrie du point de vue de la sécurité
des données : un utilisateur qui se connecte peu avant minuit a la
possibilité de télécharger les listes de contacts envoyées par les
autres utilisateurs la même journée, pourvu qu'il arrive à deviner les
noms des fichiers. Tu pourrais mitiger le problème en faisant tourner le
cron plus souvent. Pour le résoudre complètement, il faudrait mettre en
œuvre un mécanisme de sessions, et permettre à l'utilisateur de
récupérer uniquement les fichiers créés dans sa propre session. Ça
ajoute une bonne dose de complexité.
Troisième solution, dans le script PHP, tu ajoutes un bout de code qui
va effacer *tous* les fichiers créés dans le répertoire concerné qui
sont âgés de plus que, disons, cinq minutes. Ça ne règle pas le problème
de fuite de données, mais ça peut aider à rétrécit la fenêtre de
vulnérabilité sans trop faire mouliner cron. Mais si tu as peu de
trafic, tu auras un de ces fichiers temporaires qui traîne pendant
longtemps...
> Mon idée, c'était de passer en paramètre dans le href le nom du
> fichier avec le paramètre du fichier à détruire
Oublie, c'est vraiment une mauvaise idée. Non, je suis sérieux, oublie.
C'est *vraiment* une très mauvaise idée.
> Je mettais basé ici pour pondre mon bout de code
> https://openclassrooms.com/fr/courses/918836-concevez-votre-site-web-avec-php-et-mysql/912799-transmettez-des-donnees-avec-lurl
Cet article insiste lourdement sur le fait qu'on ne peut pas faire
confiance aux données envoyées par le client. La section « Ne faites
jamais confiance aux données reçues ! » représente même plus de la
moitié de l'article. Mais visiblement il n'a pas insisté assez ! Il va
falloir remettre une couche...
Le contenu de $_GET est contrôlé par le client. Quand tu fais
$fich_temp = $_GET['retour']
unlink($fich_temp)
tu effaces le fichier que le client te dit d'effacer, sans te poser la
question de savoir si c'est raisonnable de faire ça.
> bon, on fait comment?
On vérifie que ce que dit le client est acceptable. Par exemple, s'il te
demande d'effacer "/bin/bash", il vaudrait mieux que tu ne trouves pas
ça acceptable. Typiquement la vérification se fait en s'assurant que ce
qui est envoyé correspond à une regexp. A minima, il faudrait interdire
la présence de "/" et les noms de fichier qui commencent par ".", mais
idéalement tu devrais whitelister un ensemble de caractères non
dangereux et interdire tous les autres.
Marc Berlioux a écrit :
> Tu peux valider les données côté client par du script JS
On parle ici de sécurité : on ne valide rien côté client, vu que ça
apporte zéro sécurité. « Ne faites jamais confiance aux données
reçues ! »
La « validation » côté client sert uniquement au confort de
l'utilisateur bien intentionné. Ça lui permet de savoir qu'il a mal
rempli un formulaire sans devoir pour cela attendre une ou deux secondes
la réponse du serveur. C'est *exclusivement* une fonctionnalité de
confort, rien de plus. Zéro sécurité.
Anne a répondu :
> Connais pas js. Je vais creuser.
NOOOON !!! Oublie ça tout de suite ! C'est la pire des idées ! Le JS
c'est une façon de dire au client « Dis, avant de m'envoyer ces données,
est-ce que tu pourrais s'il te plaît vérifier qu'elles ne contiennent
rien de malveillant ? » Tu vas dire ça au pirate qui s'apprête à
attaquer ton site, et ensuite tu lui fais confiance pour faire ces
vérifications à ta place ?
> J'ai fait avec post mais ce n'est peut-être pas mieux.
Ben non, c'est pas mieux. $_POST, tout comme $_GET, contient des
informations envoyées par le client. « Ne faites jamais confiance aux
données reçues ! »
En résumé, l'idée de demander au client de te dire quel fichier tu dois
effacer est complètement foireuse. Oublie ça et essaye, par exemple,
l'une de trois solutions que je propose plus haut.
Ah oui, j'ai failli oublier un rappel important : « Ne faites jamais
confiance aux données reçues ! »
À+,
Edgar.
[1]
https://dwaves.org/2016/06/30/csv2vcf-online-converter/
