La sécurité 1 Introduction Lors de l'écriture d'une application de gestion, les problèmes liés à la sécurité deviennent vite prégnants. L'utilisateur doit disposer des droits nécessaires, ne pouvoir modifier que ce qui lui est autorisé. Il convient également de s'assurer que les données qui vont être stockées en base de données ne sont pas corrompues ou qu'un utilisateur mal intentionné ne peut modifier le comportement de l'application pour obtenir des informations auxquelles il n'aurait pas droit normalement. En développant des applications de type "clients lourds", bâties avec des outils comme Powerbuilder, Windev, Visual Basic..., il est assez facile de maîtriser la sécurité globale de l'application, celle-ci étant encapsulée dans un fichier.exe qui contient tout. Une fois l'application lancée, son fonctionnement reste complètement maîtrisé au sein de l'exécutable. En développant en mode web, l'approche est différente : l'application fonctionne en mode déconnecté, les pages peuvent être appelées de façon indépendante les unes des autres. Il est alors nécessaire de recourir à des mécanismes sophistiqués pour suivre le comportement de l'utilisateur, conserver son login, ses droits... tout au long de sa séquence de travail. De plus, la démocratisation d'internet fait qu'aujourd'hui, nul ne peut ignorer les tentatives de piratages, qu'elles soient externes si l'application fonctionne sur le réseau mondial, ou internes si l'application est confinée à réseau privé. Il ne faut d'ailleurs pas sous-estimer les risques provenant des personnels de la société : nous ne côtoyons nos collègues de travail que pendant les heures de bureau et nous ne connaissons rien de leur vie ou de leurs difficultés personnelles, de leurs engagements extérieurs ou des conflits qu'ils peuvent avoir avec leurs supérieurs. Les compétences informatiques, les outils pour exploiter les failles de sécurité sont à disposition de nombreuses personnes et ce n'est pas parce que le réseau est protégé des accès externes qu'il ne peut pas se faire attaquer de l'intérieur. La sécurisation d'une application va s'appuyer sur plusieurs briques : - l'identification : le login de l'utilisateur est vérifié ; - l'habilitation : l'utilisateur doit disposer des droits adéquats pour accéder à un module ou à un sous-ensemble de données définies, par exemple, le chiffre d'affaires de son service ; - la cohérence : les données introduites dans le système doivent être conformes à ce qui est attendu ; - et enfin, la sécurisation générale : la mise en œuvre de mécanismes adaptés rend les attaques plus difficiles à mener. Editions ENI - Toute reproduction interdite 119
PHP - De l'analyse au développement d'une application professionnelle 2 L'identification Le login, porte d'entrée de l'utilisateur dans l'application, est associé en général à un mot de passe. L'utilisateur va être confronté, à l'ouverture de l'application ou lors de l'accès à des informations protégées, à un écran lui demandant de saisir son login et un mot de passe associé. Il existe néanmoins des identifications basées sur des mécanismes plus complexes : par exemple, en utilisant des certificats numériques ou en demandant à l'utilisateur de saisir des codes complémentaires, lus dans une grille fournie au préalable à celui-ci. Aujourd'hui, trois grands modes d'identification sont utilisés : - La base de données contient une table Login, dont un des champs correspond au mot de passe utilisé. - L'identification des utilisateurs est réalisée à partir d'une base de données centrale et peut être réutilisée entre différentes applications. En entreprise, celle-ci s'appuie en général sur un annuaire, Active Directory de Microsoft ou la norme LDAP (Lightweight Directory Access Protocol). À noter que l'annuaire Active Directory est compatible LDAP (hormis la toute première version) : nous ne traiterons ici que le cas LDAP. - L'identification des utilisateurs est sous-traitée à une application dédiée à cet effet, un serveur CAS (Central Authentication Service - service d'authentification centralisé), qui traite de manière unique toutes les demandes de vérification de login. C'est en général la méthode la plus fiable et la plus sécurisée pour gérer l'identification dans les applications. 2.1 L'identification basée sur le login stocké en base de données Nous allons définir une table Login : Champ id login password Type Int varchar(32) varchar(256) Puis, la classe Login, basée sur ObjetBDD (cf. le chapitre L'accès aux données, pour l'utilisation de la classe ObjetBDD) : class Login extends ObjetBDD 120 Editions ENI - Toute reproduction interdite
La sécurité Le constructeur de la classe va être défini. La variable $bdd correspond à l'instance de la classe ADOConnection, gérant la relation avec la base de données. function Login($bdd) $this->table="login"; ObjetBDD::ObjetBDD($bdd); $this->id_auto = 1; $this->types=array( 'id'=>1); La fonction qui va permettre de vérifier le mot de passe saisi est créée : function veriflogin($login,$password) $password = hash("sha256",$password); $sql='select login from LoginGestion where login ="'. $login.'" and password = "'.$password.'"'; $res=objetbdd::lireparam($sql); if ($res["login"]==$login) return TRUE; else return FALSE; Dans l'application, pour vérifier le couple login/mot de passe, nous utiliserons le code suivant : $login = new Login($instance_adodb); $res=$login->veriflogin($_request['login'],$_request['password']); if ($res==true) $_SESSION["login"] = $_REQUEST["login"]; Nous avons ainsi récupéré le login de l'utilisateur et il a été stocké dans la variable de session login : nous pourrons l'utiliser ensuite dans l'application pour vérifier les droits associés. Editions ENI - Toute reproduction interdite 121
PHP - De l'analyse au développement d'une application professionnelle Le mot de passe ne doit jamais être stocké en variable de session : un simple print_r($_session) permettrait de l'afficher en clair dans un autre endroit de l'application. Cela poserait un problème juridique, le mot de passe est propriété unique de son titulaire et sous sa responsabilité. Un administrateur ou un développeur n'a pas à connaître les mots de passe des utilisateurs et encore moins le droit de les utiliser ou de les transmettre à un tiers. Il est important de faire attention au codage du mot de passe. Si, jusqu'à il y a deux ou trois ans, le codage md5 était considéré comme fiable, aujourd'hui, ce n'est plus le cas. Des mathématiciens ont prouvé que pour un même code, il pouvait exister deux valeurs différentes (mécanisme des collisions). Des pirates ont également établi des bases de données des empreintes, ce qui leur permet, s'ils récupèrent un fichier des mots de passe, de les décoder très rapidement. Comme les vols des fichiers de mot de passe sont malheureusement assez fréquents, il est conseillé d'utiliser d'autres algorithmes de codage, comme sha256 (considéré comme un des plus fiables actuellement), RIPEMD-160 ou Whirlpool. Il est également possible de combiner plusieurs codages les uns après les autres mais il ne faut pas perdre de vue que les temps de traitement augmenteront en conséquence. Les mots de passe ne doivent pas non plus être "réversibles", c'est-à-dire susceptibles d'être retransmis à l'utilisateur s'ils l'oublient. De nombreux sites fonctionnent sur ce principe : après saisie de l'adresse e-mail ou d'un mot clé (information personnelle...), le serveur renvoie le mot de passe. Avec ce mécanisme, des personnalités publiques se sont faites "casser" leur profil sur des sites collaboratifs, comme facebook. Il est préférable de mettre en place des systèmes de réinitialisation basés sur des mots de passe à usage unique. De même, le stockage des mots de passe ne doit jamais être réalisé en clair, ni avec des algorithmes symétriques, qui permettent de les décoder si la clé de cryptage est connue. Il est également conseillé de promouvoir l'utilisation de mots de passe non triviaux. Aujourd'hui, les mots de passe devraient comprendre au moins 8 caractères mélangeant minuscules, majuscules, chiffres et caractères spéciaux. Dans tous les cas de figure, un mot de passe doit être renouvelé tous les six mois et il est préférable de conserver un historique des mots de passe pour éviter une utilisation "en boucle". Pour les applications critiques, le mot de passe doit être changé tous les deux mois. 122 Editions ENI - Toute reproduction interdite
La sécurité 2.2 L'identification basée sur un annuaire LDAP L'identification ne va plus être gérée directement dans l'application mais s'appuyer sur un annuaire d'entreprise, disposant de ses propres règles de gestion (longueur de mot de passe, durée de validité...). Les avantages sont nombreux : l'application n'a plus à se soucier de protéger le fichier des mots de passe et l'utilisateur peut employer le même mot de passe pour plusieurs applications. Si l'annuaire LDAP est celui utilisé pour ouvrir une session de travail (sous Windows ou sous Linux), il n'a plus besoin de ne connaître qu'un seul login. Aujourd'hui, la plupart des applications web modernes proposent ce mode d'identification. La mise en place d'une identification basée sur l'annuaire LDAP est assez simple à réaliser. Elle vise à vérifier qu'il est possible de se connecter à l'annuaire en utilisant le couple login/mot de passe. Pour réaliser cette identification, nous allons créer une classe LoginLdap : class LoginLdap function construct($ldap_address, $LDAP_port,$LDAP_basedn, $LDAP_user_attrib,$LDAP_v3,$LDAP_tls) Les arguments du constructeur sont stockés en variables de classe. Nous retrouvons donc : - l'adresse du serveur : $this->ldap_address = $LDAP_address; - le port (par défaut, 389) : $this->ldap_port = $LDAP_port; - l'arborescence servant de base de recherche dans l'annuaire : $this->ldap_basedn = $LDAP_basedn; - l'attribut qui contient le login dans l'annuaire : $this->ldap_user_attrib = $LDAP_user_attrib; - la version de l'annuaire (aujourd'hui, les annuaires LDAP sont le plus souvent en version 3) : $this->ldap_v3 = $LDAP_v3; Editions ENI - Toute reproduction interdite 123
PHP - De l'analyse au développement d'une application professionnelle - et le mode crypté ou non de l'annuaire (TLS : Transport Layer Security - couche de transport sécurisée) : $this->ldap_tls = $LDAP_tls; Le test du couple login/mot de passe va être réalisé en vérifiant que la connexion à l'annuaire s'effectue correctement avec le login et le mot de passe fournis par l'utilisateur : function veriflogin($login,$password) La connexion à l'annuaire LDAP est réalisée : $ldap = @ldap_connect($this->ldap_address,$this->ldap_port) or die("impossible de se connecter au serveur LDAP."); À noter l'utilisation du caractère @ avant le nom de la fonction (ldap_connect) pour inhiber les messages d'erreur. La variable $ldap contient l'identifiant de la connexion à l'annuaire. La version de l'annuaire est indiquée : if ($this->ldap_v3) ldap_set_option($ldap, LDAP_OPT_PROTOCOL_VERSION, 3); Puis le mode de fonctionnement de l'annuaire crypté ou non : if ($this->ldap_tls) ldap_start_tls($ldap); La connexion à la base est préparée, puis elle est testée en fournissant le mot de passe : $dn = $this->ldap_user_attrib."=".$login.",".$this- >LDAP_basedn; $rep=ldap_bind($ldap,$dn, $password);; 124 Editions ENI - Toute reproduction interdite