Securite BD

Introduction
à la Sécurité des
Bases de Données
Jean-Luc Hainaut
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
2 2007-2008
 Conclusions
 Références
3 2007-2008
Motivations et introduction
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 e-mail addresses from the company to sell to a spammer.
http://www.securityfocus.com/news/10271
4 2007-2008
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, voicemail password, secret question/answer, sim#,
IMEA#, and more" Ces données provenaient de la BD de l'opérateur wifi T-
Mobile (2004). http://www.securityfocus.com/news/10271
SQL Slammer (janvier 2003). Ce ver a infecté en 10 minutes plus de 120.000

serveurs SQL Server 2000. Technique : buffer overflow.
5 2007-2008
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 à 10.000.000 utilisateurs
anonymes et incontrôlés)
6 2007-2008
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
7 2007-2008
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
8 2007-2008
 Conclusions
 Références
9 2007-2008
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)
10 2007-2008
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)
11 2007-2008
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
12 2007-2008
communications
Interface Application
usagers utilisateur (business logic)
SGBD
BD
BD schéma
données
station serveur serveur

cliente d'application de données
13 2007-2008
BDR et SGBDR : les données sont stockées dans des tables
14 2007-2008
BD et SGBD : les composants d'une table
identifiant schéma
(primary key)
ligne
données
colonne colonne
obligatoire facultative
15 2007-2008
BD et SGBD : un formulaire contenant des données
16 2007-2008
BD et SGBD : stockage des données du formulaire
clé étrangère
(foreign key)
17 2007-2008
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
18 2007-2008
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.
19 2007-2008
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
20 2007-2008
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)
21 2007-2008
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)
22 2007-2008
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 ( les valeurs de la colonne NCLI

comportent 4 caractères
NCLI char(4) not null,
NOM char(32) not null,
ADRESSE varchar(100) not null, la colonne NOM est obligatoire
LOCALITE char(30) not null,
CAT char(2), la colonne CAT est facultative
COMPTE decimal(8,2) not null, la colonne NCLI est un

primary key (NCLI) ); identifiant de la table CLIENT
create table COMMANDE (

NCOM integer not null,
NCLI char(4) not null,
DATECOM date not null, la colonne NCLI est une clé
primary key (NCOM), étrangère vers la table CLIENT
foreign key (NCLI) references CLIENT);
23 2007-2008

on demande de supprimer la
drop table FACTURE ; table FACTURE et son contenu.
alter table COMMANDE on demande d'ajouter une

add column MONTANT decimal (6,2) not null; colonne MONTANT à la table
COMMANDE.
create view CLIENT_TOULOUSE (NUM, NOM, ADRESSE, CATEGORIE)

as select NCLI, NOM, ADRESSE, CAT
on demande de créer une vue,
from CLIENT c-à-d une table virtuelle
where LOCALITE = 'Toulouse'; adaptée aux besoins d'une
catégorie d'utilisateurs.
create table PRODUIT (NPRO .., LIBELLE .., PRIX .., QSTOCK ..,
primary key (NPRO), prédicat check définissant une
check (PRIX > 0) ) contrainte sur les valeurs de la
colonne PRIX.
24 2007-2008
create procedure MODIFIER_CLIENT (in N char(4), LOC char(30))

begin
on demande de créer une procédure
<actions sur la base de données> et de l'enregistrer dans la base de
end; données.
create trigger MAJ_CLI

after insert on CLIENT on demande de créer un trigger, c-à-d
une procédure qui se déclenche
for each row automatiquement. Ici, après chaque
begin insertion d'une ligne de CLIENT, on
insert into JOURNAL(OPER,NCLI, INSTANT) ajoute à la table JOURNAL une trace
de l'opération.
values ('insert', new.NCLI, Current_Time);
end
25 2007-2008
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
26 2007-2008
Le langage SQL - SQL/DML (extraction de données)
on extrait les valeurs de NCLI, NOM,

et ADRESSE ...
select NCLI, NOM, ADRESSE
des lignes de la table CLIENT ...
from CLIENT
where LOCALITE = 'Toulouse' pour lesquelles LOCALITE a la
valeur 'Toulouse' ...
order by NCLI;
le résultat doit être ordonné par
valeurs croissantes de NCLI
select NCLI, NOM, ADRESSE
from CLIENT une condition plus complexe
where LOCALITE = 'Toulouse' and CAT = 'B1';
select NCLI, NOM from CLIENT

where LOCALITE = 'Toulouse' priorité de 'and' sur 'or'. Une ligne est
and CAT = 'B1' sélectionnée :
- soit si (LOCALITE = 'Toulouse') et (CAT = 'B1')
or COMPTE > 0; - soit si (COMPTE > O)
- soit si toutes les conditions sont réunies
27 2007-2008
select NCLI, NOM, ADRESSE from CLIENT

une condition curieuse mais valide;
where 'A' = 'A'; elle est toujours vraie; toutes les lignes
seront sélectionnées
select NCLI, NOM, ADRESSE from CLIENT cette condition sera toujours vraie,
même s'il n'existe pas de client dont
where NCLI = 'C400' or 'A' = 'A'; 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 !
28 2007-2008

on extrait deux fonctions statistiques :
le nombre de lignes et la somme des
select count(*), sum(COMPTE) valeurs de COMPTE ...
from CLIENT des lignes de la table CLIENT ...
where LOCALITE = 'Toulouse'; dont LOCALITE a la valeur 'Toulouse' ...
on extrait des données ...

select NCOM, DATECOM, CLIENT.NCLI, NOM
from COMMANDE, CLIENT ... de deux tables dont les lignes sont
appariées par une jointure définie par ...
where COMMANDE.NCLI = CLIENT.NCLI;
... une condition de jointure
select NOM, LOCALITE from CLIENT

le résultat global de cette requête
union all composée est l'union des résultats
select NOM, LOCALITE from PROSPECT; des deux requêtes élémentaires ('all'
= on garde les doublons)
29 2007-2008
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 ... dont COMPTE > 0 ...
set CAT = 'B2
... en changeant leur valeur de CAT.
where COMPTE > 0;
on demande de supprimer de la table

delete from COMMANDE COMMANDE les lignes ...
where NCLI = 'C400'; ... dont NCLI = 'C400'
30 2007-2008
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 !
31 2007-2008
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 !
32 2007-2008
Le langage SQL - anatomie d'une instruction

résultats
select NCLI, NOM

from CLIENT
where LOCALITE = 'Toulouse' and CAT = 'B1'
données
update PRODUIT résultats

set PRIX = 110 (OK / KO)
where NPRO = 'PA45'

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

display R1, R2; exploitation des résultats
34 2007-2008
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)
35 2007-2008
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)
36 2007-2008
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)
37 2007-2008
 Conclusions
 Références
38 2007-2008
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
39 2007-2008
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.
40 2007-2008
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

Exemples :
 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
41 2007-2008
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.
42 2007-2008
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é.
43 2007-2008
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
44 2007-2008
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)
45 2007-2008
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.
46 2007-2008
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).
47 2007-2008
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.
48 2007-2008
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)
49 2007-2008
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).
50 2007-2008
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).
51 2007-2008
 Conclusions
 Références
52 2007-2008
Disponibilité des données
 Disponibilité et continuité de service

 Menaces
 Contre-mesures
 Notion de transaction
 Reprise à chaud
 Reprise à froid
53 2007-2008
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é
54 2007-2008
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.
55 2007-2008
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.
56 2007-2008
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.
57 2007-2008
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
58 2007-2008
• 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.
59 2007-2008
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.
60 2007-2008
• Exemple : transfert entre comptes (version "pédagogique")

lire et modifier
getForm(CPT1, CPT2, M); le compte source
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
lire et modifier
<suite du programme> le compte destinataire
61 2007-2008
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
62 2007-2008
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.
63 2007-2008
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.
64 2007-2008
 Conclusions
 Références
65 2007-2008
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
66 2007-2008
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
67 2007-2008
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
68 2007-2008
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
69 2007-2008
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
70 2007-2008
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
71 2007-2008
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
72 2007-2008

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
F2 Lo2
R x
W
Ls
R
W x Lo1
F1
73 2007-2008
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.
74 2007-2008
R
F1
U1
R
R/W
U2 F2
75 2007-2008
R
F1
U1
W
R/W
U2 F2
U1 P F1
cT
! F1
U2 F2
76 2007-2008
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
77 2007-2008
Lu1
U1 P F1 Lf1
cT
x
no write-down F2
U2
Lu2 Lf2
78 2007-2008
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).
79 2007-2008
• 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.
80 2007-2008

le propriétaire/administrateur (U1) de la
table CLIENT accorde le droit d'effectuer
cette opération (O) ...
grant select(NCLI, NOM, LOCALITE)
... sur la table CLIENT (D)
on CLIENT
to MERCIER; ... à l'utilisateur MERCIER (U2)
grant update (QSTOCK, PRIX)

on PRODUIT GEST05 reçoit en outre de droit
d'accorder ce privilège à d'autres
to GEST05 utilisateurs. Il devient administrateur
with grand option; (délégué) de PRODUIT.
grant select
on PRODUIT Ce privilège est accordé à tous les
to public; utilisateurs, présents et futurs.
81 2007-2008
grant run On accorde le droit d'exécuter la

on MODIFIER_CLIENT procédure MODIFIER_CLIENT
to MERCIER;
revoke update (QSTOCK)

Désormais, GEST05 ne peut plus
on PRODUIT modifier les valeurs de QSTOCK dans la
to GEST05; 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
82 2007-2008
1. L'utilisateur U possède Dp
U P BD
les privilèges Du.
2. La procédure P possède
Du
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.
83 2007-2008
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 !
84 2007-2008

non sensibles sensibles
EMPLOYE
NEMP NOM LOCALITE CAT SALAIRE
B062 GOFFIN Namur B2 2.800
B112 HANSENNE Poitiers C1 3.050
B332 MONTI Genève B2 3.200
B512 GILLET Toulouse B1 3.355
C003 AVRON Toulouse B1 2.600
C123 MERCIER Namur C1 2.900
C400 FERARD Poitiers B2 2.650
D063 MERCIER Toulouse C2 2.800
F010 TOUSSAINT Poitiers C1 2.950
F011 PONCELET Toulouse B2 3.400
F400 JACOB Bruxelles C2 1.900
K111 VANBIST Lille B1 3.800
K729 NEUMAN Toulouse B1 2.450
L422 FRANK Namur C1 2.650
S127 VANDERKA Namur C1 3.600
S712 GUILLAUME Paris B1 1.950
85 2007-2008
On vérifie que la première règle est d'application :

select SALAIRE
from EMPLOYE requête refusée
where NEMP = 'C400'
select NEMP
from EMPLOYE requête refusée
where SALAIRE between 3000 and 3500
On essaye la deuxième :
select count(*) as N N
from EMPLOYE 5
where LOCALITE = 'Toulouse'
select count(*) as N, avg(SALAIRE) as Moy N Moy

from EMPLOYE 5 2.831
where CAT = 'B1'
86 2007-2008
Oui, mais si je demande :

from EMPLOYE
where NEMP = 'C400'
1 2.650 !
Ou encore (je ne demande pas de données sensibles) :
select count(*) as N
N
from EMPLOYE
where NEMP = 'C400' 1 !
and SALAIRE between 2600 and 2700
On corrige donc la règle :

les requêtes statistiques dont la condition d'échantillonnage ne
porte pas sur un identifiant sont autorisées
87 2007-2008
Parfait. Je peux donc demander :

from EMPLOYE
where LOCALITE = 'Namur' and CAT = 'B2'
1 2.800 !
On doit manifestement affiner la règle :
les requêtes statistiques portant sur un échantillon de taille K
telle que K < k sont interdites
88 2007-2008
Le contournement est facile :

select count(*) as N1, avg(SALAIRE) as Moy1 N1 Moy1
from EMPLOYE 15 2.883,667
where not (LOCALITE = 'Namur' and CAT = 'B2')
N Moy2
select count(*) as N, avg(SALAIRE) as Moy2
from EMPLOYE 16 2.878,4375
SALAIRE(LOCALITE = 'Namur' and CAT = 'B2')

= (Moy2*N - Moy1*N1) / (N - N1)
= (2878,4375*16 - 2883,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
89 2007-2008
Ce n'est hélas pas suffisant :
entrée en scène des traceurs !
90 2007-2008

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
2k  count(T)  (N - 2k) i e r l es
justif
Une telle condition est en général aisée à trouver.
T est un traceur (tracker) généralisé pour R
91 2007-2008

E
R
ET 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)
92 2007-2008

E
R
ET 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)
93 2007-2008

E
R
ET 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)
94 2007-2008
Un exemple
Soient
C  (LOCALITE = 'Namur' and CAT = 'B2') (devrait identifier B062)
T  (NOM < 'M') (M est la 13e lettre de l'alphabet)
E: EMPLOYE where
LOCALITE = 'Namur and CAT = 'B2'
R: EMPLOYE
ET: EMPLOYE where R-ET: EMPLOYE where

NOM < 'M' NOM >= 'M'
95 2007-2008
E: EMPLOYE where
LOCALITE = 'Namur' and CAT = 'B2'
R: EMPLOYE

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 + N2
= 16
et on vérifie la qualité du traceur : N1/N = 8/16 = 0,5  excellent
96 2007-2008

E: EMPLOYE where
R: EMPLOYE

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
97 2007-2008
E: EMPLOYE where
R: EMPLOYE

On calcule ensuite la somme des salaires dans R

sumSR1 = select sum(SALAIRE) from EMPLOYE where NOM < 'M' = 20.955
sumSR2 = select sum(SALAIRE) from EMPLOYE where NOM >= 'M' = 25.100
sumSR = sumSR1 + sumSR2 = 46.055
98 2007-2008

E: EMPLOYE where
R: EMPLOYE

On peut enfin calculer le salaire de B062

sumSE1 = select sum(SALAIRE) from EMPLOYE
where (NOM < 'M') or (LOCALITE = 'Namur' and CAT = 'B2') = 20.955
sumSE2 = select sum(SALAIRE) from EMPLOYE
where (NOM >= 'M') or (LOCALITE = 'Namur' and CAT = 'B2') = 27.900
sumSE = sumSE1 + sumSE2 - sumSR = 2.800
le salaire de B062 est 2.800 !
99 2007-2008

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.
100 2007-2008
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 !
101 2007-2008
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.
102 2007-2008
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 : http://www.killdisk.com/).
8. Certains contrôleurs de disques disposent d'une primitive
d'effacement en profondeur d'un secteur (ATA).
103 2007-2008
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 email; 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 [http://www.edrsolutions.com/]
104 2007-2008
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. (http://citp.princeton.edu/pub/coldboot.pdf)
105 2007-2008
 Conclusions
 Références
106 2007-2008
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
107 2007-2008
Principales motivations des vols de données

 usage frauduleux
 chantage
 vente à des organisations criminelles
108 2007-2008
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.
109 2007-2008
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
110 2007-2008
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 Identification agent

USER_ID PW autres
Login : Albert-Durant
Anne-Mercier 73flmrsZZ ...
Albert-Durant A7cfg990 ...
Mot de passe : A7cfg990
Charles-André biose584h74 ...
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;
111 2007-2008
Injection de code SQL - Observation (2)

Comment cela fonctionne-t-il dans le programme ?

USER_ID PW autres
Login : Albert-Durant
Mot de passe : A7cfg990
[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;
112 2007-2008
Etude de quatre techniques d'injection

 neutralisation d'une condition
 troncature de la clause where
 surcharge de l'extraction
 requêtes multiples
113 2007-2008
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 !

USER_ID PW autres
Login : ' or ' ' = '
Mot de passe : ' or ' ' = '
N=3

from SYS_USERS
where USER_ID = ' ' or ' ' = ' ' and PW = ' ' or ' ' = ' '; toujours True !
if (N = 0) then AUTORISATION = False else AUTORISATION = True;
114 2007-2008
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)
 ''=''  True (par construction)
False or True and False or True
 False or (True and False) or True
 False or (False) or True
 True
115 2007-2008
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.
Identification agent
Login : ' or ' ' = ' ' --
Mot de passe : XXXXXXXX

from SYS_USERS commentaire
where USER_ID = ' ' or ' ' = ' ' -- ' and PW = ' XXXXXXXX'; ignoré

from SYS_USERS
where USER_ID = ' ' or ' ' = ' ';
116 2007-2008
Injection de code SQL - Surcharge (7)

Surcharge de l'extraction (ajout illégal d'informations confidentielles)
COMPTES Extraction des comptes d'un client

Client Compte Solde
Numéro Client : B512
C400 1770482-02 +1500
B512 8400254-37 - 7250
B512 0309477-37 - 50
K111 7901432-19 - 51005
select Client, Compte, Solde

from COMPTES
where Client = ' B512 ';
Extraction des comptes d'un client

Client Compte Solde
B512 8400254-37 - 7250
B512 0309477-30 - 50
117 2007-2008
Injection de code SQL - Surcharge (8)

Surcharge de l'extraction (ajout illégal d'informations confidentielles)
SYS_USERS
ID_USERCOMPTES PW autres
Anne-Mercier
Client 73flmrsZZSolde . . .
Compte Numéro Client : B512' union all select USER_ID, PW, 0
Albert-Durant A7cfg990 ... from SYS_USERS where ' ' = '
C400 1770482-02
Charles-André biose584h74+1500 . . .
B512 8400254-37 - 7250
B512 0309477-37 - 50
K111 7901432-19 - 51005

from COMPTES
where Client = ' B512' union all select USER_ID, PW, 0
from SYS_USERS where ' ' = ' ';

Client Compte Solde
B512 8400254-37 - 7250
B512 0309477-30 - 50
Anne-Mercier
Albert-Durant
Charles-André
73flmrsZZ
A7cfg990
biose584h74
0
0
0
} données secrètes
118 2007-2008
Injection de code SQL - Requêtes multiples (9)

Requêtes multiples par ajout d'une requête illégale
COMPTES Extraction des comptes d'un client

Client Compte Solde
Numéro Client : B512
C400 1770482-02 +1500
B512 8400254-37 - 7250
B512 0309477-37 - 50
K111 7901432-19 - 51005

from COMPTES
where Client = ' B512 ';

Client Compte Solde
B512 8400254-37 - 7250
B512 0309477-30 - 50
119 2007-2008

SYS_USERS
Anne-Mercier
Compte Numéro Client : B512'; delete from SYS_USERS
Albert-Durant A7cfg990 ... where ' ' = '
C400 1770482-02
B512 8400254-37 - 7250
B512 0309477-37 - 50
K111 7901432-19 - 51005

from COMPTES
where Client = ' B512'; delete from SYS_USERS where ' ' = ' ';
SYS_USERS
USER_ID PW autres
Client Compte Solde
B512 8400254-37 - 7250
B512 0309477-30 - 50
! ! !
120 2007-2008

SYS_USERS
Anne-Mercier
Compte Numéro Client : B512'; insert into SYS_USERS(USER_ID,
Albert-Durant A7cfg990 ... PW) values('JLH','X') --
C400 1770482-02
B512 8400254-37 - 7250
B512 0309477-37 - 50
K111 7901432-19 - 51005

from COMPTES
where Client = 'B512'; insert into SYS_USERS(USER_ID,PW)
values('JLH','X') --';
Extraction des comptes d'un client SYS_USERS

USER_ID PW autres
Client Compte Solde
B512 8400254-37 - 7250
B512 0309477-30 - 50
!
Albert-Durant
Charles-André !
A7cfg990
biose584h74 !
...
...
JLH X
121 2007-2008

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.
122 2007-2008

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).
123 2007-2008

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.
124 2007-2008

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.
125 2007-2008

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.
126 2007-2008

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.
127 2007-2008

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.
128 2007-2008

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
129 2007-2008

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)
130 2007-2008

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.
131 2007-2008

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.
132 2007-2008

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)
133 2007-2008

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.
134 2007-2008
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.
135 2007-2008
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.
136 2007-2008
 Conclusions
 Références
137 2007-2008
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.
138 2007-2008
Références
 Site technique sur la sécurité des SGBD : http://www.databasesecurity.com/

 Site de news sur la sécurité : http://search.securityfocus.com
 Common weakness enumeration - CWE Dictionary,
http://cwe.mitre.org/data/dictionary.html
 CAPEC - Common Attack Pattern Enumeration and Classification,
http://capec.mitre.org/data/dictionary.html
 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", http://www.databasesecurity.com/dbsec/cursor-
injection.pdf
 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. 199-216,
Elsevier
 Chris Anley, Advanced SQL Injection In SQL Server Applications, NGS Software
Insight Security Research (NISR) Publication, 2002,
http://www.ngssoftware.com/papers/advanced_sql_injection.pdf
139 2007-2008
Références
 Wikipedia, SQL Injection, http://en.wikipedia.org/wiki/SQL_injection

 SQL injection. Analyse pour PHP :
http://be.php.net/manual/en/security.database.sql-injection.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
41-59.
 De Jonge, W., Compromising Statistical Databases Responding to Queries about
Means, ACM Transactions on Database Systems, Vol. 8, No. 1, March 1983, Pages
60-80.
 Denning D., Secure Statistical Databases with Random Sample Queries, ACM
Transactions on Database Systems, Vol. 5, No. 3, September 1980, Pages 291-315.
 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
76-96.
 Hughes, G., Coughlin, T., Tutorial on Disk Drive Data Sanitization, 2006,
http://cmrr.ucsd.edu/people/Hughes/DataSanitizationTutorial.pdf
140 2007-2008
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, http://securitywatch.eweek.com/cursor-snarfing.pdf
 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 :
http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
 Clarke, J., SQL Injection Attacks and Defense, Syngress Publish., Elsevier, 2009
141 2007-2008

Securite BD

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Securite BD

Transféré par

Droits d'auteur :

Formats disponibles

Introduction

Quelques faits [Ben Natan, 2005]

Conférences dédiées au hacking (BlackHat, Defcon, etc.)

En 2001, plus de 40% de compagnies bancaires et financières ont subi des

Jason Smathers, a former AOL employee accused of stealing 92 million

Quelques faits [Ben Natan, 2005]

Annonce trouvée sur muzzfuzz.com : "[A]m offering reverse lookup of

SQL Slammer (janvier 2003). Ce ver a infecté en 10 minutes plus de 120.000

Sécurité d'une base de données

Base de données : au coeur du système d'information (SI).

L'accès aux bases de données via le web augmente considérablement les

Cinq dangers spécifiques

La sécurité des bases de données est un domaine complexe, polymorphe,

Il n'existe pas encore de solution globale ni de recettes clé-sur-porte.

Système d'information : les composants techniques

station serveur serveur

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

BD et SGBD : les composants d'une table

BD et SGBD : un formulaire contenant des données

BD et SGBD : stockage des données du formulaire

Les composants d'une base de données

Les données comprennent

Les composants d'une base de données

de 20 à 50 tables, dont celles qui décrivent les utilisateurs et leurs privilèges.

 Utilisateurs internes, utilisateurs externes

Le marché des SGBD

Le langage SQL - Principes

• SQL est le langage permettant à une application cliente de demander

 manipulation de données (DML)

 contrôle des données (contrôle d'accès, etc.)

Le langage SQL - SQL/DDL (Data Definition Language)

create table CLIENT ( les valeurs de la colonne NCLI

COMPTE decimal(8,2) not null, la colonne NCLI est un

create table COMMANDE (

Le langage SQL - SQL/DDL (Data Definition Language)

alter table COMMANDE on demande d'ajouter une

create view CLIENT_TOULOUSE (NUM, NOM, ADRESSE, CATEGORIE)

Le langage SQL - SQL/DDL (Data Definition Language)

create procedure MODIFIER_CLIENT (in N char(4), LOC char(30))

create trigger MAJ_CLI

Le langage SQL - SQL/DML (Data Manipulation Language)

• Ensemble des instructions permettant de manipuler les données,

• Comporte quatre instructions

 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,

select NCLI, NOM from CLIENT

Le langage SQL - SQL/DML (extraction de données)

select NCLI, NOM, ADRESSE from CLIENT

Ces conditions triviales, en apparence sans intérêt, intéresseront

Le langage SQL - SQL/DML (extraction de données)

from CLIENT des lignes de la table CLIENT ...

where LOCALITE = 'Toulouse'; dont LOCALITE a la valeur 'Toulouse' ...

on extrait des données ...

select NOM, LOCALITE from CLIENT

Le langage SQL - SQL/DML (modification de données)

on demande de modifier, dans la table

on demande de supprimer de la table

where NCLI = 'C400'; ... dont NCLI = 'C400'

Le langage SQL (commentaire)

-- Instructions de chargement des données