Un point sur le projet ZEP 12

Je m’étais promis de faire avant le premier avril un petit point sur l’avancement de la ZEP12.

Pour ceux qui ne savent pas ce qu’est une ZEP, voire qui ne connaissent pas zeste de savoir, je vous prie d’aller ici et .

Les ZEP sont souvent de très gros projets qui visent à améliorer le site d’une manière drastique ! Aujourd’hui, deux ZEP ont été menée à leur fin, la ZEP 03 qui permet aux auteurs de demander de l’aide pour améliorer leurs tutoriels et la ZEP 17 qui permet de mettre en place une API REST pour accéder aux informations publiques des membres. Elle permet aussi de gérer toujours en REST votre compte grâce à OAuth 2. Le but est bien évidemment de permettre à des applications tierces de profiter des données de zds, à terme il y aura tout (ZEP 02) mais on a commencé par les membres.

C’est super important car cela montre qu’il y a une vraie dynamique dans le développement (open source) de zds.

Continue reading

Premier article publié sur zeste de savoir (et autres retours d’expérience)

Vous vous souvenez, il y a quelques mois, je vous parlais de zeste de savoir. Un site édité par une association loi 1901 qui a pour but de partager gratuitement la connaissance sur le web.

Je reviendrait un peu plus loin sur cette expérience passionnante qu’est le développement de zeste de savoir. Je voudrais cependant commencer par une autre bonne nouvelle : je viens enfin de publier mon premier contenu rédactionnel sur zeste de savoir !

Le contenu, le nerf de la guerre

Je suis développeur, mais il faut que l’outil que l’équipe développe soit utilisé, pour cela, il faut que nous ayons des auteurs, pour cela il faut que nous ayons des visiteurs qui liront les contenus, pour cela il faut que nous ayons du contenu et donc des auteurs…

C’est dans cette optique que j’ai donc baissé légèrement ma participation au développement (bien que la QA et la ZEP 12 me prennent beaucoup de temps) pour créer du contenu. Sous conseil de firm1, avec l’aide de Blue Shark, j’ai donc coécris un article à propos de la mise en open source du coeur du framework .NET ! Parce que, oui, Microsoft met .NET sous licence MIT, c’est beau non? Et première bonne nouvelle : cet article est publié aujourd’hui ! Bonne lecture ^^

Continue reading

Zeste de savoir : un projet opensource pour la beauté du zeste

J’ai enfin trouvé un chez moi dans le monde de l’open source.p

Même si j’ai envie de me retirer petit à petit du développement web, c’est pourtant vers publicsur un projet de site que je compte apporter ma pierre à l’édifice. Ce projet, c’est http://zestedesavoir.com.

mascotte zds

Clem’ la mascotte de zeste de savoir

Ce projet exploite la stack technologique python/django, mysqli, nginx pour le back, et SCSS, JS, Twig pour le front.

L’histoire du projet est simple : le site du zéro, géré par la société Simple IT, devenus tous les deux (le site et la société) OpenClassrooms, l’équipe dirigeante de OC a décidé un virage total en ce qui concerne la communauté de base. Aujourd’hui, la communauté historique est un poids pour le site, la volonté de partager gratuitement des connaissances ou des savoir faire n’est plus à l’ordre du jour, comme le dit une de leur éditrice “si c’est gratuit c’est vous le produit”.

Alors les anciens modérateurs, validateurs, auteurs ont commencé à réfléchir à des nouveaux projets de sites.

Dans une volonté de rassembler une communauté autodidacte à un niveau assez sérieux et qui s’oriente surtout vers l’embarqué, plusieurs d’entre eux ont créé progdupeupl.

Pendant ce temps, firm1, nohar et d’autres (comme mon ami nordiste ShigeruM) ont démarré un projet qui a la même cible que le site du zéro : les débutants.

Et comme on ne refait pas l’Histoire, il était normal que SDZ devienne… ZDS. Vient alors le nom “zeste de savoir”.

Comme progdupeupl offrait une base technique fiable, l’équipe a décidé de forker ce dernier depuis son dépot bitbucket. Et c’est le début d’une belle aventure qui se formalisera le 19 avril 2014 par un parution au journal officiel des status de l’association zestedesavoir.

Personnellement, j’arrive à cette époque comme beta testeur sur leur premier test privé. Le projet me plait, je propose mes services. Quelques semaines plus tard, le code est ouvert au public, ma première pull request peut être envoyée.

Depuis, je me concentre sur le backend, n’étant pas particulièrement doué pour l’intégration front.

Ma petite fierté, est le débuggage complet du système de tag qui permet une meilleur sémantique sur les forums de zds. Travailler sur ce système m’a permis d’en apprendre plus à propos de Solr, un moteur de recherche ultra puissant dont la seul faiblesse est qu’il est en Java et développé par la fondation Apache (documentation, tout ça…)

Ce que je désirerai faire pour le projet?

  • Créer quelques méthodes d’API en lecture pour faciliter la navigation au sein du système de tag lorsqu’on est sur mobile;
  • Ajouter la possibilité pour un membre d’envoyer une correction orthographique qui se présenterait à l’auteur comme une Pull Request
  • Une appli winphone 8.1 voire carrément une appli universelle

Sécuriser une API avec HMAC

En plein développement du projet que je présenterai avec le Cii à l’ImagineCup, nous devons exposer une API à nos clients mobiles et desktop. En effet, à l’heure actuelle, un site internet ça ne suffit plus pour accompagner un client dans ses achats, et c’est ce que nous voulons faire. Certes, nous avons un site web, respectant les règles du Responsive Design, mais nous voulons utiliser au maximum les outils mis à disposition par Windows 8.1 pour accompagner la recherche pré-achat (contrats de partage, accès hors ligne, puissance de calcul déportée en local…) et les possibilités des smartphones actuels (localisation, notifications, hub social, capteur photo, accessibilité au touché…).

Nous exposons donc une API à notre public : nos partenaires comme les clients. Certaines données sont ouvertes car elles peuvent être obtenues de manière ouverte chez d’autres fournisseurs. Par contre il faut pouvoir authentifier nos clients…

L’authentification, c’est un peu plus complexe que prévu quand on parle d’API. Utiliser un jeton de session, c’est s’assurer ce qu’on appelle une « side attack », autrement dit, quelqu’un qui sniff le réseau en attente du cookie de session, le prend et se fait passer pour nous avec ce cookie. Comme il nous est impossible d’utiliser de jeton CSRF avec une API, ça complique tout.

Deux grandes solutions s’offrent à nous :

  • Implémenter OAuth 2.0
  • Utiliser une authentification par HMAC

OAuth2.0 c’est bien, mais ça a un coût : il faut un fournisseur d’identité complet et surtout c’est plus lent. Notre choix est donc d’utiliser HMAC.

Le fonctionnement

 

Le but est ici de transmettre au serveur de manière totalement chiffré un couple clef publique/clef privée. Le chiffrement se fait par la méthode HMAC.

Figure 1Formulation de HMAC

h est ici la fonction de hashage (SHA-1, SHA-256…), K est la clé privée, m est dans notre cas la clef publique ainsi que d’autres informations utiles pour sécuriser l’envoie. Opad et ipad sont des constantes internes à la fonction HMAC.

La clef privée est une chaîne de caractère aléatoire qui est connue du client et du serveur seuls. Cette clef ne doit pas être envoyée sur le réseau sauf à envisager un échange plus complexe de type zero knowledge.

La clef publique est une clef qui est utilisée pour déterminer la personne qui demande l’authentification. Elle ne permet pas de l’authentifier en soit.

  1. Côté client : On calcule le Hashmac(clef privée, clef publique). HASHMACSHA256 ou HASHMACSHA512 sont conseillés.
  2. Côté client : On insère la clef publique et le hashmac dans l’url sous forme de paramètre GET ou bien on glisse ça dans une entête http étendue.
  3. Côté client : On insère les données demandées par le programme.
  4. Côté serveur : On récupère la clef publique et on regarde si elle correspond à un utilisateur et que cet utilisateur a le droit d’accéder aux données. Sinon 401 :UnAuthorized
  5. Côté serveur : On calcule le Hashmac(clef privée, clef publique) avec le même algorithme que le client. On compare le hashmac fournie par le client et celle calculée. Si elles ne sont pas identiques => 401 Unauthorized
  6. Côté serveur : On exécute la requête envoyée et on renvoie les données, si possible de manière cryptées.

Le problème réside donc dans la clef privée : comment la rendre privée ?

Dans le cas de Amazon, c’est assez simple, quand on inscrit un compte développeur, ils nous donne cette clef et nous disent de ne pas la compromettre. Mais dans le cas d’une application mobile ?

On ne peut pas demander à nos utilisateur d’entrer une suite indescriptible de chiffres et de lettres par pure plaisir, non ?

Et puis comment on gère le fait qu’il y a une clef privée par personne ? Impossible.

Un moyen est simplement de compiler la clef privée avec l’application et de la changer régulièrement, à chaque mise à jour de l’application par exemple. C’est relativement sécurisé mais ça n’empêchera pas les utilisateurs dont le téléphone est rooté de tenter de décompiler le programme et d’en extraire la clef privée et la manière dont vous hashez le tout.

A partir d’un moment il semble donc que OAuth soit nécessaire mais pour la plupart des utilisations, HMAC semble être un très bon compromis entre facilité de développement, sécurité, et rapidité d’exécution.

 

Les failles qu’il faut combler

 

Les attaque par « replay »

 

Ces attaques se servent d’une fonctionnalité qui est souvent souhaitable pour les API destinées à la mobilité : la possibilité de retenter la requête plusieurs fois.

L’attaquant observe le réseau et prend votre signature ainsi que la clef publique puis lance une flopée de requêtes qui ne sont pas celles que vous désiriez lancer. Quand l’utilisateur a un accès restreint, ça va, mais quand c’est un utilisateur à haut niveau de privilège, je vous laisse imaginer le désastre.

La première idée sera donc marquer temporellement la clef publique pour que sa validité ne soit bonne que durant un temps donné, une, deux, dix minutes par exemple.

Les attaques par replay sont toujours possibles, mais elles offrent moins de temps.

Une seconde idée est de fournir dans la clef publique un jeton unique qui identifiera la requête. Cet identifiant est simplement un compteur de requêtes.

Lorsque vous envoyez votre requête, vous incluez le jeton dans la clef publique et l’incrémentez aussi bien côté client que côté serveur. Lorsque l’attaquant voudra récupérer la hashmac de la première requête celle-ci ne sera plus valide. En effet si le serveur a renvoyé une réponse à cette requête alors il s’attend au jeton suivant et non plus à celui qui a permis de générer la signature usurpée.

Les attaques par changement de méthode.

 

Dans le cas d’un homme dans le milieu, ce dernier tentera d’utiliser l’authentification de l’utilisateur pour envoyer un POST/DELETE/PUT alors que la requête de départ est un GET par exemple. Cela peut générer des gros problèmes, surtout quand, par exemple, le routeur de ASP.NET MVC se base sur les méthodes pour désigner quelle action exécutée.

La parade est ici très simple : on inclut la méthode dans la signature. Ainsi si l’attaquant usurpe votre signature, il ne peut pas usurper votre demande.

L’URI de base doit être, dans ce modèle elle aussi ajoutée à la signature.

 

Et bien d’autres encore… Il est aussi toujours nécessaire d’utiliser une connexion HTTPS pour transmettre les données de manière cryptée !