> Data > La chute des cookies ?

La chute des cookies ?

Data - Par Susan Perschke - Publié le 24 juin 2010

La gestion des sessions utilisateur sur plusieurs fermes Web et plateformes demeure l’un des défis suprêmes du développement de sites Web à haute disponibilité. Comme l’explique l’article « Une recette pour remplacer les variables de session » (Club Abonnés, SQL Server Magazine décembre 2006), l’utilisation conjointe des cookies, des procédures stockées SQL Server, d’un générateur de GUID et de paramètres d’URL. Certains développeurs évitent les paramètres d’URL car ils sont transmis de manière visible d’une page à l’autre. Ils leur préfèrent le passage de valeurs au moyen de champs masqués. Dans les deux cas, les résultats ne sont pas sécurisés. Par conséquent, les valeurs passées d’une page à l’autre doivent être les plus obscures possibles.

Le passage de toute information présente un risque potentiel pour la sécurité. J’aime utiliser les GUID car ils ne révèlent pas réellement d’informations utiles pour les pirates potentiels et permettent malgré toute la persistance de la session pendant tout le temps nécessaire. Le présent article va aborder les techniques que j’emploie pour créer un gestionnaire de sessions sans cookies basé sur SQL Server. Il présente également le fonctionnement du gestionnaire de sessions et différentes manières de l’employer.

Etape 1 : Création du générateur de GUID dans SQL Server
Pour les besoins de cet exemple, j’utilise le générateur de GUID intégré livré avec SQL Server. Il s’agit d’un simple appel de fonction, intitulé newid(). Gardez à l’esprit que l’unicité est garantie uniquement sur la machine hôte. Toutefois, comme j’effectue la configuration afin qu’un serveur de base de données gère les sessions, cette approche convient parfaitement à mon application. Je commence par écrire une procédure stockée simple qui génère un nouveau GUID, comme l’illustre le listing 1. Il est logique de recourir à des GUID.

Il s’agit en effet de valeurs uniques, non séquentielles, lesquelles n’ont aucune signification pour les utilisateurs, mais peuvent être suivies dans la base de données, au même titre que n’importe quel ID utilisateur. Pour des raisons de simplicité, cet exemple utilise les 12 caractères le plus à droite de la sortie à 36 caractères de la fonction newid(). Si votre site est extrêmement actif, vous souhaiterez probablement employer la valeur entière, mais n’oubliez pas qu’il faut plus de temps pour indexer les valeurs longues. Une valeur plus courte améliore les performances de l’indexation, mais peut ne pas fournir un degré d’unicité suffisant pour votre application.

Etape 2 : Test du générateur de GUID
Pour tester la procédure stockée, j’utilise une page ASP (Active Server Page). Le listing 2 présente le code de test écrit en VBScript de cette page. (Le listing Web 1 affiche une version Visual Basic de ce code à l’adresse http://www.itpro.fr, Club Abonnés). Ce code ouvre la connexion à la base de données SQL, puis exécute la procédure stockée chargée de générer la valeur de GUID servant à suivre l’activité de l’utilisateur.

Dans un navigateur Web, la sortie de cette page aura un aspect du type : 7ED986BFB37C Chaque chargement de la page entraîne la génération d’une nouvelle valeur. La fonction newid() est native à SQL Server et le fait de l’appeler à partir d’une procédure stockée précompilée ajoute peu de traitement par rapport à des sessions de variable ASP, lesquelles utilisent beaucoup de mémoire serveur.

Téléchargez cette ressource

Sécurité et conformité du Cloud

Ce guide vous permettra de revisiter vos connaissances et repenser votre posture en matière de sécurité et de conformité dans le cloud. Vous découvrirez comment mettre en place et déployer une stratégie de sécurité fluide et transparente. Un guide essentiel pour sécuriser votre cloud de façon pérenne.

Data - Par Susan Perschke - Publié le 24 juin 2010