Forums, scripts, cours, services pour webmaster, manuels (PHP, MySQL, HTML...) en français !
PHP / MySql
Recherche
 
ManuelPHP.com
Se connecter au serveur MySQL
<<<
Contrôle d'accès, étape 1 : Vérification de la connexion Contrôle d'accès, étape 2 : Vérification de la requête
>>>

4.2 Règles de sécurité et droits d'accès au serveur MySQL
4 Administration du serveur
 Manuel de Référence MySQL 4.1 : Version Française

Instructions générales de sécurité
Comment protéger MySQL contre les pirates
Options de démarrage qui concernent la sécurité
Problèmes de sécurité avec LOAD DATA LOCAL
Rôle du système de privilèges
Comment fonctionne le système de droits
Droits fournis par MySQL
Se connecter au serveur MySQL
->Contrôle d'accès, étape 1 : Vérification de la connexion
Contrôle d'accès, étape 2 : Vérification de la requête
Causes des erreurs Access denied

4.2.9 Contrôle d'accès, étape 1 : Vérification de la connexion

Lorsque vous tentez de vous connecter au serveur MySQL, le serveur accepte ou rejette la connexion en fonction de votre identité et du mot de passe que vous fournissez. Si le mot de passe ne correspond pas à celui qui est en base, le serveur vous interdit complètement l'accès. Sinon, le serveur accepte votre connexion et passe à l'étape 2, et la gestion de commandes.

Votre identité est basée sur trois informations :
  • L'hôte depuis lequel vous vous connectez
  • Votre nom d'utilisateur MySQL
  • Votre mot de passe
La vérification d'identité est réalisée avec les trois colonnes de la table user ( Host , User et Password ). Le serveur accepte la connexion uniquement si une entrée dans la table user correspond à votre hôte, et que vous fournissez le mot de passe qui correspond.Les valeurs de la table user peuvent être paramétrées comme ceci :
  • Une valeur de la colonne Host peut être un nom d'hôte, une adresse IP numérique, ou encore 'localhost' , qui représente l'hôte local.
  • Vous pouvez utiliser les caractères jokers '%' et '_' dans le champ Host .
  • Une valeur de '%' dans la colonne Host remplace n'importe quelle autre valeur.
  • Une valeur vide pour la colonne Host indique que les droits doivent être gérés avec les entrées de la table host qui correspond à l'hôte se connectant. Vous trouverez plus d'informations à ce sujet dans le prochain chapitre.
  • Depuis MySQL version 3.23, les valeurs de Host spécifiées sous la forme d'IP numériques peuvent être complétées avec le masque de réseau qui indique combien de bits d'adresse sont utilisés. Par exemple :
    
    mysql> GRANT ALL PRIVILEGES ON db.*
        -> TO david@'192.58.197.0/255.255.255.0';
    Cela permet à toute personne se connectant depuis une adresse IP qui satisfait la contrainte suivante :
    
    user_ip & netmask = host_ip.
    
    Dans l'exemple ci-dessus, toutes les IP dans l'intervalle 192.58.197.0 - 192.58.197.255 pourront se connecter au serveur MySQL.
  • Les caractères joker ne sont pas autorisés dans le champ User , mais vous pouvez spécifier une valeur vide qui remplacera tous les noms. Si l'entrée de la table user , qui correspond à une connexion entrante, a un nom d'utilisateur vide, l'utilisateur est alors considéré comme anonyme (c'est l'utilisateur sans nom) et non pas le nom d'utilisateur fourni. Cela signifie qu'un utilisateur fournissant un nom d'utilisateur vide sera utilisé pour identifier ses droits dans les prochaines étapes.
  • Le champ Password peut être vide. Cela ne signifie pas que n'importe quel mot de passe est valable, mais que l'utilisateur peut se connecter sans fournir de mot de passe.
Les valeurs non vides du champ Password représentent des valeurs du mot de passe chiffrées. MySQL ne stocke pas les mots de passe en clair, à la vue de tous. Au contraire, le mot de passe fourni pas l'utilisateur qui tente de se connecter est chiffré (avec la fonction PASSWORD() ). Le mot de passe ainsi chiffré est alors utilisé entre le client et le serveur pour vérifier s'il est valable. Cela évite que des mots de passe en clair circulent entre le client et le serveur, sur la connexion. Notez que du point de vue de MySQL, le mot de passe chiffré est le vrai mot de passe, ce qui fait que vous ne devez en aucun cas le donner à un tiers. En particulier, ne donnez pas accès en lecture aux utilisateurs normaux aux tables d'administration dans la base mysql ! A partir de sa version 4.1, MySQL utilise un mécanisme différent pour les logins, mots de passes qui est sécurisé même si les paquets TCP/IP sont sniffés et/ou que la base de données mysql est capturée.Les exemples ci-dessous illustrent comment différentes variantes de Host et User dans la table user s'appliquent aux connexion entrantes :
Host value User value Connexions autorisées
'thomas.loc.gov' 'fred' fred , se connectant depuis thomas.loc.gov
'thomas.loc.gov' '' N'importe quel utilisateur, se connectant depuis thomas.loc.gov
'%' 'fred' fred , se connectant depuis n'importe quel hôte
'%' '' N'importe quel utilisateur, se connectant depuis n'importe quel hôte
'%.loc.gov' 'fred' fred , se connectant depuis n'importe quel hôte dans le domaine loc.gov
'x.y.%' 'fred' fred , se connectant depuis x.y.net , x.y.com , x.y.edu , etc. (Ceci n'est probablement pas très utilisé)
'144.155.166.177' 'fred' fred , se connectant depuis l'hôte d'IP 144.155.166.177
'144.155.166.%' 'fred' fred , se connectant depuis un hôte d'IP dans la classe C 144.155.166
'144.155.166.0/255.255.255.0' 'fred' Identique à l'exemple précédent
Comme vous pouvez utiliser des caractères jokers dans les adresses IP de la colonne Host (par exemple, '144.155.166.%' pour identifier tout un sous-réseau), il est possible d'exploiter cette fonctionnalité en nommant un hôte 144.155.166.kekpart.com . Pour contrer de telles tentatives, MySQL interdit les caractères jokers avec les noms d'hôtes qui commencent par des chiffres ou des points. Par exemple, si vous avez un nom d'hôte tel que 1.2.foo.com , il ne sera jamais trouvé dans la colonne Host des tables de droits. Seule une adresse IP numérique peut être comparée avec un masque à caractère joker.

Une connexion entrante peut être identifiée par plusieurs entrées dans la table user . Par exemple, une connexion depuis thomas.loc.gov par fred sera identifiée de plusieurs façons différentes dans l'exemple ci-dessus. Comment le serveur va-t-il choisir si il y a plusieurs solutions ? Le serveur résoud cette question en triant les utilisateurs dans la colonne user après le démarrage, et il recherchera dans cette liste triée lorsqu'un utilisateur tente de se connecter. La première ligne qui satisfait les critères sera alors utilisée.

Le tri de la table user suit les règles suivantes. Supposons que votre table user ressemble à ceci :

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-
Lorsque le serveur lit cette table, il ordonne les lignes depuis les valeurs les plus spécialisées de la colonne Host jusqu'aux plus générales ( '%' dans la colonne Host signifie ``tous les hôtes'' et elle est la moins spécifique). Les entrées identiques dans la colonne Host sont ordonnées en fonction de la spécificité des valeurs de la colonne User (une entrée vide dans la colonne User signifie ``n'importe quel utilisateur'' et est spécifique). Le résultat de ce tri donne quelque chose comme ceci :

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-
Lorsqu'une connexion est en cours de mise en place, le serveur regarde dans cette liste, et utilisera la première entrée trouvée. Pour une connexion depuis l'hôte localhost avec le nom d'utilisateur jeffrey , les entrées 'localhost' dans la colonne Host sont trouvées en premier. Parmi celles-la, la ligne avec un utilisateur vide satisfait les deux contraintes sur le nom et l'hôte. '%'/'jeffrey' pourrait avoir fonctionné, mais comme ce n'est pas le premier rencontré, il n'est pas utilisé.

Voici un autre exemple. Supposons que la table user ressemble à ceci :


+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-
La table triée ressemble à ceci :

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-
Une connexion depuis l'hôte thomas.loc.gov avec jeffrey satisfait les conditions de la première ligne, tandis qu'une connexion depuis whitehouse.gov avec jeffrey satisfait la seconde ligne.Une erreur commune est de penser que pour un utilisateur donné, toutes les entrées qui utilisent explicitement ce nom seront utilisées en premier lorsque la connexion est en cours d'établissement. Ceci est tout simplement faux. L'exemple précédent illustre cette situation, car la connexion depuis l'hôte thomas.loc.gov avec jeffrey est la première ligne qui est trouvée, alors que la ligne contenant 'jeffrey' dans la colonne User est ignorée, car il n'y a pas de nom d'utilisateur.

Si vous avez des problèmes lors de la connexion, listez le contenu de la table user et triez-la à la main pour savoir quel est la première ligne qui est trouvée et utilisée.

Si la connexion s'est bien passée, mais que vos privilèges vous semblent faux, utilisez la fonction CURRENT_USER() (ajoutée en version 4.0.6) pour voir quel combinaison d'utilisateur/hôte votre connexion a utilisé. Fonctions diverses .

<< Contrôle d'accès, étape 1 : Vérification de la connexion >>
Se connecter au serveur MySQL Règles de sécurité et droits d'accès au serveur MySQL Contrôle d'accès, étape 2 : Vérification de la requête





Google

Services webmasters

Les manuels
 

ManuelPHP.com © 2003-2012 Tigersun - Crédits
Webmaster Site Internet - Télécharger des Logiciels - Programme TV - Entraide Informatique - Agence de Communication
2017-05-23