2006-06-05

TLS pour sécuriser des transactions Web

(TLS) Transport Layer Security (anciennement SSL (Secure Socket Layer)) est une technologie éprouvée permettant de sécuriser les protocles internet. Elle est aujourd'hui utilisée dans le domaine du Web où les données échangées sont sensibles.

L'intégration de TLS à une application existante est facile car TLS se place sous le protocole HTTP. Il n'y a donc pas besoin de changer grand chose au niveau d'une application Web. Une activation du service sur le serveur et le tour est joué. De la sécurité facile et à moindre coût.

Toutefois, comme toute technologie de cryptographie, il faut l'utiliser correctement pour qu'elle soit efficace. En cherchant un peu sur la toile on peut trouver des entreprises respectables qui ont une utilisation étrange de la technologie.

Une erreur courante est de commencer la session TLS après la phase d'authentification utilisateur. Cette pratique annule presque complétement l'interêt d'une session sécurisée. Effectivement. une fois la session démarrée, on ne peut pas savoir ce que fait l'utilisateur. Mais cela a peu d'importance puisque les informations les plus sensibles : Son mot de passe et son nom d'utilisateur, passent en clair sur internet.

Schéma TLS

Le schéma montre dans le premier cas l'architecture correcte et dans le deuxième cas l'architecture non sécurisée utilisée par l'entreprise en question.

Un simple navigateur permet de dire si une page est sécurisé via un icône ou le préfixe protocole "https". Par conséquent, pour un oeil averti, il est possible de détecter ce genre d'erreurs simplement en surfant sur un site. J'en ai trouvé une qui se présente sous forme d'une authentification HTTP. Pour être certain que ma trouvaille était bien une erreur, j'ai utilisé Ethereal et j'ai constaté que le nom d'utilisateur et le mot de passe circulent bien en clair sur le réseau :

Screenshot Ethereal

Je n'ai pas pu vérifier les implications de ce problème car je ne sais pas ce que l'on peut faire sur le compte utilisateur.

Udapte du 19 novembre 2006 : un amis m'a informé qu'il est possible de tout faire avec le nom de l'utilisateur et ce mot de passe. Ce qui m'a aussi fait rigoler c'est un article paru dernièrement dans la presse gratuite qui annonce l'explosion du chiffre d'affaire de cette entreprise IT. Ce qui est sûr, ce que je vais réfléchir à deux fois avant d'utiliser leur service. À ce jour la faille de sécurité est toujours visible dans leur système d'authentification.

L'entreprise contactée par email nie pour l'instant l'existance du problème, ce qui est assez inquiétant connaissant son domaine d'activité (Le banking en ligne).

2006-06-02

Architectures MVC et 3-Tier

Les noms d'architectures MVC et 3-Tier sont très couramment utilisés dans les cours de génie logiciel. Il est facile de s'emmêler les pinceaux car ces deux pratiques sont à la fois différentes et similaires.

L'architecture MVC

Model View Controller (Modèle Vue Contrôleur) est souvent décrit comme un simple design pattern (motif de conception) mais c'est plus un architectural pattern (motif d'architecture) qui donne le ton à la forme générale d'une solution logiciel plutôt qu'à une partie restreinte.

Les trois parties du pattern MVC sont les suivantes :

  1. Model : Le modèle défini les données de l'application et les méthodes d'accès. Tout les traitements sont effectués dans cette couche.
  2. View : La vue prend les informations en provenance du modèle et les présente à l'utilisateur.
  3. Controller : Le contrôleur répond aux événements de l'utilisateur et commande les actions sur le modèle. Cela peut entrainer une mise à jour de la vue.

L'architecture 3-Tier

L'architecture 3-Tier sépare, tout comme MVC, l'application en trois parties bien distinctes :

  1. User interface : La partie présentation de l'application.
  2. Buisness logic : La couche métier qui s'occupe du traitement de l'information.
  3. Data access : La partie accès et stockage des données

Architecture MVC ou 3-Tier ?

La différence fondamentale se trouve dans le fait que l'architecture 3-Tier sépare la couche Buisness logic (couche métier) de la couche Data access (accès aux données).

Pour qu'une application MVC soit une vraie application 3-Tier il faut lui ajouter une couche d'abstraction d'accès aux données de type DAO (Data Access Object).

Inversement pour qu'une application 3-Tier respecte MVC il faut lui ajouter une couche de contrôle entre User interface et Buisness logic.

Loin d'être antagonistes, ces deux pratiques se combinent et sont la fondation de la plupart des frameworks de création d'applications Web.

Peut-on parler alors de MVCDAO ou d'architecture 4-Tier ?