Sécuriser un gestionnaire de fichiers PHP de ses utilisateurs

Question

Bonjour à tous, je développe un site Web de partage de photos à l'aide du framework PHP CodeIgniter . L'idée est que les gens puissent télécharger leurs photos, les gérer (via un navigateur de fichiers qui leur permet de créer des sous-dossiers, de faire glisser des fichiers, etc.) et de les éditer (des opérations de base telles que le redimensionnement, la rotation et le recadrage, etc.). plus tard, je vais ajouter quelques fonctionnalités avancées).

J'ai déjà mis en œuvre une solution d'authentification tierce pour CI ( Redux Authentication 2 Beta ) et j'intègre maintenant un gestionnaire de fichiers JS / PHP ( AjaxExplorer ), mais le problème est que le serveur PHP pour la gestion des fichiers (déplacement, copie, etc.) fait trop confiance à la saisie de l'utilisateur à partir des appels ajax. Par exemple, il s’agit de choses comme ceci (simplifiées pour plus de clarté):

move_uploaded_file(
 Bonjour à tous, je développe un site Web de partage de photos à l'aide du  framework PHP CodeIgniter . L'idée est que les gens puissent télécharger leurs photos, les gérer (via un navigateur de fichiers qui leur permet de créer des sous-dossiers, de faire glisser des fichiers, etc.) et de les éditer (des opérations de base telles que le redimensionnement, la rotation et le recadrage, etc.). plus tard, je vais ajouter quelques fonctionnalités avancées). 

 J'ai déjà mis en œuvre une solution d'authentification tierce pour CI ( Redux Authentication 2 Beta ) et j'intègre maintenant un gestionnaire de fichiers JS / PHP ( AjaxExplorer ), mais le problème est que le serveur PHP pour la gestion des fichiers (déplacement, copie, etc.) fait trop confiance à la saisie de l'utilisateur à partir des appels ajax. Par exemple, il s’agit de choses comme ceci (simplifiées pour plus de clarté): 

<*>

 Comme vous pouvez le constater, il existe des problèmes de sécurité évidents, car il accepte aveuglément le chemin emprunté par l'utilisateur! Je vois déjà quelqu'un envoyer quelque chose du type "../AutreUser /". comme valeur $ _POST ['destination_dir']. 

 Ma question est la suivante:  Quel est le meilleur moyen de " bac à sable " un utilisateur, afin de lui permettre uniquement de gérer ses propres données?  Dois-je simplement valider + filtrer les entrées, dans l’espoir d’attraper chaque tentative d’intrusion? Existe-t-il des bibliothèques / packages dédiés à cette problématique? 

 Je pense que ce problème doit être résolu d'une manière ou d'une autre dans tout projet (suffisamment mature), qui donne à ses utilisateurs le pouvoir de gérer leurs fichiers via un navigateur Web. Je m'attendais donc à trouver des directives claires à ce sujet (car il y en a beaucoup sur SQL Injection, XSS, CSRF, etc.), mais je suppose que je n’utilise pas les bons mots clés. 
FILES['upload']['tmp_name'], $root.$username.
 Bonjour à tous, je développe un site Web de partage de photos à l'aide du  framework PHP CodeIgniter . L'idée est que les gens puissent télécharger leurs photos, les gérer (via un navigateur de fichiers qui leur permet de créer des sous-dossiers, de faire glisser des fichiers, etc.) et de les éditer (des opérations de base telles que le redimensionnement, la rotation et le recadrage, etc.). plus tard, je vais ajouter quelques fonctionnalités avancées). 

 J'ai déjà mis en œuvre une solution d'authentification tierce pour CI ( Redux Authentication 2 Beta ) et j'intègre maintenant un gestionnaire de fichiers JS / PHP ( AjaxExplorer ), mais le problème est que le serveur PHP pour la gestion des fichiers (déplacement, copie, etc.) fait trop confiance à la saisie de l'utilisateur à partir des appels ajax. Par exemple, il s’agit de choses comme ceci (simplifiées pour plus de clarté): 

<*>

 Comme vous pouvez le constater, il existe des problèmes de sécurité évidents, car il accepte aveuglément le chemin emprunté par l'utilisateur! Je vois déjà quelqu'un envoyer quelque chose du type "../AutreUser /". comme valeur $ _POST ['destination_dir']. 

 Ma question est la suivante:  Quel est le meilleur moyen de " bac à sable " un utilisateur, afin de lui permettre uniquement de gérer ses propres données?  Dois-je simplement valider + filtrer les entrées, dans l’espoir d’attraper chaque tentative d’intrusion? Existe-t-il des bibliothèques / packages dédiés à cette problématique? 

 Je pense que ce problème doit être résolu d'une manière ou d'une autre dans tout projet (suffisamment mature), qui donne à ses utilisateurs le pouvoir de gérer leurs fichiers via un navigateur Web. Je m'attendais donc à trouver des directives claires à ce sujet (car il y en a beaucoup sur SQL Injection, XSS, CSRF, etc.), mais je suppose que je n’utilise pas les bons mots clés. 
POST['destination_dir']);

Comme vous pouvez le constater, il existe des problèmes de sécurité évidents, car il accepte aveuglément le chemin emprunté par l'utilisateur! Je vois déjà quelqu'un envoyer quelque chose du type "../AutreUser /". comme valeur $ _POST ['destination_dir'].

Ma question est la suivante: Quel est le meilleur moyen de " bac à sable " un utilisateur, afin de lui permettre uniquement de gérer ses propres données? Dois-je simplement valider + filtrer les entrées, dans l’espoir d’attraper chaque tentative d’intrusion? Existe-t-il des bibliothèques / packages dédiés à cette problématique?

Je pense que ce problème doit être résolu d'une manière ou d'une autre dans tout projet (suffisamment mature), qui donne à ses utilisateurs le pouvoir de gérer leurs fichiers via un navigateur Web. Je m'attendais donc à trouver des directives claires à ce sujet (car il y en a beaucoup sur SQL Injection, XSS, CSRF, etc.), mais je suppose que je n’utilise pas les bons mots clés.

Answer 1

  

Quel est le meilleur moyen de " bac à sable " un utilisateur, afin de lui permettre uniquement de gérer ses propres données?

Autorisez les noms de fichiers / répertoires souhaités par l'utilisateur, mais ne les utilisez pas simplement sur le système de fichiers côté serveur. Au lieu de cela, écrivez les noms de chemin dans une base de données avec une clé primaire et utilisez la clé primaire comme un nom de fichier comme "34256.dat" dans un répertoire de stockage plat (ou même comme un BLOB dans la base de données si vous préférez). Puis, utilisez un script de téléchargement ou une réécriture d'URL pour faire apparaître le nom de fichier souhaité dans l'URL.

La désinfection des noms de fichiers entrants est difficile . Détecter «..» n’est que le début. Noms de fichiers trop longs; noms de fichiers trop courts; combinaisons de points de début et de fin; combinaisons d'espaces blancs de début et de fin; les différents séparateurs de répertoires de différentes plates-formes; caractères non valides sur certaines plates-formes; caractères de contrôle; Caractères Unicode et les moyens de les traiter spécifiques à l'environnement; ADS; noms de fichiers (".htaccess") ou extensions (".php", ".cgi") qui pourraient être "spéciales" sur votre serveur Web; Noms de fichiers réservés de Windows ...

Vous pouvez passer votre vie à dénicher de drôles de bizarreries de règles de chemins de fichiers sur différentes plates-formes, ou vous pouvez simplement les oublier et utiliser la base de données.

Answer 2

Je ne suis pas sûr de ce à quoi ressemble votre rép_est de destination , mais ce à quoi je pensais, c'était d'affecter des clés de répertoires, puis d'obtenir le répertoire en fonction de cette clé. Par exemple:

//
 Je ne suis pas sûr de ce à quoi ressemble votre  rép_est de destination , mais ce à quoi je pensais, c'était d'affecter des clés de répertoires, puis d'obtenir le répertoire en fonction de cette clé. Par exemple: 

<*>

 Cependant, vous devez prédéfinir les clés avant la main. Une autre alternative pourrait être l’inverse: md5 / sha1 l’entrée et l’utiliser comme destination_dir, puis stocker cette clé dans la base de données avec l’étiquette associée. 
POST['destination_dir'] = '4hg43h5g453j45b3';
*_query('SELECT dir FROM destinations WHERE key = ? LIMIT 1'); //etc.

Cependant, vous devez prédéfinir les clés avant la main. Une autre alternative pourrait être l’inverse: md5 / sha1 l’entrée et l’utiliser comme destination_dir, puis stocker cette clé dans la base de données avec l’étiquette associée.

Answer 3

À ma connaissance, il n'y a pas de bibliothèque.
Toutefois, dans votre exemple particulier, supprimez toutes les barres obliques (arrière) et les points de la chaîne, puis ajoutez-y une barre oblique à la fin, afin que l'utilisateur ne puisse pas changer de dossier.

$destdir = str_replace(array('.', '/', '\\'), '', 
 À ma connaissance, il n'y a pas de bibliothèque. 

Toutefois, dans votre exemple particulier, supprimez toutes les barres obliques (arrière) et les points de la chaîne, puis ajoutez-y une barre oblique à la fin, afin que l'utilisateur ne puisse pas changer de dossier. 

<*>POST['destination_dir']); 
$destdir .= "/";