SnowCamp 2022

Les process événementiel sont une nouvelle façon de traiter et d'ingérer les données. Le serverless est un nouveau paradigme pour faire abstraction de la couche technique et se concentrer sur ce qui compte: les processus métier.
Les deux combinés, vous pouvez créer un pipeline de données puissant et évolutif sur Google Cloud. Vous pouvez réagir à un événement, déclencher l'étape suivante avec facilité et juste à temps.

La réalité n'est pas si belle, et ça devient vite devenu un cauchemar pour comprendre et mettre à jour les pipelines. Workflows est un nouveau produit sur Google Cloud qui orchestre les processus.
Venez découvrir ce qu'était le pipeline de données avant et comment il est plus fluide avec Workflow!

Rsocket est un nouveau protocole utilisé dans les communications TCP, WebSockets et Aeron. Il est conçu pour dépasser de nombreuses limitations, notamment celles rencontrées avec le protocole HTTP. RSocket s’appuie sur le manifeste réactif et implémente la spécification Reactive-Streams.

Le protocole est activement développé et disponible dans de nombreux langages (Java, Javascript, .NET, GO, C++ et Kotlin). Il est intégré dans Spring Framework depuis la version 5.2 et largement soutenu par des entreprises comme Facebook, VMWare et Alibaba.

Nous verrons avec des cas pratiques comment ce protocole permet de correspondre aux besoins modernes : push de données, échanges bi-directionnels, reprise de connexion et asynchronisme.

Documenter l'architecture d'un système est toujours une tâche fastidieuse. Une approche qui gagne actuellement en réputation est l'utilisation du modèle C4, imaginé par Simon Brown. Dans cette présentation, je vais parler de mon usage de ce système, et des adaptations que j'ai ajouté pour permettre une documentation d'architecture en continu de la manière la plus simple possible

Vous avez une source de données représentant la source de vérité. Vous avez besoin d'utiliser ces données d'une autre façon afin de couvrir d'autres cas d'utilisation (cache, indexation, recherche, business intelligence...). Pour cela, pas de magie, il vous faudra dupliquer la donnée, souvent dans un autre format, afin de pouvoir répondre à votre besoin.

Mais comment conserver la données toujours synchronisée avec la source de vérité ? Le tout, sans même pouvoir toucher l'application métier.

Dans cette session 100% live coding, nous vous donnerons une recette simple pour surmonter ces difficultés en utilisant un pattern de "Change Data Capture".

Comme tout sujet lié à la sécurité, les incontournables standards OAuth2, OpenID Connect et leurs recommandations évoluent rapidement. Ce qui était la norme hier est absolument interdit aujourd’hui.

Pour mieux comprendre l’état d’OAuth2(.1)/OIDC en 2021, on partira de ses origines en expliquant les concepts, leurs contextes et les problèmes qu’ils résolvent.
Pourquoi l’Implicit Flow est passé de recommandation pour les SPA à persona non-grata ? Qu’est-ce que résous PKCE ? Quel flow utiliser en fonction du type de client ? ou même quel stockage pour les tokens d’accès ?

On fera donc le tour des dernières recommandations de l’IETF et d’OWASP et on en profitera aussi pour parler du futur avec GNAP.
Il se pourrait que vous ayez des choses à faire en ressortant de cette conf ;).

Préambule : ce talk est une tentative de vulgarisation visant à expliquer un protocole simple à développer et à utiliser, mais qui repose sur des méthodes cryptographiques méconnues et qui pourraient rebuter certains développeurs. Sa démocratisation peut avoir un impact positif majeur sur la sécurité des internautes et sur la protection de leur vie privée.

Il était une fois des valeureux administrateurs et développeurs, qui devaient contrôler l'accès à des services de grande valeur, par une authentification à base de mot de passe. Les vénérés utilisateurs étaient riches d'un trésor de données personnelles et sensibles, et leurs mots de passe en étaient la clef. Leur vie aurait été merveilleuse, sans les terribles pirates à chapeau noir équipés de leurs redoutables tables en arc-en-ciel et les gigantesques grufalos, capables d'espionner et de cloner les mots de passe des utilisateurs pour leur voler, ou exploiter, leur trésor. Les valeureux développeurs et administrateurs luttaient contre les pirates grâce à des recettes à base de hash et de sels qu’ils se transmettaient de génération en génération. Mais sachez, braves et valeureux amis, qu'une ancienne recette indienne (d’Amérique) à l’efficacité redoutable a été déterrée, puis utilisée dans les terres helvétiques de ProtonMail : le protocole Secure Remote Password (aka SRP). En effet, cette recette "mathémagique" permet aux utilisateurs de s'authentifier simplement avec leur mot de passe, sans jamais exposer ces précieux sur le chaotique Internet. Les vilains pirates et les grufalos affamés ne peuvent donc plus espionner et voler les clefs du trésor, et la recette mathémagique simplifie grandement le travail des valeureux développeurs et administrateurs. Si à travers cette modeste histoire nous faisons connaitre SRP et participons à son adoption, alors c'est la fin du game pour les pirates à chapeau noir et les gigantesques grufalos (ou presque).

Secure Remote Protocol est un protocole d'authentification par mot de passe reposant sur une preuve à divulgation nulle de connaissance (Zero-Knowledge Proof). Il a été publié en 1998 par Tom Wu, de l'université de Stanford, puis standardisé en 2000 dans la RFC 2945. Il est notamment utilisé au quotidien par les millions d'utilisateurs de ProtonMail.

Depuis quelques années, on ne compte plus le nombre d'entreprises s'étant fait dérober des données sensibles. Il est intéressant de noter que les failles utilisées sont généralement toujours les mêmes : XSS, SQLi, RCE, etc.

Pour un néophyte, ces termes peuvent paraître difficile à comprendre, mais en tant que développeurs, vous savez probablement ce qui se cache derrière (ou au moins en partie).

Mais connaissez-vous vraiment les risques encourus ?
Savez-vous réellement comment exploiter ce type de faille ?

Dans ce talk, nous reviendrons sur des cas concrets (comprendre : des failles que l'on a identifié et reporté sur des "vrais" sites et peut-être même des applications que vous utilisez tous les jours).

A chaque fois, nous vous proposerons :
- Une mise en situation en reproduisant la faille rencontrée sur une application test.
- Nous montrerons les outils que nous avons utilisé pour identifier le souci et le POC mis en place pour le report.
- Nous reviendrons sur les conséquences possible si cette faille avait été identifié par une personne malveillante.
- La correction de la faille.

Pour avoir une meilleure vision de la menace qui pèse sur votre application, il est devenu quasiment indispensable de connaître les outils utilisés par les pentesters / hackers.

Aujourd'hui, nous vous proposons de vous partager nos astuces / nos outils mais aussi notre vision de développeurs passionnés de sécurité afin d'avoir une meilleure vision des menaces qui pèsent sur votre application !

Cela fait une dizaine d'années que nous essayons d'appliquer les principes du DevOps pour livrer plus vite en production. Sur le chemin de l'unification des devs et des ops, la sécurité est encore un frein. Alors faut-il ignorer la sécurité et attendre la fuite de données ou bien agir maintenant, s'organiser, et automatiser.

Le DevSecOps nous promet d'intégrer la sécurité dans nos pipelines CI / CD mais aussi dans notre processus de développement pour que la sécurité fasse partie intégrante de notre culture et ne soit pas un goulot d'étranglement.