DevFest Lille 6 : L’open-source à la rescousse de mes API

Dans cette présentation, David et Guillaume mettent en oeuvre un API manager Gravitee sur une application assez simple, qui permet néanmoins de voir la plupart des cas d’utilisation de Gravitee pour sécuriser une API.

Créer une application

David avait déja fait cette présentation au chtijug.

CORS

Il est facile de rajouter les entêtes CORS dans une API avec Gravitee (vraiment facile).

Authentification et autorisation

Ben là, le plus simple, c’est de passer par Keycloak (qui a également été présenté au chtijug !).

Création du realm

Pour le coup, onv a utiliser Keycloak en authentifieur OpenID. Il faut donc créer un CLIENT_ID pour l’application.

Connexion de l’interface web à Keycloak

Pas bien compliqué, puisque Keycloak fournit l’api JS pour s’authentifier auprès du serveur Keycloak. Et on peut évidement utiliser tout un tas de fournisseurs OpenID.

Sécurisation d’API

Identification

Dans ce cas, il faut créer pour le client (l’interface web en l’occurence) une clé d’API qui lui permettra d’accéder aux ressources qui sont protégées par le plan définissant cette clé. Ce qui n’est pas une clé d’autorisation : c’est juste une identification. === Autorisation Pour autoriser l’accès à l’API, on va encore une fois passer par Keycloak, qui sera cette fois le provider OAuth2.

Conclusion

L’un des intérêts du coupe Gravitee + Keycloak, c’est qu’on peut ajouter des fonctionnalités à l’application sans jamais toucher au serveur backend. Et ça, en terme d’évolutivité, c’est top !

Publicités

DevFest Lille 5 : Les cookies HTTP

Hubert vient tous parler d’un sujet quasi-neuf : les cookies. Et évidement, comme chez les autres showmen de l’informatique, la forme compte autant que le fond.

Revenons en 1994. A cette époque, Lou Montuli travaille chez Netscape. Et le navigateur typique est Lynx (et pas links, sa version avec Javascript et autres). On y invente (un peu à cause de lui) la balise <blink>. Et il y invente également les gifs animés. Et enfin, il y invente les cookies, dont l’objectif était déja de maintenir une session côté client.

C’est un paquet d’information envoyé par le serveur (via l’entête http Set-Cookie). Le navigateur les stocke localement dans un cookie jar (une boîte à cookie). Et lorsqu’il refait une requête au même serveur, il renvoie les cookies que ce serveur a déja positionné (via l’entête cookie).

Par défaut, le cookie expire quand le navigateur est fermé. Sauf évidement quand le serveur envoie l’entête Expiration-Date ou Max-Age qui définit une date de suppression.

La méthode typique est d’envoyer une Expiration-Date dans le passé, ou un Max-Age de 0.

Comment le navigateur sait-il que deux requêtes concernent le même site ?

Attribut Domain=

Avec cette attribut, le cookie est accessible sur tous les domaines dont le nom se termine par ce domaine. Par contre, on ne peut pas positionner un cookie sur un TLD (top level domain). Ces domaines sont tous listés sur http://publicsuffix.org.

On ne peut pas non plus définir comme domaine localhost.

Attribut Path

Si cet attribut est positionné, le cookie est positionné lorsque le path commence par le préfixe défini suivi par un /.

Attribut Secure

Lorsqu’il est positionné, le cookie n’est envoyé que pour les pages servies en https. ATTENTION ! cet attribut peut être positionné par une page non sécurisée (ce qui pourrait ouvrir la porte à toute une série de mauvaises requêtes).

Header HSTS

L’entête HTTP Strict-Transport-Security garantit que toutes les requêtes suivantes seront effectuées en HTTPS, comme une redirection (mais sans aller-retour de la requête auprès du serveur.)

Préfixes __

Deux préfixes de ce type existe : _ sur un nom de cookie et Host. chacun d’entre eux limite et le nombre de cas dans lesquels le cookie est servi.

Choix du port

Deux requêtes sur des ports différents serviront les mêmes ensembles de cookies. Heureusement, les navigateurs implémentent le same origin policy (qui identifie un serveur pour le local-storage, les requêtes Ajax). Malheureusement, celui-ci n’est pas utilisé pour les cookies.

Est-ce que les images utilisent également les cookies ?

Evidement ! Et du coup, c’est ce qui ouvre la porte aux attaques cross-server (CSRF & co). A noter qu’on peut les inclure dans des images. Mais comme le dit Hubert, entre gens de bonne compagnie, on ne fait pas de requêtes GET pour mettre à jour un site web.

Attribut SameSite

Avec cet attribut, les cookies ne sont envoyés que lorsqu’il sont servis par une page issue du même site.

Qui lit les cookies ?

Le navigateur, mais aussi l’API Javascript document.cookie …​ qui est sacrément étrange.

Et c’est la porte ouverte aux attaques XSS

Le sujet est vaste.

Attribut HttpOnly

Quand il est positionné, les Javascript dans la page ne peuvent pas accéder au cookie.

Mon avis

Le tour d’horizon était chouette. Et évidement, Hubert est un sacré showman qui maîtrise (presque) tous ses effets.

Vite, un chtijug !

Je me demande si je n’ai pas déjà utilisé ce titre …

En attendant, hier soir, c’était chtijug spécial quickies.

HTTPS Everywhere avec let’s encrypt

Le HTTPS c’est mieux pour la confidentialité des utilisateurs. Let’s encrypt est une autorité de certification, dont le client essentiel est certbot.

certbot

Tourne sur n’importe quel Unix (oui oui). Il y a des plugins pour tous les serveurs web, même sur le Raspberry.

Démonstration avec un site Apache

S’ensuit une jolie démonstration avec des poneys en ascii-art. Et tant mieux, parce que certbot a une interface ncurses ! On note tout de suite les problèmes classiques liés à du https : le mixed content (images ou scripts chargés en http, …). Je note également le point « magique » de Let’s Encrypt : obtenir un certificat à la volée, c’est quand même vachement plus rapide que de le réclamer physiquement à un service de sécurité.

Validation du certificat

La partie intéressante de Let’s encrypt, c’est le mode de génération de certificat. Plutôt que d’utiliser la méthode traditionnelle avec échange de mail, ils reposent sur l’exposition d’un challenge en http sur le site pour lequel on veut un certificat. C’est assez malin, car plus facilement automatisable. Et j’imagine que certbot doit pouvoir automatiser ça

Démonstration avec nginx et webroot

Histoire de montrer les capacités de certbot, on refait la démo, mais avec une configuration manuelle, pour nginx.

Intérêt ?

Le certificat est renouvellé automatiquement tous les 90 jours ! Du coup, plus de problème d’expiration. Et ça, pour les noobs de la sécurité comme moi, c’est vraiment cool. Un point important à noter : Let’s encrypt ne fournit que des certificats de classe 1, donc avec une sécurité « moyenne ». Les classes 2 et 3 impliquent des vérifications physiques, qui sont évidement manuelles.

Point bonus : il y a une interface permettant de révoquer les certificats depuis le site de Let’s Encrypt, ce qui provoquera sans doute leur renouvellement automatique.

Ce que la revue de code m’a apporté

Julien commence par nous raconter sa vie de jeune développeur. Et, personnellement, je me reconnais mal là-dedans :

  • la fierté du code produit
  • la propriété du code (c’est le code de Julien)
  • Et enfin, il veut que son code soit beau longtemps

Du coup, ils ont mis en place chez Axa des revues de code avec des rôles identifiés pour limiter les procès en sorcellerie. Malheureusement, j’ai peur que ça ne suffise pas. Du coup, il faut apprendre plusieurs choses (qui, il me semble, font partie de l’expérience du développeur). La première étant évidement de faire preuve de bienveillance envers ses collègues, le fameux « dur avec le code, doux avec les gens ».

Axa consomme environ 5% de son temps à faire de la revue de code. C’est assez peu, vu que ça permet de détecter des bugs (en plus d’assurer une cohérence stylistique des livrables).

A priori, il faut environ 3 mois pour que les revues soient « apaisées ».

A la réflexion, il y a à mon avis quelque chose de complètement biaisé dans le fait que le développeur vienne présenter lui-même son code à un procès en sorcellerie. Il vaudrait sans doute mieux que le code soit défendu par un « avocat » sans que le développeur à l’origine du code puisse être reconnu. Parce que, comme je le dis toujours, le code qui est dans Subversion/Git n’est plus ton code, c’est celui de l’équipe. Et c’est ce qui le rend magiquement sale.

lunrjs

lunrjs est un portage de Lucene pour javascript, utilisé chez Decathlon. Et sur le site de Decathlon, actuellement, quand on change un filtre de recherche, la page est visiblement rechargée (ce qui n’est pas terrible en termes de performances). Un portage, mais un peu restreint, puisqu’on perd par exemple les recherches de termes approchants.

A noter qu’actuellement, le catalogue produits de Decathlon est hébergé en SAAS, ce qui est … osé, je trouve.

Cela dit, je n’ai pas trouvé ça si impressionnant. Parce qu’il existe déja des tonnes d’API javascript pour exploiter le local storage « correctement ». En fait, le seul intérêt de lunrjs, c’est de compléter les recherches disponibles dans Lucene pour les déconnexions, mais je trouve le cas d’utilisation assez rare pour ne pas investir spécifiquement dessus. A mon sens, travailler sur une vraie API client/serveur dans le navigateur permettrait plus facilement d’attaquer ce type de problème. Sauf, bien sûr, si l’objectif du projet est précisément d’étendre Lucene, mais c’est plus de l’ordre du patch que de l’évolution en profondeur.

Cerberus

Donc, cerberus est un outil de test fonctionnel automatique. Des outils comme ça, il y en a … déjà … des tonnes. Alors pourquoi La Redoute s’est lancée dans cette guerre des tranchées ? Comme d’hab, l’hubris (autrement dit « il n’existait pas de solution correspondant à leur besoin »). Cerberus se place donc entre les différentes équipes, pour fournir un référentiel commun. ce qui implique également que les tests puissent être décrits par les fonctionnels ou les développeurs. Et comme un outil comme HPQC, il offre tout un tas de fonctionnalités, comme le support multi-technologies, multi-langues, multi-environnements l’exécution adaptative des tests, la génération de rapports ou l’intégration dans les outils de développement du SI (IC, bug tracker, …).
Bon, j’avoue, j’ai décroché lors de la démo. Parce que vraiment, on est face à de l’outil de test fonctionnel très haut niveau, où les étapes peuvent être effectuées manuellement ou automatiquement. Ce qui ne m’inspire qu’une chose : ces outils ne sont pas faits pour le monde d’aujourd’hui, mais pour les bonnes grosses applications traditionnelles des entreprises qui ont encore des équipes dév, fonctionnelles, test, différentes, et des processus de livraison longs et lourds. Dans ce cadre, j’imagine que ça doit marcher. Mais dans le cadre hyper-mouvant du web de 2016, je ne suis pas sûr que ça bouge assez vite.

Conclusion

Je peux paraître un peu dur avec certains des talks, mais ça n’est pas mon but. Le contenu ne m’a peut-être pas autant intéressé que les orateurs l’auraient souhaité, mais ça n’ôte rien à leur prestation. Les quatre présentations étaient en effet bien préparées, construites, bien organisées. C’est juste que chaque auditeur met ses propres filtres sur les sujets qui lui sont présentés … Bravo encore au chtijug qui arrive toujours à trouver des choses intéressantes à nous présenter (eh oui, ça n’est pas parce que ça ne m’a pas plu que ça n’était ps intéressant).

#devoxxfr – mon appli est secure … je crois

Allez c’est parti pour un peu de sécurité, enfin … je crois. Donc petit retour d’expérience sur la sécurité. Ou plus exactement sur les projets où on gère la sécurité à la fin.

Les MOA, les chefs de projet, ils ne parlent pas de la sécurité, parce que pour eux, ça n’est pas la sécurité.

Donc dans votre appli, vous mettez des trucs qui servent à rien : Spring security, OAuth, et même un WAF (web application firewall … genre f5, quoi).

Et comme ça arrive en fin du projet, même les simples bugs sont critiques et toute l’équipe a l’air nulle.

La sécurité, plus on s’approche des données, plus c’est fonctionnel, plus on s’éloigne, plus c’est technique.

On pourrait lire tous les bouquins de l’OWASP et comprendre ce qu’ils font, ou on pourrait … contrôler et valider que ça marche bien (autrement dit faire des tests).

Et donc, ils ont développé une application (highway to URLHell) qui montre tous les points d’accès de l’application. Et rien que ça, c’est déja très chouette.

Et là, on a une belle liste de boulettes :
deleteAll accessible par ‘importe quel user
dump de la base accessible
Opérations crud non protégées entre users (donc appel aux delete d’autres entrées)

ca attaque quand même assez fort en termes de liens entre authentification et autorisation.

Clairement, leur outil H2H est une super idée pour identifier le périmètre d’attaque d’une application. Et je vais sans doute le tester assez prochainement.

ophcrack, c’est pas si simple …

Bon, j’ai passé quinze jours de vacances assez agréables (la semaine passée à Séville, notament, fut un vrai bonheur). Mais malheureusement, les vacances sont finies.
Et en rentrant ce Lundi au travail, je me suis rendu compte avec stupeur et tremblements que … j’avais oublié mon mot de passe de session Windows ! Et ça, c’est moche. Parce que Windows 7 est « raisonnablement » sécurisé.
Du coup, j’ai dû prendre la voie du pirate et tenter de récupérer ledit mot de masse. J’ai successivement essayé

  • Un LiveCD ophcrack qui n’a pas marché (évidement, puisque c’était une version d’ophcrack taillée pour Windows XP)
  • Une tentative de création avec UNetBootin (dont l’interface graphique est atroce sous Linux, tout simplement) d’une clé USB bootable avec ophcrack (parce que l’outil de création de clés USB bootables d’Ubuntu ne marche que pour les dérivées d’Ubuntu)
  • Et, finalement, la version qui a marché : créer une clé USB Ubuntu, faire un apt-get install de chntpw, et supprimer le mot de passe de Windows depuis cette clé USB.

Ce que je retiens de ces aventures ? C’est qu’il est effectivement très simple de pirater une machine Windows qui n’est pas dans un domaine (ce qui rend ce dernier indispensable pour des ordinateurs professionnels) quand on en dispose. Mais aussi que même si c’est très simple, trouver la bonne démarche prend un certain temps ….

Mais quel fichu manque d’imagination je peux avoir !

Quand j’ai commencé à fréquenter les recoins sombres d’internet, je n’y connaissais rien en sécurité. J’avais donc, comme tout le monde, un unique mot de passe d’à peine huit caractères (dont un chiffre, heureusement).

Et puis j’ai peu à peu compris qu’un seul mot de passe pour tous les sites, c’était à peu près utile qu’aucun mot de passe. Hélas, si j’utilisais plusieurs mots de passe, comment me souvenir de quel mot de passe était utilisé pour quel site ? Et c’est là que j’ai découvert l’excellent Keepass. C’est donc tout naturellement que j’y ai stocké tous mes mots de passe, protégés par un mot de passe maître d’une longueur … insolente.

Hélas, cette phrase pouvait facilement être retrouvée sur le web, puisqu’il s’agissait de l’une de mes signatures mail/usenet (d’ailleurs, c’est à nouveau, après des errances diverses, ma signature mail/usenet).

Or j’ai découvert récemment les progrès dans les tables d’attaque utilisées par les pirates divers et variés, et donc par les gouvernements qui les emploient. Ce qui m’a poussé, naturellement, à changer ce mot de passe.

Et je dois dire que c’est un changement franchement flippant. Ce mot de passe, c’est, grâce à Keepass, le seul que je connaisse. Il est certes long, mais il est unique et bien ancré dans ma mémoire. Du coup, le changer, ça me fait flipper. Parce que si je le perds, je perds absolument tout : plus d’accès à mes mails, ni à tous les sites web auxquels j’ai pu me connecter.

Je crois qu’il est enfin temps pour moi de passer, pour certains services critiques, à l’authentification à deux facteurs … Ou plutôt à une forme spécifique de celle-ci pour Keepass.

N’empêche, j’ai tellement peur de perdre ce mot de passe que je me demande si je ne vais pas le noter dans un coin secret …

Le XXIème siècle sera paranoïaque

Mon krissfeed m’a ramené ce matin cet article de Maïa Mazaurette : Nouvelles de la paranoïa : peut-on encore se masturber devant son ordinateur ?

Je ne trouve pas ce texte de Maïa Mazaurette anodin. Mais alors pas du tout.

Normalement, c’est une blogueuse sexe.

Normalement elle parle de sex-toys, d’huiles de massage et autres harnais à sexe-balançoire.

Et là, elle nous montre ce qu’est la paranoïa sur internet. C’est mauvais signe. Mauvais signe parce que cet article est un signe indiscutable de paranoïa : mettre un post-it sur sa webcam juste parce qu’on risque d’être espionné ? Et puis quoi encore ?

Malheureusement, c’est une paranoïa justifiée. L’utilisation des webcams de manière furtive par le FBI est un fait documenté, et je ne peux pas iamginer que si le FBI le fait, d’autres services – moins respectueux du respect de la vie privée des citoyens d’autres pays que le leur – le font aussi. Comme par exemple (non exclusif) la NSA, la CIA, la DGSE, … Et comme Maïa l’indique également, le fait est que des hackers pratiquent également ce genre d’intrusion dans votre salon/bureau/chambre/… Bon, ces hackers le font … sans doute grâce aux backdoors installées dans les systèmes pour les dits services de renseignement.

Sur le même thème, l’article de Charles Stross  « Trust me, I’m a kettle » va beaucoup plus loin, en particulier dans la direction de l’internet des objets. Et égalemement dans une forme de paranoïa particulière, qui est également celle de Maïa.

Cette paranoïa (j’imagine qu’elle a un nom médical, mais la wikiedpia n’est aps claire sur le sujet) m’apparaît (parce qu’elle me touche, je pense) comme une paranoïa dirigée contre les autorités. Une forme un peu névrotique du slogan de Watchmen : « who watches the watchers » (à défaut d’une capture, j’ai dû me contenter de la wikipedia). En effet, chaque jour ou presque, nos gouvernants élus prennent des mesures pour « nous protéger », « rendre le monde plus sûr ». Au-delà de la bêtise formidable de ces slogans, il faut voir que chaque fois qu’une activité, qu’un site, qu’un ouvrage devient illégal, on crée à la fois une demande supérieure ET la sensation pour les citoyens que l’Etat, loin de les protéger, les enferme dans un cocon certes doux et chaud, mais dont l’état ne veut pas qu’on sorte.

Avec ce cocon vient évidement l’arsenal de surveillance panoptique, lequel contient donc désormais toutes les webcams connectées. C’est ce genre de choses qui me font penser que les « déomcraties occidentales » ne verront peut-être pas la fin du XXIème siècle : à chaque fois, leurs usages des moyens de communication moderne sont des usages déviants, et encore plus névrotiques que la paranoïa à laquelle je cède ici.

Ne leur faites pas confiance

On peut dire que la NSA a réussi son coup. Oh, d’accord, Snowden a parlé et maintenant on commence à se douter que les barbouzes n’ont pas d’âme, mais quand même. Ils sont forts ces enculés, comme on dit.

Tout a commencé par cette série de messages sur le shaarli de Sebsauvage (je vous conseille de suivre les différents liens, parce que je ne sais pas trop comment inclure directement les textes du flux RSS de Sebsavuage (dommage, parce que c’est une affaire passionante)

Autrement dit (depuis mon PC Windows), il semble de plus en plus nécessaire de passer à une version un peu protectrice de mes droits de Linux si je ne veux pas révéler chaque repli e mes testicules à la NSA.

Alors évidement, vous mentionnerez le dessin de XKCD sur le sujet

Malheureusement, je ne crois pas qu’il suffise de se réfugier derrière une attitude du type « ce qui est virtuel n’atteint pas le réel ».

Parce qu’une part croissante de notre communciation se fait via des réseaux.

Parce que j’aime l’idée que mes mails à ma femme restent privés.

Parce que je ne tiens pas à ce qu’une fuite de données dans un silo de données du fin fond du Delaware ne fournisse tous les détails de ma vie à n’importe quel pirate russe (ça arrivera un jour ou l’autre, mais je préférerai que ce soit l’autre).

Parce que je sais que la protection de mon fichier Keepass dans Dropbox n’est pas suffisante.

Il faut donc que je muscle encore la protection de ma vie privée virtuelle (et évidement des membres de ma famille).

Echelon 2 ?

Vous vous souvenez des histoires à propos d’Echelon ? Les délires sur l’interception d’emails ? Il y a dix ans, j’avais du mal à y croire. Aujourd’hui, à la lecture de cette présentation de la NSA, j’ai quand même du mal à ne pas fermer mes comptes chez chacun de ces pourvoyeurs de clouderies américaines. […]

Génération de mots de passe

Bon, aujourd’hui, je voulais vous parler initialement de Npackd, ou de minidlna, mais finalement, je vais vous parler de XKCD.
Et plus particulièrement de ce dessin :

 

Password_strength

 

Ce qui est intéressant avec internet, et plus spécifiquement avec XKCD et d’autres comics du genre, c’est que les mecs ont tellement de sens pratique que leurs délires peuvent devenir réalité.
Ainsi, LifeHacker m’apprend aujourd’hui que ce que l’auteur a rêvé existe maintenant sous forme d’une application web. Sympa. Mais j’aimerais encore mieux avoir un générateur de mot de passe dans Keepass. La grande question, c’est évidement « est-ce possible ? ».
Eh bien pas si facilement : les générateurs de Keepass sont limités et, par nature, choisissent des lettres aléatoires, et non des mots aléatoires. Bon, cela dit, faut encore que je regarde en détail la doc de Keepass, parce qu’il y a peut-être une option. D’un autre coté, les sites limitent souvent les mots de passe à dix caractères (ou vingt), ce qui est ennuyeux. Bon, je fouille, et je vous dis quoi, d’accord ?