La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.
Agilité
Web
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
- Nous étions au premier évènement du Paris Cassandra Meetup (Par Pierre-Jean Vardanéga)
- Mercredi dernier le PAUG (prononcer pog) nous proposait une soirée inédite et rare sur le thème de la sécurité sous Android. (Par Dahlia Scherr)
Intégration de la sécurité dans les projets agiles
(Par Audrey Pedro)
La sécurité est de plus en plus présente sur les projets Studio. Ayant dans une ancienne vie travaillé au plus proche de la sécurité, j’ai également remarqué à quel point les RSSIs et autres garants de la sécurité sont perdus face aux méthodes agiles. J’ai donc profité de ma formation de Product Owner pour me renseigner sur le sujet.
La sécurité fait partie de la grande famille des Non Functionnal Requirements (NFR) qui peuvent principalement être traités de deux manières différentes :
- le requirement entre dans la définition du Done, il faut alors s’assurer que les tests sont faits en conséquence. Si la sécurité est vraiment critique sur le projet, les tests de sécurité peuvent même devenir une étape entre le développement et le Done afin de les rendre visibles ;
- le requirement devient une contrainte transverse, affichée de manière très visible pour l’ensemble de l’équipe. Ici aussi, les tests doivent être faits en conséquence.
Voici un lien vers quelques informations sur les NFRs.
Web
HTML5 et OAuth : la saison des chaises musicales
(Par Philippe Antoine)
En avril, Ian Hickson, jusqu’ici seul rédacteur de la spécification W3C HTML5, avait annoncé qu’il laisserait sa place pour se concentrer sur la rédaction de HTML Living standard au sein du Web Hypertext Application Technology Working Group (WHATWG). C’est maintenant chose faite. Dernière étape avant la finalisation de ce fork: la duplication des bugs restants HTML5 dans le workflow du WHATWG. Le WHATWG adopte pour l’occasion le système de fonctionnement du W3C et accepte désormais toutes les propositions extérieures. Le W3C s’occupera de réaliser une snapshot de HTML Living Standard pour le standardiser et lui faire franchir toutes les étapes juridiques nécessaires.
Ce désengagement du W3C de la part de Ian Hickson fait écho à l’annonce récente d’Eran Hammer, qui se retire de la liste des rédacteurs de la spécification OAuth 2.0. Eran, après avoir été l’un des acteurs principaux de la standardisation OAuth (utilisée par Twitter, Facebook et Google, entre autre), constate que le processus de standardisation a perdu sa simplicité initiale. Ian Hickson répond à cette désillusion en expliquant avoir vécu le même type de difficulté au moment de la standardisation des websockets.
Il reste à espérer qu’en dehors des contraintes du processus de standardisation, les deux ex-rédacteurs des spécifications les plus mediatisées du Web sauront proposer des améliorations encore plus innovantes. En attendant, Tav Ino/Espian vient déjà de proposer une spécification de ce qui pourrait devenir le futur OAuth 3.0.
Le coin de la technique
TDGotchi : La gamification au service des tests
(Par Julien Smadja)
TDGotchi est un plugin Eclipse démarré il y a plus d’un an. Il revient sur le devant de la scène suite à différents articles publiés ces derniers jours.
Le principe est simple, vous nourrissez un petit personnage à chaque exécution de vos tests unitaires. Ce Tamagotchi-like peut se trouver dans différentes conditions : Zombie, Beginner, Level 2, etc. Le changement d’humeur de votre compagnon de développement change en fonction des points que vous engrangez :
- lorsqu’un test passe de l’état Fail à Success, vous gagnez un point,
- lorsque vous refactorez du code et que vos tests passent, vous gagnez un point,
- si un test à l’état Success passe à l’état Fail, vous perdez 5 points.
Au-delà de l’aspect ludique de ce plugin, il est intéressant de lire les commentaires de l’article sur Reddit.com. En effet, le terme TDD est parfois mal compris et assimilé à la méthode Tests First qui consiste à écrire toute une batterie de tests avant l’implémentation. En réalité, le TDD est beaucoup plus subtile et préconise l’écriture d’un test à la fois, le plus simple possible et d’écrire le minimum de code pour le faire passer au vert.
TDGotchi est opensource et hébergé sur Github : https://github.com/sbastn/com.happyprog.tdgotchi. Mais, en tant que nouvel utilisateur d’IntelliJ, j’ai hâte qu’un portage soit réalisé !
L’avez-vous déjà essayé ?
Evènements de notre communauté en France et à l’étranger
Nous étions au premier évènement du Paris Cassandra Meetup
(Par Pierre-Jean Vardanéga)
Mercredi dernier (25 Juillet 2012) s’est déroulé au Camping le premier évènement du Paris Cassandra Meetup. Environ 40 à 50 personnes ont assisté à deux conférences durant 3 heures. Ensuite, une collation nous a été offerte par DataStax.
La première session était intitulé Introduction à Cassandra et présentée par Sylvain Lebresne (committer Cassandra chez DataStax). Il nous a décrit le fonctionnement d’un Cluster Cassandra en abordant les notions de noeuds, ring, réplication, token, etc. Ensuite, nous avons vu comment interroger la base de données. Nous avons tout particulièrement insisté sur les consistency levels. C’était une bonne introduction. Pour ceux qui, comme moi, avaient suivi la présentation de Nicolas Romanetti à Devoxx France (ou d’autres présentations), nous n’avons rien appris. En revanche, j’ai pu consolider mes connaissances.
La seconde session était intitulée Firehose storage at Paper.li et présentée par Pierre-Yves Ritschard (leadtech chez Paper.li). Ce fut un retour d’expérience sur la mise en place de Cassandra. Le besoin était de pouvoir contenir une énorme quantité de données : des pics de 15’000 requêtes / seconde et 200 millions d’insertions/mises-à-jour quotidiennes. Aujourd’hui, ils ont un cluster de 40 noeuds et peuvent stocker facilement 100 fois plus de données que dans leur ancienne base MySQL pour un coût d’environ 150&nhsp;% (par rapport à MySQL).
Cette soirée a été filmée, il devrait y avoir une vidéo de disponible sous peu. J’espère que d’autres évènements suivront.
Infos sur le Paris Cassandra Meetup : @pariscassa
Mercredi dernier le PAUG (prononcer pog) nous proposait une soirée inédite et rare sur le thème de la sécurité sous Android.
(Par Dahlia Scherr)
Voici un retour sur ces 2 conférences passionnantes : on y parle de philosophie, des choix des différents systèmes mobiles, de user linux, d’ajout de privilèges à l’insu de l’utilisateur, de chèvres, de chiffrement, de château fort, de SSL.
Une soirée à la fois technique et pointue et en même temps des premières réponses à ceux venus découvrir la sécurité dans la mobilité.
Philippe Prados nous présentait le développement sécurisé sous Android dans une première conférence très riche et complète :
Rappel des différents champs couverts par la sécurité : vol de terminal, exploitation d’une application par une autre, protéger l’utilisateur contre lui-meme, sécurité des différents flux de communication.
Mise en perspective avec les choix des autres systèmes mobiles. Des problématiques spécifiques liées à la philosophie d’Android : Des 3 systèmes, c’est android qui est le plus ouvert avec au coeur du système la communication entre applications. Il s’agit d’un véritable multitâche (kernel linux). Il n’y a aucune limite sur les applications possibles.
Quand pour iPhone, il y a peu de communication entre applications avec un multitâche limité. Les possibilités d’applications restreintes (nouveau market impossible, nouveau clavier impossible …).
Enfin avec Windows 7, il n’y a tout simplement pas de multitâche, pas de service en tâche de fond. Le risque est supprimé…certes, mais fin de vie du système ! Microsoft ne le reconduit pas et choisit de repartir à zéro pour son système windows 8.
Rappel des concepts d’Android :
- Les applications sont isolées selon le principe linux de users différents. Un répertoire de travail accessible seulement par le user de l’application. Il faut toute fois savoir que d’autres applications signées avec le même certificat (les applications d’un même développeur) peuvent avoir le même user linux donc avoir accès au même répertoire.
- L’utilisateur du terminal est considéré comme autorisé
- Toutes les ressources de l’apk sont accessibles à toutes les applications.
- Le chiffrement du disque, possible, n’est pas de base comme pour l’iPhone (La problématique du chiffrement réside cependant sur la manière de conservée la clef privée ou asymétrique).
- Une application peut utiliser plusieurs processus et réciproquement, plusieurs aplications peuvent partager le même processus.
- Le principe de base d’Android : des activités ou services utilisables par toutes les applications. (L’utilisateur peut ainsi passer d’une application à une autre sans même s’en rendre compte. Il pourrait y avoir un risque d’attaque des paramètres utilisés (SQLInjections, XSS? CSRF, ..).
La réponse principale à cette problématique, est la notion de privilèges déclaratifs : l’utilisateur peut décider de ne pas installer une application présentant un privilège qu’il jugerait abusif. C’est du tout ou rien finalement : il n’y a pas de possibilité à priori d’avoir des privilèges modulables et une application qui aurait les fonctionnalités correspondantes…
Enfin, ce n’est pas tout à fait vrai. Philippe Prados nous a montré comment rajouter une permission à une application sans même que l’utilisateur ne le sache ! Bien sûr, ceci pourrait être utilisé par un développeur malveillant. Mais pas de panique ! un développeur découvert serait immédiatement rayé du market. Google a de plus la possibilité de supprimer à distance des applications de nos mobiles. (Eh oui).
Le mécanisme est assez simple. Prenons l’exemple d’une application qui n’a pas de privilège d’envoi de SMS et que l’utilisateur télécharge dans un premier temps. Puis il télécharge une autre application qui a le privilège SMS, ayant la même signature et le même user id que la précédente. La première hérite automatiquement du privilège SMS. Tout cela est possible car les 2 applications partagent le même processus.
Or les privilèges sont en fait associés à un processus ; ils sont l’union des privilèges des applications qui partagent le même identifiant utilisateur.
Et le conférencier de nous rassurer alors : la bonne nouvelle, c’est que jusqu’à ce jour personne n’a utilisé ce procédé.
David Fages abordait dans une seconde conférence non moins passionnante, la sécurité des communications.
Avec en métaphore, l’image d’un château fort et de ses douves, le conférencier nous faisait nous poser la question en préambule : la sécurité pour quoi faire ? Oui, la sécurité c’est bien, mais pour répondre à un objectif précis.
Rappel de la terminologie :
- le bien à protéger : par exemple dans une comminication, les informations échangées sont les biens à protéger (confidentialité, intégrité, disponibilité).
- les menaces : la divulgation (via interception du terminal mobile, de l’infra serveur ou le proxy ou encore le sniffage du réseau), la modification (du terminal, du proxy ou du serveur), le déni de service
- l’objectif de sécurité
- la contre-mesure
Ensuite, Daniel Fages décortiquait la solution de sécurité classique : SSL. La solution de chiffrement de bout en bout est-elle fiable ?
Tout dépend de la gestion des clés et particulièrement de la gestion des certificats racines. En fait, de la protection du keystore contenant les certificats racines.
Avant la version 4 d’Android, il fallait être root pour ajouter un certificat racine. Après la version 4, c’est encore plus facile, la liste des certificats racines est accessibles depuis les paramètres systèmes.
Enfin, il nous montrait avec quelle facilité il était possible d’intercepter la communication entre un terminal et le service « Google Check-in » à partir d’un certificat racine « fake » sur le terminal et de la mise en place d’une solution d’interception de requêtes http/https (redirection vers un proxy « transparent » qui envoie le contenu vers un serveur). Le proxy transparent génère à la volée un faux certificat serveur signé par le certificat racine « fake » : il peut alors décoder toutes les requêtes reçues.
Pour conclure :
- Avec SSL, la gestion des clés est primordiale.
- La sécurité forte a un coût. Il faut choisir une solution adaptée au besoin (mot de passe crypté en md5 peut largement suffire).
- De toute manière, la sécurité totale est impossible puisque tout fini par être craqué. Mais pour citer Philippe Prados, sinon, on peut toujours aller élever des chèvres.
On attend avec impatience les conférences de la rentrée du PAUG.