J'essayais de comprendre comment les sessions fonctionnent dans PHP et ont constaté que les données de session sont par défaut stockées dans le système de fichiers. Dans un environnement d'hébergement partagé, les données de session peuvent être lues par des scripts PHP écrites par n'importe quel utilisateur. Comment cela peut-il être empêché?
5 Réponses :
Vous pouvez remplacer le gestionnaire de sauvegarde de la session pour votre script pour utiliser autre chose que le système de fichiers, tel qu'une base de données ou un memcache. Voici une implémentation détaillée: http://phpsec.org/projects/guide/5.htmlLe_ a>
dépend du niveau d'accès que vous avez au fichier php.ini - si vous êtes sur un environnement d'hébergement partagé qui exécute SUPHP et vous permet d'avoir votre propre fichier php.ini (par exemple), vous pouvez simplement définir la session.Save_Path vers un chemin comme ~ / TMP au lieu de / TMP qui est généralement partagé.
Pour commencer, je ne pense pas que vous puissiez réellement lire des données de session PHP d'autres applications. Je crois que c'est quelque chose de plutôt unique à la personne la consultant.
Enfin, les données de session PHP ne sont pas uniquement enregistrées dans le système de fichiers. Il peut également être configuré pour enregistrer dans un cookie sur la machine de l'utilisateur ou vous pouvez configurer des données de session PHP à stocker dans une base de données.
Malheureusement, les données de session pour d'autres sessions sont faciles à lire à partir du système de fichiers: $ sessionFileDirectory = ini_get ("session.save_path"); echo '
Je suppose que je configurais mes systèmes par défaut plus sûrement parce que je ne peux pas imiter cela sur ma configuration. Les fichiers de TMP / appartiennent au compte que PHP fonctionne sous et sont enregistrés avec 0640 afin que SESES_XXX appartiennent à "Marco" "Marco" tandis que d'autres appartiennent à "utilisateur" par exemple par exemple. SUPHP aide vraiment à résoudre tous ces problèmes Pesky Personne.
Écrivez votre propre enveloppe de session.
Par exemple, Bibliothèque de session DOE ne dépend pas de la personne natale de PHP et c'est plus Sécurisé:
Remarque: la classe de session n'utilise pas de sessions PHP natifs. Il génère ses propres données de session, offrant plus de flexibilité pour les développeurs.
Vous pouvez utiliser session_save_path () pour changer le répertoire de données de session à un qui n'est pas partagé.
Corrigez-moi si je me trompe, mais ce que vous ne changez pas ce que vous modifiez le répertoire, il faut toujours être lu et écrit par l'utilisateur PHP fonctionne comme et donc encore techniquement lisible par d'autres utilisateurs de l'hébergement partagé?
L'hébergement partagé vous enferme généralement de ne lire que des annuaires et des fichiers situés dans votre compte.
C'est vrai. Mais si c'est vrai, il est également vrai que tout autre répertoire (votre Webroot, des répertoires avec des scripts dans, etc.) sera également lu et écritable par d'autres utilisateurs. Sauf si les autres utilisateurs ne sont tous capables d'exercer le contrôle de votre site (et de chacun »), nous devons conclure que tout fournisseur d'hébergement sensible a mis en place un moyen de limiter le contrôle qu'un utilisateur possède des répertoires appartenant à un autre utilisateur.
Et c'est pourquoi ils ont inventé Open_Basedir
Utiliser session_save_path () et modifier votre dossier de session comme "/ htdocs / stockage / sessions". Maintenant, des sessions enregistrées uniquement sur votre chemin donné.
Il est possible de spécifier différentes pistes de sauvegarde par hôte virtuel. Il n'est donc pas nécessairement vrai que chaque utilisateur a accès à ce répertoire.
@Gumbo True, avec une mise en garde - si PHP fonctionne avec l'UID du serveur Web, vous ne pouvez rien faire pour empêcher l'hôte virtuel A d'accéder aux données de session d'hôte virtuelle.
@Artefacto, je suis d'accord. Je crois que dans l'hébergement partagé, PHP fonctionne toujours comme le même utilisateur pour chaque compte d'hébergement. Ceci est la faille de sécurité intégrée qui ne remplace que le gestionnaire basé sur le fichier peut guérir. Droit?
@Mike Cela dépend, mais beaucoup fonctionnent sous le serveur Web UID. Remplacer le gestionnaire basé sur le fichier ne vous aidera pas beaucoup là-bas, vous pouvez toujours lire l'autre script utilisateur et aller chercher les données comme il le fait.
@ARTEFACTO, mais il ne peut lire que l'autre script utilisateur de la manière dont l'autre script utilisateur est destiné à fonctionner.
@Mike "destiné à travailler"? Que veux-tu dire? Il peut lire la source et il peut faire exactement la même chose dans ses scripts, car il a une autorisation de niveau de système de fichiers pour lire les fichiers (si la session est stockée dans une base de données, elle est encore plus simple; il n'a que de chercher le mot de passe). La seule chose qui pourrait éventuellement avoir dans la voie serait ouverte_basedir, mais cela peut être contourné.
@Artefacto, je vois. Il peut utiliser PHP pour lire le contenu de l'autre fichier PHP sans qu'elle soit dans le contexte d'un navigateur. Alors, peu importe ce qu'il fait, si un attaquant était capable de deviner l'emplacement de certains fichiers, il n'y a aucune protection, car il n'y a aucune distinction entre lui exécutant PHP et l'attaquant exécutant PHP. J'imagine alors que le seul moyen de sécuriser ceci est de vous assurer que votre société d'hébergement a PHP Exécuter en tant qu'utilisateur différent pour chaque compte d'hébergement?
@Mike c'est correct. Mieux encore, chaque client sur son propre VM. Certaines entreprises d'hébergement fournissent ceci pour 5 $ / mois.