Gestionnaire de bases de données

Le monde de l’informatique se divise en deux camps : le camp de l’à-peu-près gratuit et celui du totalement cher. Si vous lisez cet ouvrage, c’est sûrement parce que vous utilisez déjà Apache ou que vous comptez le faire : vous appartenez donc au premier camp. Celui ci offre des logiciels gratuits placés sous un grand nombre de licences (voir plus loin), ainsi qu’un support commercial suivant les cas. Aujourd’hui, tous les SGBD (systèmes de gestion de bases de données) utilisent le modèle relationnel et le langage SQL. Un bon livre sur ce langage est essentiel. La plupart des langages de scripts disposent maintenant d’interfaces plus ou moins standard avec les SGBD les plus connus. Lorsqu’il travaille avec un système de base de données, le programmeur doit souvent choisir entre l’utilisation des fonctions intégrées au SGBD et celle d’un langage : MySQL, par exemple, dispose de fonctions puissantes permettant le formatage des dates, qui renvoient une date et une heure présentées selon votre goût ; on pourrait obtenir la même chose en Perl, mais cela demanderait plus de travail. Par conséquent, cela vaut la peine d’explorer le langage de programmation intégré d’un SGBD.

Les SGBD suivants sont des logiciels gratuits qui méritent attention :

Serveur de courrier

La plupart des sites web ont besoin d’un serveur de courrier pour communiquer avec leurs clients et avec les membres de leur société.

Le programme Sendmail d’Unix ( http://www.sendmail.org ) est ancien et complet (plutôt énorme, même). Il a la réputation d’avoir des failles de sécurité, mais elles semblent avoir été corrigées et, ces dernières années, il y a eu peu d’attaques recensées contre lui. À titre indicatif, l’ouvrage d’O’Reilly qui lui est consacré est l’un des plus épais de la collection. Sendmail a trois jeunes concurrents :

PGP

Le courrier commercial devrait être chiffré car il peut contenir des détails confidentiels sur vos affaires ou sur vos clients. Dans les deux cas, il est souhaitable que ces informations soient tenues secrètes.

PGP ou Pretty Good Privacy ( http://www.pgpi.org/ ) est la solution évidente, mais il utilise l’algorithme IDEA, est protégé par des brevets et n’est pas totalement libre. GnuPG, lui, n’utilise pas IDEA et est libre ( http://www.gnupg.org/ ). PGP est un excellent logiciel, mais il a un problème lorsqu’il est utilisé de façon interactive. Il tente de s’installer comme plug-in de votre navigateur et se propose de chiffrer vos courriers au vol, mais nous avons constaté que cela ne fonctionne pas toujours, ce qui fait que vos plus sombres projets sont envoyés en clair. Il est bien plus sûr d’écrire un courrier de la façon habituelle, de le copier dans le bloc-notes, d’utiliser PGP pour chiffrer le bloc-notes et de copier celui-ci dans votre courrier.

Accès au serveur par SSH

Votre site web de production sera sûrement sur une machine trop éloignée pour que vous puissiez la contrôler directement. Vous pouvez vous y connecter à distance par telnet puis lancer un émulateur de terminal sur votre machine, mais vous devrez taper le fameux mot de passe root pour avoir le contrôle du serveur distant. Avec telnet, le mot de passe circulera en clair sur le web, ce qui n’est pas souhaitable.

Vous devez donc y accéder par un shell sécurisé afin que tout votre trafic sur le web soit chiffré. Non seulement vos mots de passe seront protégés, mais également, par exemple, une nouvelle version de la base de données de vos clients (avec leurs numéros de carte de crédit et les détails de leurs comptes) que vous téléchargeriez sur le serveur. Les sales types aimeraient l’intercepter, mais ils n’y arriveront pas.

Pour ce faire, vous avez besoin de deux logiciels :

1. SSH ( Secure SHell ), librement disponible sur www.openssh.org, ou payant sur http://www.ssh.com.
2. Un émulateur de terminal qui créera un tunnel SSH vers la machine cible et vous permettra d’être dans la même situation que si vous étiez devant la machine cible. Si vous utilisez Win32, Mindterm ( www.mindbright.se ) fonctionne correctement, bien qu’il soit écrit en Java et qu’il nécessite donc d’installer le JDK. Lorsque nous l’avons essayé, notre version a produit des messages d’erreurs alarmants, mais qui ne l’ont pas empêché de fonctionner. Une bonne alternative est Putty ( http://www.chiark.greenend.org.uk/~sgtatham/putty ). Si vous utilisez Unix, vous n’avez rien de plus à faire puisque vous avez déjà accès à un terminal.

Cartes de crédit

Le but du commerce consiste à soutirer l’argent des clients (de la façon la plus douce qui soit) et le point où doit se concentrer notre attaque est la carte de crédit. C’est le robinet par lequel s’écoule la richesse, mais elle peut également vous servir un breuvage empoisonné. Dès que vous gérez des numéros de cartes de crédit, vous êtes susceptible de rencontrer des problèmes : la fraude est importante et le commerçant finit par la payer. Lisez, par exemple, ce triste avis sur http://antifraud.com/tips.htm. Inversement, vous ne pouvez pas faire grand chose pour empêcher les employés qui ont accès aux numéros de carte de les noter puis de faire leurs courses à vil prix. Une personne mieux organisée peut même vous causer des tracas encore plus importants.

À moins que vous ne soyez une grosse société assurée et que vous ayez un département compétent chargé de la sécurité, vous utiliserez sûrement une société intermédiaire qui gèrera les transactions par carte de crédit et vous enverra l’argent. http://www.virtualschool.edu/mon/ElectronicProperty/klamond/credit_card.htm présente un survol intéressant de tout ce processus compliqué.

Il existe un certain nombre d’intermédiaires. Les interfaces avec votre site dépendront des sociétés, ainsi que les coûts et le pourcentage prélevé pour chaque transaction. Il est également très important de lire le petit alinéa sur la fraude des clients : qui paiera ?

Nous avons utilisé WorldPay -- une société anglaise internationale, filiale de HSBC, l’une des plus grosses banques anglaises. WorldPay offre un certain nombre de produits, dont des systèmes de commerce complets ainsi que la possibilité d’accepter les paiements dans toutes les monnaies pour les convertir dans la vôtre au taux en vigueur. Nous avons utilisé leur produit d’entrée de gamme, Select Junior, qui dispose d’une interface assez ingénieuse. C’est elle que allons décrire ici pour illustrer notre propos, mais d’autres intermédiaires proposeraient sûrement d’autres méthodes.

Vous avez réussi à persuader votre client d’acheter et vous lui présentez alors un formulaire HTML contenant une ligne comme celle-ci :

Nous allons maintenant débiter votre carte de crédit de 50,75 euros.

Ce formulaire comporte également un certain nombre de champs cachés contenant votre identifiant WorldPay, l’identifiant de la transaction associé à cet achat, sa description, le montant et la monnaie utilisée. Lorsque le client clique sur le bouton de validation, le formulaire appelle le site d’achat sécurisé de WorldPay qui gère ensuite les détails concernant la carte de crédit sur leur propre page web. Celle-ci est intégrée dans une page que vous aurez conçue et pré-chargée sur leur site, ce qui vous permet de conserver une continuité d’aspect par rapport aux autres pages de votre site. Le résultat combine votre page avec les leurs.

Lorsque le dialogue concernant la carte de crédit du client est terminé, WorldPay affiche l’une des deux pages que vous avez pré-chargées : la première sera choisie pour une transaction réussie, remerciera le client et le ramènera à votre site ; la seconde apparaîtra en cas d’échec de la transaction, exprimera vos regrets et le renverra vers la page de votre concurrent direct. Puis, WorldPay vous envoie un courrier électronique et/ou appelle une URL sur votre site pour vous communiquer les détails de la transaction. Ce lien appelle un script qui effectue toutes les opérations nécessaires pour achever la transaction. Son écriture est un peu spéciale car il ne fait rien de visible dans le navigateur ; vous devez faire en sorte que les messages de débogage soient stockés dans un fichier.

Vous avez également intérêt à vérifier que la somme que l’intermédiaire a débité au client correspond au montant de son achat car le processus de paiement a pu être perturbé par un pirate ou, tout simplement, s’être mal passé.

Mots de passe

Un mot de passe n’est utile que s’il y a un humain qui s’en rappelle et qui le saisit. Ils ne sont pas utilisés entre les processus qui s’exécutent sur le serveur. Les scripts qui utilisent le gestionnaire de bases de données, par exemple, devront souvent fournir un mot de passe mais, comme celui-ci doit se trouver dans le script, cela signifie que toute personne ayant accès au serveur pourra le lire et qu’il ne sert à rien pour ceux qui n’ont pas cet accès : on ne peut donc pas dire qu’il améliore la sécurité.

Cependant, comme nous l’avons déjà indiqué, les services devraient avoir des droits d’accès minimaux et tourner sous des comptes différents : il faudra donc mettre en place un accès SSH avec les clés chiffrées associées pour effectuer des mises à jour ou des opérations de maintenance.

Désactivation des services inutiles

Vous ne devez pas lancer plus de services Unix qu’il n’est nécessaire. La commande ps vous indiquera quels sont les programmes qui s’exécutent sur votre machine et, si elle est installée, sockstat recherchera les services qui utilisent des sockets et sont donc vulnérables aux attaques venant de l’extérieur via TCP/IP. Cette commande produit un affichage comme celui-ci :

USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS

root mysqld 157 4 tcp4 127.0.0.1.3306 *.*

root sshd1 135 3 tcp4 *.22 *.*

root inetd 100 4 tcp4 *.21 *.*

qui indique ici que MySQL, SSH et inet s’exécutent.

L’utilitaire lsof est plus cryptique mais il est disponible sur un plus grand nombre de plateformes ; il montre les fichiers et les sockets ouverts, ainsi que les processus qui les utilisent. Vous le trouverez sur ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/.

Il est conseillé de restreindre les services pour qu’ils n’écoutent que sur l’interface appropriée. Si, par exemple, vous faites tourner un gestionnaire de bases de données, vous pouvez faire en sorte qu’il n’écoute que sur localhost afin que seul un CGI puisse communiquer avec lui. Si vous avez deux réseaux (un réseau local et Internet), vous pouvez choisir celui qui sera utilisé pour tel ou tel service.

Réseaux internes

Les services internes -- ceux qui ne sont pas exposés sur l’Internet : un gestionnaire de bases de données, par exemple -- doivent avoir leur propre réseau. Vous devez partitionner le plus possible vos machines/réseaux pour que les attaquants soient obligés de passer par vos barrières internes.

SuEXEC

S’il y a des utilisateurs internes à votre système en qui vous n’avez pas confiance (des étudiants sur le réseau de l’Université, qui ont le droit de créer leurs propres sites web virtuels, par exemple), utilisez suexec pour être sûr qu’ils n’abuseront pas des droits d’accès qu’ils obtiennent via Apache.

SSL

Lorsque vos clients doivent communiquer avec vous de façon confidentielle -- et vice versa -- vous devez utiliser Apache SSL (voir le chapitre 11) mais, comme cela a un coût en termes de performances, n’abusez pas de cette fonctionnalité. Un lien à partir d’une page non sécurisée invoque SSL en appelant simplement https://<page_sécurisée>. Utilisez une autorité de certification connue, ou les clients recevront des avertissements pouvant altérer leur confiance en vous. Vous devez lancer une page SSL assez tôt, afin que le client constate que le verrou de son navigateur est fermé avant que vous ne lui demandiez son numéro de carte de crédit.

Vous pouvez également utiliser SSL pour accéder aux pages de maintenance (voir plus haut).

Certificats

Reportez-vous au chapitre 11 consacré à SSL.