Sécurité PHP - droits d'accès exposés

Autorisations d'accès exposées

L’un des principaux problèmes à prendre en compte lors de l’utilisation d’une base de données est l’exposition des droits d’accès, c’est-à-dire le nom d’utilisateur et le mot de passe. Pour plus de commodité dans la programmation, un fichier db.inc est généralement utilisé pour l'enregistrer, tel que :

CODE :

<?php
 
$db_user = &#39;myuser&#39;;
$db_pass = &#39;mypass&#39;;
$db_host = &#39;127.0.0.1&#39;;
 
$db = mysql_connect($db_host, $db_user,
$db_pass);
 
?>

Les noms d'utilisateur et les mots de passe sont des données sensibles et nécessitent une attention particulière. Le fait qu’ils soient écrits dans le code source crée des risques, mais c’est un problème inévitable. Si vous ne le faites pas, votre base de données ne sera pas protégée par un nom d'utilisateur et un mot de passe.

Si vous lisez la version par défaut de http.conf (le fichier de configuration d'Apache), vous constaterez que le type de fichier par défaut est text/plain (texte brut). De cette façon, si un fichier comme db.inc est enregistré dans le répertoire racine du site Web, cela entraînera des risques. Toutes les ressources situées dans le répertoire racine du site Web ont des URL correspondantes. Étant donné qu'Apache ne définit pas le type de méthode de traitement pour les fichiers avec le suffixe .inc, lors de l'accès à ce type de fichier, il sera renvoyé sous forme de texte ordinaire ( le type par défaut ), afin que les droits d'accès soient exposés au navigateur du client.

Pour illustrer davantage ce risque, considérons un serveur avec /www comme répertoire racine du site Web. Si db.inc est stocké dans /www/inc, il possède sa propre URL http://www.php.cn/ (en supposant un exemple). .org est le nom de domaine hôte). En accédant à cette URL, vous pouvez voir le fichier source de db.inc affiché en mode texte. Quel que soit le sous-répertoire de /www dans lequel vous enregistrez le fichier, vous ne pouvez pas éviter le risque d'exposition aux autorisations d'accès.

La meilleure solution à ce problème consiste à l’enregistrer dans un répertoire d’inclusion en dehors de la racine du site Web. Vous n'avez pas besoin de les placer dans un emplacement spécifique du système de fichiers pour les inclure, il vous suffit de vous assurer que le serveur Web y a accès en lecture. Par conséquent, il n’y a aucun risque inutile à les placer dans le répertoire racine du site Web, et tous les efforts visant à réduire le risque sont vains tant que les fichiers inclus se trouvent dans le répertoire racine du site Web. En fait, il vous suffit de placer les ressources auxquelles il faut accéder via des URL dans le répertoire racine du site Web. Après tout, il s'agit d'un annuaire public.

Les rubriques précédentes sont également utiles pour les bases de données SQLite. Enregistrer la base de données dans le répertoire courant est très pratique car il suffit d'appeler le nom du fichier sans spécifier de chemin. Cependant, stocker la base de données dans le répertoire racine du site Web représente un risque inutile. Si vous n'utilisez pas de mesures de sécurité pour empêcher l'accès direct, votre base de données est en danger.

S'il est impossible de placer tous les fichiers d'inclusion en dehors du répertoire racine du site Web en raison de facteurs externes, vous pouvez configurer Apache pour refuser les demandes de ressources .inc.

CODE :

<Files ~ "\.inc$">
  Order allow,deny
  Deny from all
</Files>

Note de traduction : Si j'écris ceci juste parce que je veux donner un exemple, c'est compréhensible. Après tout, tout le monde a appris certaines méthodes, mais cet exemple est un peu brutal. En fait, renommez simplement le fichier en db.inc.php. C'est comme ne pas réparer un trou dans une maison mais construire une maison plus grande à l'extérieur pour couvrir la maison détruite.

Au chapitre 8, vous verrez également une autre façon d'empêcher l'accès à la base de données d'être exposé, ce qui est très efficace dans un environnement de serveur partagé (où il existe toujours un risque d'exposition même si les fichiers sont situés en dehors de la racine du site Web).

Ce qui précède est le contenu de l'exposition des autorisations d'accès de sécurité PHP. Pour plus de contenu connexe, veuillez prêter attention au site Web PHP chinois (www. php.cn) !