Introduction à la Sécurité des Bases de Données

Introduction à la Sécurité des Bases de Données
Jean-Luc Hainaut Uniformiser le vocabulaire : processus, entité, composant... Ajouter rootkits et keyloggers Slide 41 : comment estimer raisonnablement les probabilités en analyse de risques ? Slide 44 : actualiser le coût des sinistres du CLUSIF

Plan de l’exposé Motivations et introduction Eléments de bases de données Intégrité des données Disponibilité des données Confidentialité des données et données privées Protection contre les intrusions (vol et fraude) Conclusions Références

Motivations et introduction
Eléments de bases de données Intégrité des données Disponibilité des données Confidentialité des données et données privées Protection contre les intrusions (vol et fraude) Conclusions Références

Quelques faits [Ben Natan, 2005] Conférences dédiées au hacking (BlackHat, Defcon, etc.) 2001 : 1 communication consacrée aux attaques de BD 2002 : 5 communications consacrées aux attaques de BD 2003 : un track entier (= sous-conférence) consacré aux attaques de BD En 2001, plus de 40% de compagnies bancaires et financières ont subi des attaques conduisant à des accès non autorisés et à une corruption de données. Jason Smathers, a former AOL employee accused of stealing 92 million customer addresses from the company to sell to a spammer.

Quelques faits [Ben Natan, 2005] Annonce trouvée sur muzzfuzz.com : "[A]m offering reverse lookup of information for a t-mobile cell phone, by phone number at the very least, you get name, ssn, and DOB at the upper end of the information returned, you get web username/password, voic password, secret question/answer, sim#, IMEA#, and more" Ces données provenaient de la BD de l'opérateur wifi T-Mobile (2004). SQL Slammer (janvier 2003). Ce ver a infecté en 10 minutes plus de serveurs SQL Server Technique : buffer overflow.

Sécurité d'une base de données ensemble des mécanismes et dispositions protégeant la base de données contre les effets des menaces accidentelles ou intentionnelles Base de données : au coeur du système d'information (SI). Toute attaque contre les données met en danger le SI lui-même, et par là, l'organisation toute entière. L'accès aux bases de données via le web augmente considérablement les menaces (de 100 utilisateurs internes identifiés à utilisateurs anonymes et incontrôlés)

Cinq dangers spécifiques perte d'intégrité des données non disponibilité des données perte de confidentialité des données perte de protection de données privées (privacy) vol et fraudes

La sécurité des bases de données est un domaine complexe, polymorphe, pour lequel il n'existe pas encore d'étude intégrée et homogène. Il n'existe pas encore de solution globale ni de recettes clé-sur-porte. Objectifs de la présentation : présentation des concepts de base identification et description de quelques menaces majeures description d'éléments de solution

Eléments de bases de données
Architecture d'un SI BD et SGBD Les acteurs Le marché des SGBD Le langage SQL (DDL, DML, statique, dynamique)

Architecture d'un SI Système d'information :  sous-système de l'organisation chargé de la collecte, de la mémorisation, de la gestion, de la distribution, du traitement et de la présentation des informations nécessaires à son fonctionnement (production + gestion);  transversal aux autres sous-systèmes de l'organisation : personnel, financier, physique, etc.  échange des informations avec son environnement;  utilise des ressources techniques (équipement informatique, logiciels) et humaines (programmeurs, concepteurs, analystes, chefs de projet, gestionnaires)

Architecture d'un SI Système d'information : les composants techniques  données : systèmes de gestion de bases de données  traitement : langages de programmation, progiciels  distribution : réseaux, protocoles, middlewares  interface avec les usagers : GUI, navigateurs

Architecture d'un SI BD données Application (business logic) schéma usagers c o m m u n i c a t i o n s serveur d'application de données station cliente Interface utilisateur SGBD

BDR et SGBDR : les données sont stockées dans des tables

BD et SGBD : les composants d'une table identifiant (primary key) schéma ligne données colonne obligatoire colonne facultative

BD et SGBD : un formulaire contenant des données

BD et SGBD : stockage des données du formulaire clé étrangère (foreign key)

Les composants d'une base de données Une base de données = un schéma + des données Le schéma est constitué :  de la description des tables et des colonnes  des identifiants, clés étrangères  de la description des vues  des prédicats check  des procédures SQL  des triggers  de la description des utilisateurs, des rôles et des privilèges Les données comprennent  le contenu des tables  les méta-données, qui se présentent sous forme de tables

Les composants d'une base de données Les méta-données (ou Tables systèmes ou Catalogue) de 20 à 50 tables, dont celles qui décrivent les utilisateurs et leurs privilèges.

Les acteurs  Utilisateurs internes, utilisateurs externes  Analyste/concepteur/développeur de la base de données  Administrateur des données (organisationnel)  Administrateur de la BD (technique)  Responsable de l'exploitation  Vendeur (commercial, consultant, technicien)  Utilisateur (naïf, avancé)  Développement d'applications (chef de projet, analyste, programmeur)  Responsable de la sécurité  Attaquant

Le marché des SGBD  Oracle : Oracle  IBM : DB2, Informix  Microsoft : SQL Server (issu de Sybase), Access  Sybase : Sybase ASE, SQL Anywhere  Sun : MySQL, Postgres (Open source)  + une cinquantaine de moteurs SQL Autres  IMS d'IBM (1969, toujours utilisé)  CODASYL (IDS de Bull, UDS de Siemens, IDMS de CA, etc., 1973, toujours utilisés)  SGBD orientés objet (fin 90, faible pénétration, absorbés par SGBDR)  SGBD XML (début 2000, faible pénétration, absorbés par SGBDR)

Le langage SQL - Principes SQL est le langage permettant à une application cliente de demander à un SGBD d'exécuter des actions sur une base de données. L'application envoie une instruction SQL au SGBD, lequel répond en envoyant un diagnostic et, le cas échéant, les données demandées. SQL comporte plusieurs parties (sous-langages)  description de structures de données (DDL)  manipulation de données (DML)  contrôle des données (contrôle d'accès, etc.) Standardisation : actuellement SQL2 (1992) et SQL3 (1999) Cependant, chaque SGBD propose des variantes qui freinent la portabilité des applications (exceptions : ODBC, JDBC, SQLJ)

Le langage SQL - SQL/DDL (Data Definition Language) Ensemble des instructions permettant de créer, supprimer et modifier les structures de données on demande de créer une table nommée CLIENT create table CLIENT ( NCLI char(4) not null, NOM char(32) not null, ADRESSE varchar(100) not null, LOCALITE char(30) not null, CAT char(2), COMPTE decimal(8,2) not null, primary key (NCLI) ); create table COMMANDE ( NCOM integer not null, DATECOM date not null, primary key (NCOM), foreign key (NCLI) references CLIENT); les valeurs de la colonne NCLI comportent 4 caractères la colonne NOM est obligatoire la colonne CAT est facultative la colonne NCLI est un identifiant de la table CLIENT la colonne NCLI est une clé étrangère vers la table CLIENT

Le langage SQL - SQL/DDL (Data Definition Language) on demande de supprimer la table FACTURE et son contenu. drop table FACTURE ; alter table COMMANDE add column MONTANT decimal (6,2) not null; on demande d'ajouter une colonne MONTANT à la table COMMANDE. create view CLIENT_TOULOUSE (NUM, NOM, ADRESSE, CATEGORIE) as select NCLI, NOM, ADRESSE, CAT from CLIENT where LOCALITE = 'Toulouse'; on demande de créer une vue, c-à-d une table virtuelle adaptée aux besoins d'une catégorie d'utilisateurs. create table PRODUIT (NPRO .., LIBELLE .., PRIX .., QSTOCK .., primary key (NPRO), check (PRIX > 0) ) prédicat check définissant une contrainte sur les valeurs de la colonne PRIX.

Le langage SQL - SQL/DDL (Data Definition Language) create procedure MODIFIER_CLIENT (in N char(4), LOC char(30)) begin <actions sur la base de données> end; on demande de créer une procédure et de l'enregistrer dans la base de données. create trigger MAJ_CLI after insert on CLIENT for each row begin insert into JOURNAL(OPER,NCLI, INSTANT) values ('insert', new.NCLI, Current_Time); end on demande de créer un trigger, c-à-d une procédure qui se déclenche automatiquement. Ici, après chaque insertion d'une ligne de CLIENT, on ajoute à la table JOURNAL une trace de l'opération.

Le langage SQL - SQL/DML (Data Manipulation Language) Ensemble des instructions permettant de manipuler les données, c'est-à-dire de les extraire et de les modifier Comporte quatre instructions  select : extraire des données des tables  insert : insérer une ou plusieurs lignes dans une table  update : modifier des valeurs de colonnes de lignes existantes  delete : supprimer des lignes existantes

Le langage SQL - SQL/DML (extraction de données) on extrait les valeurs de NCLI, NOM, et ADRESSE ... select NCLI, NOM, ADRESSE from CLIENT where LOCALITE = 'Toulouse' order by NCLI; des lignes de la table CLIENT ... pour lesquelles LOCALITE a la valeur 'Toulouse' ... le résultat doit être ordonné par valeurs croissantes de NCLI select NCLI, NOM, ADRESSE from CLIENT where LOCALITE = 'Toulouse' and CAT = 'B1'; une condition plus complexe select NCLI, NOM from CLIENT where LOCALITE = 'Toulouse' and CAT = 'B1' or COMPTE > 0; priorité de 'and' sur 'or'. Une ligne est sélectionnée : - soit si (LOCALITE = 'Toulouse') et (CAT = 'B1') - soit si (COMPTE > O) - soit si toutes les conditions sont réunies

Le langage SQL - SQL/DML (extraction de données) select NCLI, NOM, ADRESSE from CLIENT where 'A' = 'A'; une condition curieuse mais valide; elle est toujours vraie; toutes les lignes seront sélectionnées select NCLI, NOM, ADRESSE from CLIENT where NCLI = 'C400' or 'A' = 'A'; cette condition sera toujours vraie, même s'il n'existe pas de client dont NCLI = 'C400'; toutes les lignes seront sélectionnées Ces conditions triviales, en apparence sans intérêt, intéresseront prodigieusement les attaquants. Elles nous causeront quelques soucis dans l'avenir !

Le langage SQL - SQL/DML (extraction de données) on extrait deux fonctions statistiques : le nombre de lignes et la somme des valeurs de COMPTE ... select count(*), sum(COMPTE) from CLIENT where LOCALITE = 'Toulouse'; des lignes de la table CLIENT ... dont LOCALITE a la valeur 'Toulouse' ... on extrait des données ... select NCOM, DATECOM, CLIENT.NCLI, NOM from COMMANDE, CLIENT where COMMANDE.NCLI = CLIENT.NCLI; ... de deux tables dont les lignes sont appariées par une jointure définie par ... ... une condition de jointure select NOM, LOCALITE from CLIENT union all select NOM, LOCALITE from PROSPECT; le résultat global de cette requête composée est l'union des résultats des deux requêtes élémentaires ('all' = on garde les doublons)

Le langage SQL - SQL/DML (modification de données) on demande l'insertion d'une ligne dans la table COMMANDE insert into COMMANDE(NCOM, NCLI, DATECOM) values (30187, 'C400', 2008/3/14); liste des valeurs de la ligne on demande de modifier, dans la table CLIENT, les lignes ... update CLIENT set CAT = 'B2 where COMPTE > 0; ... dont COMPTE > 0 ... ... en changeant leur valeur de CAT. on demande de supprimer de la table COMMANDE les lignes ... delete from COMMANDE where NCLI = 'C400'; ... dont NCLI = 'C400'

Le langage SQL (commentaire) Un commentaire est une instruction SQL spéciale constituée d'un texte libre explicatif qui est ignoré par le SGBD. En principe, un commentaire est préfixé par le symbole "--" et occupe la fin de la ligne. Un commentaire peut terminer une instruction SQL normale. Dans certains SGBD, un commentaire est entouré de symboles spéciaux (MySQL) -- Instructions de chargement des données insert into DETAIL ... update CLIENT set CAT = 'B2 where CAT is null; -- ajouté le 8/3/2008 delete from COMMANDE /* intégrité référentielle ! */ where NCLI = 'C400'; Attention : instruction faussement inoffensive !

Le langage SQL - SQL statique ou dynamique Les instructions SQL sont insérées dans les programmes d'application. Lors de l'exécution du programme, chaque instruction est transmise au SGBD pour exécution. En retour, si l'instruction est correcte et exécutable, le SGBD envoie les données demandées ainsi qu'un diagnostic sur les conditions de l'exécution. Il existe deux mode de construction des instructions SQL : au moment de la rédaction du programme (SQL statique) au moment de l'exécution du programme (SQL dynamique) SQL dynamique va nous causer quelques solides problèmes !

Le langage SQL - anatomie d'une instruction select NCLI, NOM from CLIENT where LOCALITE = 'Toulouse' and CAT = 'B1' données résultats update PRODUIT set PRIX = 110 where NPRO = 'PA45' données résultats (OK / KO)

Le langage SQL - anatomie d'une instruction select NCLI, NOM into :R1, :R2 from CLIENT where LOCALITE = :D1 and CAT = :D2 données résultats D1 = 'Toulouse'; D2 = 'B1'; select NCLI, NOM into :R1, :R2 from CLIENT where LOCALITE = :D1 and CAT = :D2; display R1, R2; acquisition des données instruction SQL exploitation des résultats

Le langage SQL - SQL statique D1 = 'C400'; select NOM, LOCALITE into :R1, :R2 from CLIENT where NCLI = :D1; display R1, R2; L'instruction est écrite dans le programme tout comme les autres instructions. Elle est construite au moment de l'écriture du programme. Les seules parties qui restent à remplir à l'exécution sont les données utilisées dans la condition where (via la variable D1). Les possibilités de trafiquer une instruction SQL statique sont très limitées. SQL statique est disponible en COBOL, C, C++ et Java (SQLJ)

Le langage SQL - SQL dynamique (version clean) D1 = 'C400'; Requete = "select NOM, LOCALITE from CLIENT where NCLI = ?"; prepare Q from Requete; execute Q using :D1 into :R1, :R2; display R1, R2; L'instruction est construite au moment de l'exécution du programme. Les seules parties variables sont les données et les résultats. Les possibilités de trafiquer une instruction SQL dynamique clean sont limitées. SQL dynamique clean est disponible en COBOL, C, C++ (ODBC) et Java (JDBC)

Le langage SQL - SQL dynamique (version trash) D1 = 'C400'; Requete = "select NOM, LOCALITE from CLIENT"; Requete = Requete + " where NCLI = " + D1 + "' "; execute imediate from :Requete into :R1, :R2; display R1, R2; L'instruction est construite au moment de l'exécution du programme. Toutes les parties de l'instruction sont susceptibles d'être variables. Les possibilités de trafiquer une instruction SQL dynamique trash sont très nombreuses (voir plus loin). SQL dynamique trash est disponible en COBOL, VB, C, C++ (ODBC) et Java (JDBC)

Intégrité des données Intégrité d'une base de données Contraintes d'intégrité Exactitude, correction et validité d'une base de données Intégrité physique et intégrité logique Menaces et contre-mesures

Intégrité d'une base de données
Intégrité des données Intégrité d'une base de données Intégrité (théorique) : Etat d'une base de données qui constitue une image fidèle du domaine d'application. Remarque : impossible à vérifier. Intégrité (pratique) : Etat d'une base de données qui respecte un ensemble de contraintes d'intégrité. Remarque : techniquement vérifiable; simulation imparfaite de l'intégrité théorique. Contrainte d'intégrité : Propriété formelle que les données et leur évolution doivent respecter à défaut de quoi elles sont réputées corrompues. Contrainte d'intégrité statique : Propriété formelle que les données doivent respecter à tout instant (ou à des instants prédéfinis), à défaut de quoi elles sont réputées corrompues. Définit les états valides. Contrainte d'intégrité dynamique : Ensemble des transitions d'état d'un objet considérées comme valides. Toute transition non valide partant d'un état valide conduit à un état corrompu des données, même si cet état respecte toutes les contraintes d'intégrité statiques.

Contraintes d'intégrité - Exemples
Intégrité des données Contraintes d'intégrité - Exemples Contrainte d'intégrité statique Exemples :  colonne obligatoire (non null)  contrainte d'unicité (identifiant)  contrainte référentielle (clé étrangère)  contraintes de valeurs (QCOM > 0) Contrainte d'intégrité dynamique  la valeur de PRIX ne peut augmenter de plus de 5%  la valeur de SALAIRE ne peut diminuer  changement d'état civil : seules certaines transitions sont valides

Exactitude, correction et validité d'une base de données
Intégrité des données Exactitude, correction et validité d'une base de données Etat exact : la base de données contient toutes les données conformes à l'état courant du domaine d'application. Correspond à l'intégrité théorique. Respecte toutes les contraintes d'intégrité. Dernier état correct : la base de données contient toutes les données introduites et elles seulement. Respecte toutes les contraintes d'intégrité. Etat correct : l'un des états corrects, mais pas nécessairement le dernier. Respecte toutes les contraintes d'intégrité. Etat correct possible : ensemble de parties correctes. N'a pas nécessairement existé dans le passé (parties asynchrones). Pertes possibles. Respecte toutes les contraintes d'intégrité. Etat valide statiquement : respecte les contraintes d'intégrité statiques. Etat valide dynamiquement : obtenu à partir d'une chaîne de changements d'état vérifiant les contraintes d'intégrité statiques et dynamiques.

Intégrité physique et intégrité logique
Intégrité des données Intégrité physique et intégrité logique Intégrité physique : les données sont accessibles au SGBD. Les structures physiques sont respectées (format des enregistrements, mécanismes d'accès, index, catalogues, etc.). Il est possible d'accéder aux données mais celles-ci ne sont pas nécessairement correctes ni valides. La perte d'intégrité physique oblige à recourir à des outils de bas niveau pour sauver ce qui peut l'être. Intégrité logique : intégrité physique + respect des contraintes d'intégrité.

Menaces et contre-mesures
Intégrité des données Menaces et contre-mesures Introduction de données valides mais inexactes Les données introduites respectent les contraintes d'intégrité statiques et dynamiques mais ne correspondent pas à l'état ou au comportement du domaine d'application. Exemple : erreur de montant déposé sur un compte (4500 au lieu de 5400). Contre-mesures : formation du personnel de saisie, conditions de travail favorables, double encodage, validation des données pour éviter les erreurs grossières, éviter l'encodage (transfert électronique si possible) Introduction de données invalides Les données introduites ne respectent pas les contraintes d'intégrité statiques et dynamiques. Exemple : introduction d'une quantité commandée négative. Contre-mesures : définir des contraintes dans le schéma et non dans les logiciels d'application, utiliser les mécanismes ad hoc : check, triggers, procédures SQL

Intégrité des données Menaces et contre-mesures Fausse manœuvre de l'utilisateur Le comportement de l'utilisateur conduit à la corruption de certaines données. Exemples : oubli de lancer une procédure de validation des données, exécution d'une fonction ou d'un programme inadéquats, interruption prématurée d'une séquence de saisie, abandon d'un poste de saisie (syndrome de la pause café), etc. Contre-mesures : formation des utilisateurs, ces incidents doivent être prévus et gérés dans les logiciels d'application. Existence de procédures exceptionnelles (corrections manuelles par exemple)

Intégrité des données Menaces et contre-mesures Erreur technique dans le logiciel applicatif Une situation imprévue provoque un incident d'exécution du programme d'application. Exemple : division par zéro, dépassement de longueur de champ, etc. Contre-mesures : ces erreurs doivent être prévues et gérées dans les logiciels, améliorer la formation des programmeurs. Erreur logique dans le logiciel applicatif La logique de l'application traduit mal les spécifications initiales. Le comportement du programme est erroné, bien que techniquement correct (pas d'incident). Contre-mesures : améliorer les méthodes d'analyse et de développement, formation des analystes.

Intégrité des données Menaces et contre-mesures Erreur dans un logiciel système Comportement erroné, inadéquat ou arrêt prématuré d'un composant système : SGBD, système d'exploitation, gestionnaire d'écran, gestionnaire de communication, etc. Contre-mesures : ces incidents doivent être prévus dans les procédures d'exploitation et les programmes; application des correctifs fournis par les éditeurs de logiciels; application des procédures de reprise standard (OS, SGBD) et spécifiques (check points, transactions).

Intégrité des données Menaces et contre-mesures Attaques ciblées, fraudes, malveillance Des individus, utilisateurs réguliers ou occasionnels, tentent de modifier frauduleusement ou de détruire les données. Contre-mesures : cryptage des données, copies de sécurité, traçabilité des opérations, détection des comportements déviants, voir "Protection contre les intrusions" Attaques anonymes, virus Des individus, via des logiciels d'attaque, recherchent des sites présentant des failles de protection, et s'y installent en cherchant à détruire ou corrompre les fichiers accessibles. Contre-mesures : firewall, anti-virus, application des correctifs fournis par les éditeurs de logiciels, détection des comportements déviants.

Intégrité des données Menaces et contre-mesures Interactions parasites entre processus concurrents Un processus de traitement est perturbé par un autre processus concurrent. Il s'agit d'un problème logique. Exemple : deux processus A et B lisent la même donnée, la modifient, puis la réécrivent dans la base de données. Seule la dernière modification sera prise en compte (problème de la mise à jour perdue). Contre-mesures : problèmes bien connus et maîtrisés; programmation par transaction garantissant leur indépendance (ACID), paramétrage approprié de la régulation de la concurrence (locking, time-stamping)

Intégrité des données Menaces et contre-mesures Incident matériel Panne ou comportement inadéquat d'un composant matériel : mémoire RAM, bus, processeur, carte contrôleur, terminal, modem, ligne, serveur distant, etc. Contre-mesures : maintenance préventive, redondance matérielle, ces incidents doivent être prévus dans les procédures d'exploitation et les programmes; application des procédures de reprise (check points, transactions). Perte du support Le support de la base de données (en général disque magnétique) subit un incident qui le rend irrécupérable. Les données qu'il contenait sont perdues. Contre-mesures : maintenance préventive, surveillance hardware (SMART), redondance matérielle (mirroring, RAID), procédure de restauration détaillée et bien maîtrisée (simulations régulières).

Intégrité des données Menaces et contre-mesures Destruction des installations Catastrophes naturelles (tremblements de terre, inondations, foudre) ou d'origine humaine (incendies, chutes d'avion, attentats). Contre-mesures : procédures de continuité de service, redondance des installations, copies de sauvegarde et journaux sur des sites distants, sites miroirs distants, procédure de restauration détaillée et bien maîtrisée (simulations régulières).

Disponibilité des données
Disponibilité et continuité de service Menaces Contre-mesures Notion de transaction Reprise à chaud Reprise à froid

Disponibilité et continuité de service La base de données doit être accessible 24/24 - 7/7 Fonctionnement de l'équipement Fonctionnement des logiciels (SGBD, applications) Intégrité des données Performances en cas de surcharge Dispositions en cas d'indisponibilité

Menaces (1) Incident affectant un programme d'application (transaction) Erreur dans une transaction, celle-ci est arrêtée. Données locales potentiellement corrompues. Pas d'interruption de service. Incident affectant tous les programme d'application (transactions) Toutes les transactions sont arrêtées. Données locales potentiellement corrompues. Interruption de service possible. Incident affectant l'intégrité des données Corruption (potentielle) accidentelle ou intentionnelle des données. Données corrompues pas nécessairement identifiées. Interruption de service possible.

Menaces (2) Incident détruisant le support Crash du disque. Données irrécupérables. Interruption de service possible. Incident logiciel affectant le serveur Panne logicielle. Reprise progressive. Interruption de service. Incident matériel affectant le serveur Panne matérielle grave. Interruption de service. Déconnexion du serveur Interruption de la connexion serveur / clients. Problème de la reprise ultérieure de la connexion : resynchronisation des données et des transactions.

Contre-mesures Gestion de transactions (reprise à chaud) Indépendance des transactions. Arrêt d'une transaction. Restauration des données locales. Gestion de transactions (reprise à froid) Arrêt puis reprise du serveur. Restauration des données locales. Redondance de données Sauvegarde des données, journaux, données répliquées (BD miroir). Redondance matérielle Duplication : des disques (RAID), des serveurs.

Notion de transaction (1) Définition Suite d'instructions représentant une unité logique de traitement. Une transaction comprend généralement plusieurs instructions de lecture et de modification de données. Exemples : enregistrement d'une commande réapprovisionnement d'un article en stock transfert d'un montant d'un compte vers un autre Les programmes travaillant sur une base de données sont généralement organisés en transactions

Notion de transaction (2) A.C.I.D Le déroulement d'une transaction doit garantir quatre propriétés : Atomicité, Cohérence, Indépendance et Durabilité. Atomicité Une transaction est exécutée complètement ou pas du tout. Cohérence Si les données sont intègres (respectent les contraintes d'intégrité) avant l'exécution de la transaction, elle le sont encore après son exécution. Indépendance La transaction est rédigée et exécutée indépendamment des autres transactions qui s'exécutent simultanément. Durabilité Si une transaction se termine normalement, les modifications qu'elle a effectuées sont permanentes.

Notion de transaction (3) Toutes les instructions SQL (DDL et DML) respectent les propriétés ACID. C'est le rôle du SGBD de les garantir également pour toutes les transactions bien formées.

Notion de transaction (4) Exemple : transfert entre comptes (version "pédagogique") getForm(CPT1, CPT2, M); begin-transaction select MONTANT into :M1 from COMPTE where NCPT = :CPT1; M1 = M1 - M; update COMPTE set MONTANT = :M1 where NCPT = :CPT1; select MONTANT into :M2 from COMPTE where NCPT = :CPT2; M2 = M2 + M; update COMPTE set MONTANT = :M2 where NCPT = :CPT2; commit-transaction <suite du programme> lire et modifier le compte source lire et modifier le compte destinataire

Notion de journal Le SGBD maintient un journal des modifications effectuées sur les données. journal = enregistrement chronologique d'événements + informations complémentaires sur ceux-ci; il contient en particulier : les instants de début et de fin de chaque transaction before images : copie des données avant une modification after images : copie des données après une modification Le journal peut être très volumineux (plusieurs dizaines de GB/jour) Le journal doit être protégé au même titre que les données de base

Reprise à chaud un incident local provoque l'arrêt prématuré de l'exécution d'une transaction; les données locales sont laissées dans un état incohérent (exemple : le montant à transférer a été retiré mais pas encore redéposé); le SGBD lit le journal en sens inverse depuis le point courant jusqu'au début de la transaction arrêtée; le SGBD remplace chaque donnée modifiée par son image before; les données locales sont ainsi réétablies dans l'état précédent l'exécution de la transaction. Il existe une possibilité de reprise à chaud lorsque toutes les transactions ont été arrêtées.

Reprise à froid (reconstruction) un incident global a affecté l'intégrité des données : corruption importante, non identifiable, destruction du support ; le contenu actuel de la base de données est irrécupérable; il existe une copie de sauvegarde (backup) de la base de données à l'instant t0; le journal contient les images after depuis l'instant t0 ; on restaure la base de données dans son état t0 puis on y introduit toutes les images after de toutes les transactions clôturées; la base de données se trouve alors dans un état correct (en principe le dernier). S'il existe une BD miroir (réplication intégrale), on peut éviter l'interruption de service de la reconstruction. Architecture RAID.

Confidentialité des données et données privées
Menaces Modèles de contrôle d'accès Contrôle d'accès en SQL Inférence statistique Suppression sécurisée des données

Menaces Un utilisateur accède à des données qui ne lui sont pas autorisées L'utilisateur est légitime ou illégitime (intrus) Cet accès a pour but de lire ces données, de les insérer, de les modifier ou de les détruire Un utilisateur obtient des informations privées sur des personnes, notamment par déduction à partir de données obtenues légalement

Menaces On distingue deux aspects Confidentialité : accès non autorisé à des données Données privées : accès à des informations relatives à la vie privées de personnes

Modèles de contrôle d'accès (1) Principes ce qui n'est pas autorisé est interdit l'utilisateur doit être enregistré l'utilisateur qui se connecte à une base de données doit avoir été identifié et authentifié (généralement via le logiciel d'application) Deux familles de modèles de contrôle d'accès [Bertino, 1998] discrétionnaires mandataires

Modèles de contrôle d'accès (2) Modèles discrétionnaires (discretionary, System/R) l'utilisateur est propriétaire des objets qu'il a créés l'utilisateur peut transmettre à sa discrétion des autorisations sur ses objets à d'autres utilisateurs l'utilisateur peut transmettre à d'autres utilisateurs le droit de transmettre ces autorisations (délégation) modèle généralement adopté par les SGBD

Modèles de contrôle d'accès (3) Modèles discrétionnaires (extensions) autorisation négative : l'utilisateur U ne peut obtenir telle autorisation (même si elle lui est accordée ultérieurement) autorisation à base de rôles : un rôle reçoit des autorisations; un utilisateur se voit attribuer un rôle, dont il hérite des autorisations autorisation à validité spatio-temporelle : l'autorisation est accordée dans certaines périodes à partir de certains points de connexion

Modèles de contrôle d'accès (4) Modèles mandataires (mandatory) l'utilisateur (sujet) est caractérisé par un niveau de sécurité Ls l'objet est caractérisé par un niveau de sécurité Lo exemple classique de niveaux : 4: top secret 3: secret 2: confidentiel 1: public

Modèles de contrôle d'accès (5) Protocole de Bell & LaPadula no read-up : le sujet peut lire (consulter) un objet si Ls  Lo no write-down : le sujet peut écrire (modifier) un objet si Ls  Lo Lo2 Ls F2 R Lo1 F1 W x

Modèles de contrôle d'accès (6) Limite des modèles discrétionnaires U1 peut lire dans F1; U2 ne peut pas lire dans F1 U2 crée F2, dans lequel il peut lire et écrire U2 donne à U1 le droit d'écrire dans U2 U2 crée un programme quelconque P (p. ex. tri) dans lequel il introduit une fonction cachée (un cheval de Troie cT) qui lit le contenu du fichier traité par P et le copie dans F2 si U1 utilise P sur F1, le contenu de F1 est copié dans F2 auquel U2 a accès.

Modèles de contrôle d'accès (7) F1 F2 U1 U2 R R/W R

Modèles de contrôle d'accès (8) F1 F2 U1 U2 R R/W W P cT F1 U1 ! F1 U2 F2

Modèles de contrôle d'accès (9) Solution dans des modèles mandataires si U2 ne peut lire dans F1, c'est que Lu2 < Lf1 U2 crée F2, donc Lf2 = Lu2 si U1 peut lire F1, c'est que Lu1  Lf1 donc, Lu1 > Lf2 U1 ne peut donc pas écrire dans F2 (no write-down) Lu1  Lf1 > Lu2 = Lf2

Modèles de contrôle d'accès (10) Lf2 Lu2 Lf1 Lu1 P cT F1 F2 U1 U2 x no write-down

Contrôle d'accès en SQL (1) Ensemble des instructions permettant d'accorder et retirer des privilèges Modèle discrétionnaire : le propriétaire ou un administrateur d'un objet peut accorder des privilèges sur cet objet à tout autre utilisateur enregistré. Privilège : droit accordé par un utilisateur U1 à U2 d'effectuer l'opération O sur (les instances de) l'objet D <U1, U2, O, D>. Tout privilège peut s'accompagner du droit de transmettre ce privilège. U2 devient alors administrateur de l'objet. Variante : un rôle reçoit un ensemble de privilèges; un rôle est accordé à un utilisateur ou à un autre rôle, qui héritent ainsi des privilèges du premier rôle (version simplifiée dans Oracle).

Contrôle d'accès en SQL (2) Remarque : lors de la connexion à une base de données, l'utilisateur (humain, application cliente) doit s'identifier et s'authentifier. En cas de réussite, il a accès à tous les objets dont il est propriétaire ou administrateur.

Contrôle d'accès en SQL (3) le propriétaire/administrateur (U1) de la table CLIENT accorde le droit d'effectuer cette opération (O) ... grant select(NCLI, NOM, LOCALITE) on CLIENT to MERCIER; ... sur la table CLIENT (D) ... à l'utilisateur MERCIER (U2) grant update (QSTOCK, PRIX) on PRODUIT to GEST05 with grand option; GEST05 reçoit en outre de droit d'accorder ce privilège à d'autres utilisateurs. Il devient administrateur (délégué) de PRODUIT. grant select on PRODUIT to public; Ce privilège est accordé à tous les utilisateurs, présents et futurs.

Contrôle d'accès en SQL (4) grant run on MODIFIER_CLIENT to MERCIER; On accorde le droit d'exécuter la procédure MODIFIER_CLIENT revoke update (QSTOCK) on PRODUIT to GEST05; Désormais, GEST05 ne peut plus modifier les valeurs de QSTOCK dans la table PRODUIT. Que se passe-t-il si GEST05 avait transmis ce privilège à MERCIER ? Quelques politiques possibles :  le privilège ne pourra être retiré que lorsque GEST05 l'aura retiré à MERCIER  le privilège est retiré à GEST05, puis à MERCIER  le privilège est retiré à GEST05, puis à MERCIER si ce dernier ne l'avait reçu que de GEST05  le privilège est retiré à GEST05 mais pas à MERCIER

Contrôle d'accès en SQL (5) P BD Du Dp U 1. L'utilisateur U possède les privilèges Du. 2. La procédure P possède les privilèges Dp. 3. L'utilisateur demande l'exécution de la procédure P. 4. Quels sont les privilèges de U vis-à-vis de la BD lors de l'exécution de P par U ? Quatre politiques distinctes. Les privilèges de U sont :  Du : ceux de U, indépendamment de ceux de P  Dp : ceux de P, quel que soit U  Du  Dp : ceux qui sont communs à U et P  Du  Dp : l'union de ceux de U et de ceux de P Il est évident que les politiques Dp et Du  Dp peuvent être dangereuses dès que P possède plus de privilèges que U, lorsque ce dernier est un attaquant.

Inférence statistique (1) On considère une collection de données individuelles confidentielles soumises à deux règles d'utilisation : l'accès ponctuel aux données sensibles est interdit mais les requêtes statistiques sur ces données sont autorisées Deux observations troublantes : Il est possible d'inférer (illégalement) des données sensibles à partir des réponses à des requêtes statistiques autorisées; Il n'existe pas de contre-mesure générale à ce type d'inférence !

Inférence statistique (2) non sensibles sensibles EMPLOYE NEMP B062 B112 B332 B512 C003 C123 C400 D063 F010 F011 F400 K111 K729 L422 S127 S712 NOM GOFFIN HANSENNE MONTI GILLET AVRON MERCIER FERARD TOUSSAINT PONCELET JACOB VANBIST NEUMAN FRANK VANDERKA GUILLAUME LOCALITE Namur Poitiers Genève Toulouse Bruxelles Lille Paris CAT B2 C1 B1 C2 SALAIRE 2.800 3.050 3.200 3.355 2.600 2.900 2.650 2.950 3.400 1.900 3.800 2.450 3.600 1.950

Inférence statistique (3) On vérifie que la première règle est d'application : select SALAIRE from EMPLOYE where NEMP = 'C400' requête refusée select NEMP from EMPLOYE where SALAIRE between 3000 and 3500 requête refusée On essaye la deuxième : select count(*) as N from EMPLOYE where LOCALITE = 'Toulouse' N 5 select count(*) as N, avg(SALAIRE) as Moy from EMPLOYE where CAT = 'B1' N Moy

Inférence statistique (4) Oui, mais si je demande : select count(*) as N, avg(SALAIRE) as Moy from EMPLOYE where NEMP = 'C400' N Moy ! Ou encore (je ne demande pas de données sensibles) : select count(*) as N from EMPLOYE where NEMP = 'C400' and SALAIRE between 2600 and 2700 N 1 ! On corrige donc la règle : les requêtes statistiques dont la condition d'échantillonnage ne porte pas sur un identifiant sont autorisées

Inférence statistique (5) Parfait. Je peux donc demander : select count(*) as N, avg(SALAIRE) as Moy from EMPLOYE where LOCALITE = 'Namur' and CAT = 'B2' N Moy ! On doit manifestement affiner la règle : les requêtes statistiques portant sur un échantillon de taille K telle que K < k sont interdites

Inférence statistique (6) Le contournement est facile : select count(*) as N1, avg(SALAIRE) as Moy1 from EMPLOYE where not (LOCALITE = 'Namur' and CAT = 'B2') N1 Moy1 ,667 N Moy2 ,4375 select count(*) as N, avg(SALAIRE) as Moy2 from EMPLOYE SALAIRE(LOCALITE = 'Namur' and CAT = 'B2') = (Moy2*N - Moy1*N1) / (N - N1) = (2878,4375* ,667*15) / (16-15) = 2.799,995  2.800 ! Mais la contre-mesure l'est tout autant : les requêtes statistiques portant sur un échantillon de taille K telle que k  K  (N - k) sont autorisées

Inférence statistique (7) Ce n'est hélas pas suffisant : entrée en scène des traceurs !

Inférence statistique (8) On considère, pour une table R de taille N,  un échantillon cible E de taille n défini par la condition C et tel que n < k (le plus souvent, n = 1 ou proche de 1),  une statistique (illégale) dans E portant sur la donnée sensible S; on se limite ici à count et sum. Etant donné une condition quelconque P, on note les statistiques recherchées count(P) ou sum(S,P);  sumSR est la somme des valeurs de S pour la table R On recherche une condition T qui définit un échantillon ET tel que : 2k  count(T)  (N - 2k) Une telle condition est en général aisée à trouver. justifier les 2 k T est un traceur (tracker) généralisé pour R

Inférence statistique (9) ET R E R - ET On observe que  ni R (trop grand) ni E (trop petit) n'ont une taille légale,  on ne peut donc pas calculer directement N, sumSR, n ni sum(S,C).  les échantillons ET et (R - ET) ont une taille légale,  les échantillons (ET - E) et (ET  E) ont aussi une taille légale, en effet : k  count(T and not C) et count(T or C)  (N - k)

Inférence statistique (10) ET R E R - ET On a les propriétés suivantes  N = count(T) + count(not T)  count(T or C) + count(not T or C) = N + n (car E compté 2 fois)  sumSR = sum(S,T) + sum(S,not T)  sum(S,T or C) + sum(S,not T or C) = sumSR + sum(S,C)

Inférence statistique (11) ET R E R - ET ... en exprimant n et sum(S,C) on obtient :  N = count(T) + count(not T)  n = count(T or C) + count(not T or C) - N  sumSR = sum(S,T) + sum(S,not T)  sum(S,C) = sum(S,T or C) + sum(S,not T or C) - sumSR grâce au traceur T, nous avons pu calculer n et sum(S,C)

Inférence statistique (12) Un exemple Soient C  (LOCALITE = 'Namur' and CAT = 'B2') (devrait identifier B062) T  (NOM < 'M') (M est la 13e lettre de l'alphabet) ET: EMPLOYE where NOM < 'M' R: EMPLOYE E: EMPLOYE where LOCALITE = 'Namur and CAT = 'B2' R-ET: EMPLOYE where NOM >= 'M'

Inférence statistique (13) ET: EMPLOYE where NOM < 'M' R: EMPLOYE E: EMPLOYE where LOCALITE = 'Namur' and CAT = 'B2' R-ET: EMPLOYE where NOM >= 'M' On calcule d'abord la taille de R N1 = select count(*) from EMPLOYE where NOM < 'M' = 8 N2 = select count(*) from EMPLOYE where NOM >= 'M' = 8 N = N1 + N = 16 et on vérifie la qualité du traceur : N1/N = 8/16 = 0,5  excellent

Inférence statistique (14) ET: EMPLOYE where NOM < 'M' R: EMPLOYE E: EMPLOYE where LOCALITE = 'Namur' and CAT = 'B2' R-ET: EMPLOYE where NOM >= 'M' on calcule la taille de E (on vérifie que C est bien identifiante) n1 = select count(*) from EMPLOYE where (NOM < 'M') or (LOCALITE = 'Namur' and CAT = 'B2') = 8 n2 = select count(*) from EMPLOYE where (NOM >= 'M') or (LOCALITE = 'Namur' and CAT = 'B2') = 9 n = n1 + n2 - N = 1 C est bien une condition identifiante

Inférence statistique (15) ET: EMPLOYE where NOM < 'M' R: EMPLOYE E: EMPLOYE where LOCALITE = 'Namur' and CAT = 'B2' R-ET: EMPLOYE where NOM >= 'M' On calcule ensuite la somme des salaires dans R sumSR1 = select sum(SALAIRE) from EMPLOYE where NOM < 'M' = sumSR2 = select sum(SALAIRE) from EMPLOYE where NOM >= 'M' = sumSR = sumSR1 + sumSR2 =

Inférence statistique (16) ET: EMPLOYE where NOM < 'M' R: EMPLOYE E: EMPLOYE where LOCALITE = 'Namur' and CAT = 'B2' R-ET: EMPLOYE where NOM >= 'M' On peut enfin calculer le salaire de B062 sumSE1 = select sum(SALAIRE) from EMPLOYE where (NOM < 'M') or (LOCALITE = 'Namur' and CAT = 'B2') = sumSE2 = select sum(SALAIRE) from EMPLOYE where (NOM >= 'M') or (LOCALITE = 'Namur' and CAT = 'B2') = sumSE = sumSE1 + sumSE2 - sumSR = 2.800 le salaire de B062 est !

Inférence statistique (17) Quelques contre-mesures 1. L'anonymisation des données est inutile : suppression, permutation ou transformation de NEMP sans effet. 2. Requêtes exécutées sur un échantillon aléatoire tiré de R; tiré pour chaque requête; mais inférence possible en exécutant une requête un grand nombre de fois. 3. Permutation de données entre les enregistrements; préserve les statistiques de degré n (n = nombre de critères dans le where de la requête statistique); utilise une BD dérivée. 4. Perturbation aléatoire des données sources (distribution normale, m = 0); effet négligeable pour grands échantillons, important pour petits échantillons; utilise une BD dérivée. 5. Perturbation aléatoire des données de l'échantillon; calculé pour chaque requête. 6. Perturbation des résultats (arrondi au plus proche multiple de q); calculé pour chaque requête. 7. Monitoring des requêtes : recherche des séquences douteuses.

Inférence statistique (18) Compromis entre précision des statistiques et protection Pas de solution efficace en toute généralité Le problème existe aussi pour des BD statistiques, ne contenant que des données agrégées !

Suppression sécurisée des données (1) La suppression effective d'un fichier n'est pas une chose simple 1. Supprimé par le système d'exploitation. Mais : peut-être encore dans la poubelle et donc récupérable dans son intégralité. 2. Effacé du catalogue. Mais : peut-être simplement désactivé (premier caractère du nom détruit) et donc récupérable dans son intégralité par un utilitaire undelete. 3. Effacé du catalogue et espace en partie réutilisé par d'autres fichiers. Mais : certains secteurs pas encore réutilisés ni modifiés, et donc consultables. 4. Formatage. Mais : formatage rapide ne modifie que le catalogue et laisse les secteurs de données intacts. Donc faciles à récupérer.

Suppression sécurisée des données (2) 5. Effacé du catalogue et espace totalement réécrit avec des données aléatoires. Exemple : formatage de surface. Mais : on prétend qu’il est possible de détecter des traces magnétiques des données anciennes. Principe théorique : l'écriture magnétique sur le support n'est pas purement binaire. écrire un bit à 1 à l'endroit où se trouvait un 0  0,95 écrire un bit à 1 à l'endroit où se trouvait un 1  1,05 Il serait donc possible de deviner la valeur précédente ! En réalité, cette possibilité n’a jamais été démontrée en pratique. 6. Effacé du catalogue et espace totalement réécrit plusieurs fois avec des patterns binaires soigneusement sélectionnés. OK. 7. Il existe des logiciels spécialisés pour supprimer en profondeur des fichiers sur disques magnétiques (ex : 8. Certains contrôleurs de disques disposent d'une primitive d'effacement en profondeur d'un secteur (ATA).

Suppression sécurisée des données (4) Quid des supports périmés ? Ils peuvent contenir des données sensibles : Bank account numbers, Biometric information; Classified information; Copyrighted material; Corporate financial records; Credit card numbers; Department of Defense secrets; DNA records; Driver's license numbers; Encryption keys; Firewall configuration files; Information security documents; Investment account information; Medical records; Law enforcement records; Legal cases and records; Login and password information; National security information; Passport numbers; Patents; Personal ; Pharmaceutical formulas; Political campaign secrets; Pornography; Proprietary information; Retirement account information; Router ACLs; Security configuration files; Sensitive customer information; Social Security numbers; Standardized test scores; Stock trades; Strategic business plans; Tax records; Trade secrets [

Suppression sécurisée des données (4) 9. Application d'un champ magnétique alternatif intense pour annihiler tous les signaux (= Dégaussage appliqué aux bandes magnétiques et aux disquettes). 10. Certains protocoles recommandent la destruction du support après suppression en profondeur. 11. Même phénomène pour une mémoire flash : il est possible d'identifier les données surchargées. 12. Mémoire RAM éteinte : il est possible d'identifier son contenu au moment de l'extinction de l'ordinateur (1 bit DRAM = un condensateur qui se décharge lentement). Exploitable pour extraire des clés de chiffrement. (

Protection contre les intrusions (vol et fraude)
Menaces Consultation non autorisée de données confidentielles Vol de données Modification frauduleuse de données Destruction de données Techniques d'attaque Débordement de tampon (buffer overflow) Injection de code SQL Détournement de curseur

Principales motivations des vols de données usage frauduleux chantage vente à des organisations criminelles

Débordement de tampon (buffer overflow) pour rappel Attaque dirigée vers le SGBD ou vers l'application Attaque profitant de vulnérabilités des logiciels systèmes, et particulièrement les SGBD.

Injection de code SQL (0) Attaque profitant d'une vulnérabilité largement répandue dans les applications web développées de manière peu soigneuse. Attaque applicable à toute communication entre un client (humain ou programme) et une application accédant à une base de données SQL. Consiste à contrefaire une instruction SQL de manière à la détourner de son objectif initial. Exploite la souplesse du langage SQL dynamique. Une étude en 2003 a montré que 61% des applications étaient vulnérables à l'injection de code SQL (source Sanctum, citée dans [Ben Natan 2005]). Deuxième type d'attaque en 2006 (14%). Permet à l'attaquant d'accéder à la base de données (lecture, insertion, modification, destruction) avec les privilèges de l'application. Google fournit 2,320,000 références (dont 600 majeures) pour la requête "SQL injection" y compris des clips sur YouTube ! Des variantes XML commencent à apparaître

Injection de code SQL - Observation (1) De nombreuses interfaces web comportent des séquences du type 1. acquisition de données via un formulaire 2. accès à la BD sur base de ces données SYS_USERS USER_ID Anne-Mercier Albert-Durant Charles-André PW 73flmrsZZ A7cfg990 biose584h74 autres . . . Albert-Durant Login : A7cfg990 Mot de passe : Identification agent N = 1 select count(*) into :N from SYS_USERS where USER_ID = ' Albert-Durant ' and PW = ' A7cfg990 '; if (N = 0) then AUTORISATION = False else AUTORISATION = True;

Injection de code SQL - Observation (2) Comment cela fonctionne-t-il dans le programme ? SYS_USERS USER_ID Anne-Mercier Albert-Durant Charles-André PW 73flmrsZZ A7cfg990 biose584h74 autres . . . Albert-Durant Login : A7cfg990 Mot de passe : Identification agent [1] String Requete, varLogin, varPW; integer N; [2] getForm (formID, varLogin, varPW); [3] Requete = "select count(*) from SYS_USERS where USER_ID = ' " + varLogin + " ' and PW = ' " + varPW + " ' "; [4] execute immediate from :Requete into :N; [5] if (N = 0) then AUTORISATION = False else AUTORISATION = True;

Injection de code SQL (3) Etude de quatre techniques d'injection neutralisation d'une condition troncature de la clause where surcharge de l'extraction requêtes multiples

Injection de code SQL - Neutralisation (4) On observe que les données fournies par l'utilisateur deviennent des fragments d'une requête SQL. Parfait si l'utilisateur joue le jeu et ne fournit que les données demandées. Danger si l'utilisateur se prend pour un programmeur SQL ! SYS_USERS USER_ID Anne-Mercier Albert-Durant Charles-André PW 73flmrsZZ A7cfg990 biose584h74 autres . . . ' or ' ' = ' Login : Mot de passe : Identification agent N = 3 select count(*) into :N from SYS_USERS where USER_ID = ' ' or ' ' = ' ' and PW = ' ' or ' ' = ' '; if (N = 0) then AUTORISATION = False else AUTORISATION = True; toujours True !

Injection de code SQL - Neutralisation (5) Explication : évaluation de la condition where pour une ligne quelconque de la table SYS_USERS where USER_ID = ' ' or ' ' = ' ' and PW = ' ' or ' ' = ' ' ; USER_ID = ' '  False (normal puisque j'ignore le Login) ' ' = ' '  True (par construction) PW = ' '  False (normal puisque j'ignore le mot de passe) False or True and False or True  False or (True and False) or True  False or (False) or True  True

Injection de code SQL - Troncature (6) Troncature de la clause where par l'injection d'une marque de commentaire (en général "--") - On élimine ainsi un filtre bloquant. ' or ' ' = ' ' -- Login : XXXXXXXX Mot de passe : Identification agent select count(*) into :N from SYS_USERS where USER_ID = ' ' or ' ' = ' ' -- ' and PW = ' XXXXXXXX'; commentaire ignoré  select count(*) into :N from SYS_USERS where USER_ID = ' ' or ' ' = ' ';

Injection de code SQL - Surcharge (7) Surcharge de l'extraction (ajout illégal d'informations confidentielles) COMPTES Client C400 B512 B512 K111 Compte Solde +1500 - 7250 - 50 Extraction des comptes d'un client Numéro Client : B512 select Client, Compte, Solde from COMPTES where Client = ' B512 '; Extraction des comptes d'un client Client Compte Solde B B

Injection de code SQL - Surcharge (8) Surcharge de l'extraction (ajout illégal d'informations confidentielles) SYS_USERS ID_USER Anne-Mercier Albert-Durant Charles-André PW 73flmrsZZ A7cfg990 biose584h74 autres . . . Extraction des comptes d'un client COMPTES Client C400 B512 B512 K111 Compte Solde +1500 - 7250 - 50 Numéro Client : B512' union all select USER_ID, PW, 0 from SYS_USERS where ' ' = ' select Client, Compte, Solde from COMPTES where Client = ' B512' union all select USER_ID, PW, 0 from SYS_USERS where ' ' = ' '; Extraction des comptes d'un client Client Compte Solde B B Anne-Mercier 73flmrsZZ Albert-Durant A7cfg Charles-André biose584h } données secrètes

Injection de code SQL - Requêtes multiples (9) Requêtes multiples par ajout d'une requête illégale COMPTES Client C400 B512 B512 K111 Compte Solde +1500 - 7250 - 50 Extraction des comptes d'un client Numéro Client : B512 select Client, Compte, Solde from COMPTES where Client = ' B512 '; Extraction des comptes d'un client Client Compte Solde B B

Injection de code SQL - Requêtes multiples (10) Requêtes multiples par ajout d'une requête illégale SYS_USERS ID_USER Anne-Mercier Albert-Durant Charles-André PW 73flmrsZZ A7cfg990 biose584h74 autres . . . Extraction des comptes d'un client COMPTES Client C400 B512 B512 K111 Compte Solde +1500 - 7250 - 50 Numéro Client : B512'; delete from SYS_USERS where ' ' = ' select Client, Compte, Solde from COMPTES where Client = ' B512'; delete from SYS_USERS where ' ' = ' '; Extraction des comptes d'un client Client Compte Solde B B SYS_USERS USER_ID PW autres ! ! !

Injection de code SQL - Requêtes multiples (11) Requêtes multiples par ajout d'une requête illégale SYS_USERS ID_USER Anne-Mercier Albert-Durant Charles-André PW 73flmrsZZ A7cfg990 biose584h74 autres . . . Extraction des comptes d'un client COMPTES Client C400 B512 B512 K111 Compte Solde +1500 - 7250 - 50 Numéro Client : B512'; insert into SYS_USERS(USER_ID, PW) values('JLH','X') -- select Client, Compte, Solde from COMPTES where Client = 'B512'; insert into SYS_USERS(USER_ID,PW) values('JLH','X') --'; Extraction des comptes d'un client Client Compte Solde B B SYS_USERS USER_ID Anne-Mercier Albert-Durant Charles-André JLH PW 73flmrsZZ A7cfg990 biose584h74 X autres . . . ! ! !

Injection de code SQL (12) Comment mener une attaque lorsqu'on ne connaît pas le schéma de la base de données ? Par essais successifs. Peuvent prendre beaucoup de temps. Intérêt à fractionner les séances pour ne pas se faire repérer par une analyse de comportement déviant (pattern d'attaque) Par une bonne connaissance du SGBD cible. Grâce à la complaisance du SGBD et au laxisme du programmeur en cas d'erreur : SQL Server : Msg 205: All queries in a SQL statement containing a UNION operator must have an equal number of expressions in their target lists. Merci mille fois ! Je sais maintenant que je dois affiner mon attaque par Surcharge de l'extraction en modifiant le nombre de colonnes de la 2e requête jusqu'à ce que ce message disparaisse.

Injection de code SQL (13) Analyse de la vulnérabilité (1) 1. La requête SQL est construite dynamiquement. 2. Le SGBD autorise l'exécution de requêtes multiples. 3. Le SGBD applique des conversions automatiques (chaîne de caractères  numérique).

Injection de code SQL (14) Analyse de la vulnérabilité (2) 4. Programmation simpliste non défensive basée sur la loyauté de l'utilisateur. 5. Usage de SQL dynamique par concaténation de fragments incluant les constantes des conditions. 6. Les données fournies par l'utilisateur ne sont pas vérifiées par le programme. 7. La requête construite dynamiquement n'est pas vérifiée par le programme avant soumission au SGBD. 8. La requête se termine par une constante numérique (apostrophe inutile). 9. Le SGBD fournit des messages d'erreurs richement informatifs; ces messages ne sont pas filtrés par le programme mais transmis tels quels à l'utilisateur. 10. Le programme jouit de privilèges étendus indépendants de la tâche en cours et de l'utilisateur. 11. Formation insuffisante des développeurs dans le domaine des bases de données.

Injection de code SQL (15) Contre-mesures (1) 1. Utilisation de SQL statique. 2. Utilisation de SQL dynamique clean avec préparation et liaison de variable plutôt qu'injection des constantes par concaténation. 3. Analyse des données fournies par l'utilisateur. 4. Transformation des données fournies par l'utilisateur. 5. Analyse de la requête construite dynamiquement avant soumission au SGBD. 6. Filtrage des messages d'erreurs fournis par le SGBD et à transmettre à l'utilisateur.

Injection de code SQL (16) Contre-mesures (2) 7. Monitoring par analyse des journaux de requêtes (log mining), temps-réel, semi temps-réel, off-line. 8. Adaptation des privilèges du programme à l'utilisateur 9. Recherche des vulnérabilités dans les programmes (analyse de code, outils d'attaque par injection). 10. Traçabilité des opérations 11. Amélioration de la formation des développeurs dans le domaine des bases de données. 12. Login biométrique, par carte à puce.

Injection de code SQL (17) Contre-mesures (3) 1. Utilisation de SQL statique (SQLJ) getForm (formID, varCLI); #SQL {select Compte, Solde into :varCPT, :varSOL from COMPTES where Client = :varCLI} La structure de l'instruction est figée et ne peut être contrefaite. Le contenu de la variable varCLI est interprété comme une valeur de Client et rien d'autre. 2. Utilisation de SQL dynamique clean avec préparation et liaison (JDBC) getForm (formID, varCLI); Requete = "select Compte, Solde from COMPTES where Client = ?} inst = con.prepareStatement (Requete); inst.setString(1, varCLI); res = inst.executeQuery(); Même sécurité que 1.

Injection de code SQL (18) Contre-mesures (4) 3. Analyse des données fournies par l'utilisateur Normalement, une valeur de mot de passe est de taille limitée, ne contient pas d'apostrophes ni d'espaces, ne contient pas de mots réservés SQL. Il peut être intéressant de vérifier que la valeur fournie se trouve dans une liste de référence (Login par exemple), à l'aide d'une requête SQL statique.

Injection de code SQL (19) Contre-mesures (5) 4. Transformation des données fournies par l'utilisateur Les apostrophes sont largement utilisées pour contrefaire une instruction SQL. Or, les seules apostrophes autorisées devraient faire partie de la valeur transmise (23, Rue de l'Eté). En SQL, une telle apostrophe apparaissant dans une valeur doit être protégée par un redoublement ou un caractère "escape" : 23, Rue de l'Eté  23, Rue de l''Eté Suggestion : doubler toutes les apostrophes des valeurs introduites, ce qui perturbe les contrefaçons et préserve les bonnes apostrophes. Exemple : fonction mySQL mysql_real_escape_string(), qui transforme les symboles spéciaux en caractères avec échappement

Injection de code SQL (20) Contre-mesures (6) 5. Analyse de la requête construite dynamiquement avant soumission Responsabilité du programme. Détection des instructions multiples, de mots réservés SQL non pertinents, de noms de composants des tables systèmes. Mais brouillage possible par commentaires internes. Ex. en MySQL : de/*il fait beau*/le/*mais le temps se couvre !*/te = delete Intérêt de la programmation orientée aspect (AspectJ par exemple) pour analyser les requêtes et les résultats (projet RISTART, FUNDP). Il existe des outils qui s'interposent entre l'application et le serveur SQL afin d'analyser les requêtes(SQLRand, Columbia University)

Injection de code SQL (21) Contre-mesures (7) 6. Filtrage des messages d'erreurs L'utilisateur n'a pas à connaître le détail des erreurs techniques. Le message doit être traduit et abstrait ("Erreur technique. Veuillez nous excuser") au lieu de "Msg 205: All queries in a SQL statement containing a UNION ...". Attention : réagir = information exploitable ! 7. Monitoring par analyse des journaux de requêtes (log mining), temps-réel, semi temps-réel, off-line. Le SGBD maintient un journal de toutes les instructions SQL reçues et exécutées, ainsi que les messages d'erreurs. On recherche : les instructions anormales pour la fonction effectuée (un drop table dans un login), des patterns d'attaques typiques des erreurs anormales en exploitation, typique d'un fonctionnement en test : type de colonnes et nombre de colonnes invalides, table/colonne inconnues fréquence anormale d'erreurs Temps réel, semi temps-réel, off-line. Il existe des outils d'analyse en streaming.

Injection de code SQL (22) Contre-mesures (8) 8. Adaptation des privilèges du programme à l'utilisateur Principe du "Minimal Privilege". Eviter de demander globalement des privilèges pour toutes les opérations de l'utilisateur. Définir les privilèges suffisants pour chaque opération. 9. Recherche des vulnérabilité dans les programmes Analyse du code des programmes. Recherche des patterns douteux (bad smells), à soumettre au programmeur. (p. ex. WebInspect de HP) Utilisation d'outils d'attaque par injection.

Injection de code SQL (23) Contre-mesures (9) 10. Traçabilité des opérations Toute modification doit être soigneusement identifiée, documentée et justifiée. Journaliser toutes les modifications : journal des opérations, journal des images des données (before, after). Interdire les substitutions : approches append-only. On ne remplace pas une valeur, on insère un nouvel état qu'on déclare courant = BD temporelles. On peut ainsi toujours tracer toutes les valeurs enregistrées. Traçage par des triggers ajoutés. Traçage par procédures SQL (mais modification des programmes)

Injection de code SQL (24) Contre-mesures (10) 11. Amélioration de la formation des développeurs dans le domaine des bases de données. Principes des bases de données Méthodologie de conception de bases de données Maîtrise approfondie du langage SQL et du SGBD utilisé Principes de programmation sur base de données (ESQL, CLI, statique, dynamique Principes de la sécurité Mais ... pas dans l'air du temps ! (Pas le temps ! Etudier c'est pas cool !) 12. Login biométrique, par carte à puce.

Détournement de curseur (cursor snarfing) (1) Principe : l'attaquant exécute légalement une procédure dont il provoque l'échec inattendu, ce qui laisse un curseur non fermé; il lance alors une procédure chargée de se reconnecter au curseur et de l'exploiter afin d'extraire illégalement des données [Litchfield, 2006]. La lecture de données dans la BD se fait généralement comme suit : [1] définition d'un curseur à partir d'une requête Q [2] ouverture du curseur [3] lecture itérative des données via le curseur [4] fermeture du curseur Normalement, lorsqu'une erreur se produit, le programme doit la traiter de manière appropriée; notamment fermer le curseur ! Or, certains programmeurs ne pensent pas toujours à traiter les erreurs qui, normalement, ne doivent pas se produire.

Détournement de curseur (cursor snarfing) (2) Si, entre [2] et [4] on provoque artificiellement une erreur (on transmet une valeur anormalement longue) et si ce type d'erreur n'est pas traité, alors la procédure se termine mais la connexion et le curseur restent ouverts (dangling cursor). Un attaquant peut alors récupérer le curseur ouvert pour extraire illégalement les données selon la requête Q. Le curseur est souvent désigné par un nombre entier; sa valeur est soit affichée dans le message d'erreur, soit retrouvée par essais successifs par l'attaquant. L'attaquant est un utilisateur enregistré (légalement ou illégalement) mais qui ne posséde pas assez de privilèges pour exécuter Q, peut créer une procédure et l'exécuter, exécute cette procédure pour récupérer le curseur laissé ouvert.

Conclusions Importance du facteur humain (utilisateur, programmeur, analyste, gestionnaire, installeur, exploitant). Importance de la formation (administrateur de BD, programmeur sur BD). Familles de vulnérabilités et de menaces identifiées mais évolutives. Fortes liaison avec les autres aspects de la sécurité : notamment programmation et réseau. Pas encore de modèle global de la sécurité des BD. La sécurité : non seulement un métier en soi, mais surtout une préoccupation majeure de chaque métier intervenant dans la conception, l'évolution, l'exploitation et l'utilisation des Systèmes d'information.

Références Site technique sur la sécurité des SGBD : Site de news sur la sécurité : Common weakness enumeration - CWE Dictionary, CAPEC - Common Attack Pattern Enumeration and Classification, David Litchfield, The Oracle Hacker's Handbook: Hacking and Defending Oracle, David Litchfield, Wiley, 2007 Rebecca Bond, Kevin Yeung-Kuen See, Carmen Ka Man Wong, Yuk-Kuen Henry Chan, Understanding DB2 9 Security, IBM Press, 2007 David Litchfield, "Cursor Injection", Ron Ben Natan, Implementing Database Security and Auditing: Includes Examples for Oracle, SQL Server, DB2 UDB, Sybase, Elsevier Digital Press, 2005 Bertino, E., Data Security, Data & Knowledge Engineering, 25 (1998), pp , Elsevier Chris Anley, Advanced SQL Injection In SQL Server Applications, NGS Software Insight Security Research (NISR) Publication, 2002,

Références Wikipedia, SQL Injection, SQL injection. Analyse pour PHP : Denning D., Schlörer, J., A Fast Algorithm for Calculating a Tracker in Statistical Database, ACM Transactions on Database Systems, Vol. 5, No. 1, March 1980 Muralidhar, K., Sarathy, R., Security of Random Data Perturbation Methods, ACM Transactions on Database Systems, Vol. 24, No. 4, Dec. 1999, pp. 487–493 Sicherman, G., De Jonge, W., Van De Riet, R., Answering Queries Without Revealing Secrets, ACM Transactions on Database Systems, Vol. 8, No. 1, March 1983, Pages De Jonge, W., Compromising Statistical Databases Responding to Queries about Means, ACM Transactions on Database Systems, Vol. 8, No. 1, March 1983, Pages Denning D., Secure Statistical Databases with Random Sample Queries, ACM Transactions on Database Systems, Vol. 5, No. 3, September 1980, Pages Denning D., Denning P., Schwartz, M., The Tracker: A Threat to Statistical Database Security, ACM Transactions on Database Systems, Vol. 4, No. 1, March 1979, Pages Hughes, G., Coughlin, T., Tutorial on Disk Drive Data Sanitization, 2006,

Références Connolly, T., Begg, C., Database Systems, Addison Wesley, 2005 [Chapter 18, Security, 29 pages] Litchfield, D., Dangling Cursor Snarfing: A New Class of Attack in Oracle, 23rd November 2006, Litchfield, D., Anley, C., Heasman, J., Grindlay, B., The Database Hacker's Handbook: Defending Database Servers, Wiley, 2005 Workbench d'expérimentation des différentes vulnérabilités d'un site web : Clarke, J., SQL Injection Attacks and Defense, Syngress Publish., Elsevier, 2009

Introduction à la Sécurité des Bases de Données

Présentations similaires

Présentation au sujet: "Introduction à la Sécurité des Bases de Données"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Introduction à la Sécurité des Bases de Données

Présentations similaires

Présentation au sujet: "Introduction à la Sécurité des Bases de Données"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back