Pascal MESSAGER (freelance)

Lorsque l'on crée une sauvegarde il est capital de se poser la question de la restauration. En particulier : "Dans quel cas de figure est-on amené à faire une restauration, et qu'est-ce que ça règle comme problème ?"

Dans l'imagerie d'Epinal des informaticiens, le risque de perte de données est symbolisé par la perte du disque dur. Vieille réminiscence d'un temps où les coûteux disques de quelques Méga octets avaient une fiabilité douteuse.

Or ce n'est plus le cas aujourd'hui. Les disques approchent le Tera octets avec une fiabilité remarquable, et pour un prix suffisament faible pour qu'on puisse les dupliquer (mirroring, RAID...)

En réalité, la perte physique du disque contenant les dnnées est aujourd'hui un scénario presque négligeable. Mais d'autres événements ont pris le relais. Dont l'erreur humaine qui n'est pas le moindre.

Voici une petite liste non exhaustive de scénarios de 'perte' de données, ou d'appel à une restauration :

Matériel
Disque défectueux	Perte physique du disque contenant sql server.
Disque défectueux	Perte physique du disque contenant des bases de données.
Electronique serveur	Machine physique défectueuse.
Site	Incendie ou destruction totale de la salle serveur.
SQL
Corruption base	Fichiers de la base physiquement corrompus.
Perte login	Perte de droits d’accès, admin ou utilisateur.
Erreur humaine
Bug applicatif	Découverte d’un bug après mise en prod qui affecte la cohérence des données.
Opération inopinée	Destruction involontaire de données (delete sauvage…)
Malveillance	Modification volontaire des données par un attaquant. Peut remonter loin dans le temps.
Virus	Virus corrompant les données et programmes.
Maintenance
Duplication	Demande de duplication de la base vers une autre machine (de test notamment)
Retour version	Annulation d’une mise à jour logicielle qui s’avère défectueuse.
Déplacement	Changement de machine physique supportant le serveur sql.
Mode dégradé
Coupure électricité	En cas de coupure d’électricité, les onduleurs ont une autonomie très limitée. Or certaines applications sont  plus prioritaires que d'autres.
Performances	Baisse de performances subite.

Il est clair que pour certains scénarios une application bête et méchante de la restauration ne suffit pas. Par exemple (cas le plus difficile) si un virus a lentement corrompu les données. Il faut appliquer alors une stratégie adaptée.

La préparation de ces scénarios et la mise en en place de procédures semi-automatiques de restauration facilite et accélère le travail de reprise.

C'est un classique. Dans les dix premières leçons de l'apprenti-pirate pré-adolescent. Pour pirater un site web, il suffit de taper ces deux mots "injection sql" dans Google, et il nous tombe 500 000 hits. 500 000 modes d'emploi de hack. Et ça marche !

Parce que c'est simple. Simple à pleurer. Il suffit de connaître un caractère présent sur le clavier. Un tout petit, à peine quelques pixels à l'écran. Mais il ouvre la porte de quantité de sites web aussi peu protégés qu'un vieux moulin abandonné en Haute-Provence, dans lequel entrent et sortent des nuées de cigales stridulentes.

Une vulgaire apostrophe. Située sous le chiffre 4 d'un clavier AZERTY. Voilà la clé magique qui menace la sécurité de votre serveur de bases de données.

Vous ne me croyez pas ? Vous avez tort. C'est simple à pleurer vous dis-je.

Travaux Pratiques

Oncques estoit votre beau site web, chargé de tous vos espoirs de richesse e-commerciale. Evidemment, vous prévoyâtes à l'endroit de vos estimés clients zé partenaires, un accès privilégié. Privilèges abolis un Quatre-Août pour les naïfs, soit dit en passant.

Pour accéder à ce club de nantis, les susdits se doivent de décliner leur identité. Le programmeur que vous chargeâtes de cette vile tâche étant fainéant par nature, il copicolla le code html d'un site concurrent et proposa deux minuscules zones de saisie. L'une baptisée "Login" et l'autre "Password", à moins qu'il ne s'astreignit à la francisation.

L'internaute honnête et cynophile saisira donc son sésame. Par exemple
Login = dupond
Password = medor
Et la chevillette cherra.

Mais supposons notre internaute, privilégié disions-nous donc non concerné par le Quatre-Août, être de cette noble engeance aristocratique et disposer d'une particule en son nom (et vaguement irlandais de plus).

Login = O'Neil d'Estrées d'Harcourt
Password = n'importe nawak

Hélas, ô rage, ô désespoir, s'abat alors le couperet fatal du bug et, au lieu d'afficher la page web due à son rang, voici qu'apparait une absconse insulte :


Perdu ! Votre site a cédé sous les coups de butoir de l'apostrophe scélérate et révélé sa vulnérabilité. Le pirate y est désormais comme chez lui.

Que c'est-il passé ?
L'apostrophe est chez SQL, le langage d'accès à la base de données, le délimiteur de chaine de caractères. Le programmeur a construit la requête autour du login, sans envisager le cas de l'apostrophe présente. Résultat, tout ce qui est après cette apostrophe est interprété par SQL comme du code exécutable. Dans l'exemple ci-dessus "Neil d" provoque une erreur de syntaxe d'où le message peu amène.

Mais si au lieu d'une instruction erronée après l'apostrophe, l'internaute saisit une instruction SQL valide ?

Login = ' or 1=1 --
Password = onsenfout

Je vous passe les détails techniques, mais la saisie ci-dessus suffit à tromper le contrôle de sécurité et donner accès à la page web protégée. Mais on peut faire bien pire et pénétrer le système entier.

Allons ! Est-ce vraiment une menace sérieuse ?
Oui, hélas. Pour avoir fait des petits essais, un site web sur dix est ainsi vulnérable. Y-compris des sites très prestigieux dans le secteur de la haute finance !

Faites le test sur votre site web. Insérez une petite apostrophe, une toute petite. Si ça plante, vous serez bientôt visité par un horrible bot aux intentions mafieuses venu du tréfond du Balozhikstan...