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.

Publicités

T’as vu ? Un chtijug !

Le monde change, et le chtijug s’adapte donc. Et ce soir, l’adaptation, c’est un framework Javascript assez connu : VueJS. J’en ai déja parlé un peu, voyons voir si les speakers vont m’aider à revoir mon opinion …​

Mais avant, deux mots. D’abord, Sarah Habchi veut interviewer des développeurs Android qui ont utilisé le Linter. Pour s’inscrire, c’est http://bit.ly/Android-Lint. Allez-y, c’est pour l’INRIA.

(attention, cette fois-ci, c’est moi qui parle directement, et pas le chtijug) Ensuite, regardez ces photos de la soirée

Comptez approximativement le nombre de présents … Et comparez avec le nombre d’inscrits sur Meetup … Où il y avait 78 personnes sur liste d’attente. Si vous vous êtes inscrits, mais que vous n’êtes pas venu, vous avez pris la place de quelqu’un. C’est assez moche. Donc la prochaine fois, ne soyez pas moche, annulez plutôt.

Revenons-en à notre sujet …

Vous pouvez trouvez les slides de la présentation à cette adresse : https://slides.com/posva/vue-simple-yet-scalable/live et si vraiment vous voulez revoir la présentation dans les conditions du direct, le chtijug a ce qu’il faut :

 

Vuejs vite fait

Donc, Vuejs ! Ou plutôt l’écosystème de Vuejs. Notre speaker posva n’est pas un amateur, parce qu’il fait partie de la core team vue, et s’occupe d’un certain nombre de librairies vue.

Ecosystème ? oui, parce qu’effectivement, vue-router, vuex, vue-devtools et autres vue-test-utils sont des outils assez pratiques pour travailler autour de Vuejs. Il faut noter que ces composants additionnels sont développés par l’équipe Vuejs, ce qui facilite la communication entre les développeurs, et fournit aussi une sacrée visibilité à ces « extensions ».

Créer une application Vuejs simple, c’est facile. Regardez cet exemple de Hello World :

Et ça permet tout de suite de montrer le lien entre le template et le modèle de données : le contenu de {{message}} sera automatiquement remplacé par sa valeur.

Ca rend Vuejs assez abordable, puisqu’on peut commencer par un simple composant et l’étendre assez rapidement (contrairement à React et Angular, il semble).

Un autre intérêt de Vuejs, c’est le format .vue, où les différents éléments d’un composant sont déclarés dans le même fichier. C’est très dérangeant pour quelqu’un qui a fait du MVC avec un modèle, une vue et un contrôleur séparé. Mais ça plaît à certains. Et je dois bien reconnaître qu’il est assez confortable d’avoir les aspects d’un composant réunis au même endroit, même si j’aurais préféré avoir trois fichiers séparés dans le même dossier (par exemple).

Parce qu’évidement, Vuejs fait du MVC. Ce MVC relie donc d’un côté le DOM et de l’autre le modèle Javascript à travers des event listeners et un virtual DOM.

Dans le document HTML, enfin dans le fragment HTML contenu dans un composant Vuejs, on utilise des directives comme v-if qui commencent toutes par v-. Vuejs supporte aussi les templates JSX. Mais franchement, utiliser des du JSX, c’est un peu comme faire une JSP à l’ancienne : c’est à peu près la garantie de perdre la séparation entre la vue et le modèle, et donc de rendre le code bien pourri.

Le meilleur morceau de Vuejs, c’est évidement le binding : quand on change une donnée, elle est immédiatement mise à jour dans toutes les vues qui l’affichent.

Et c’est tout pour le « comment ça marche ».

L’écosystème

Voyons maintenant pourquoi Vuejs est aussi adaptable à l’échelle de l’application, en partant d’un simple rendu déclaratif, puis en intégrant les composants, le routage, la gestion d’état, le système de build. Évidement, tous ces éléments sont optionnels.

Démarrer un projet

Donc, pour commencer, la CLI, ou POI, c’est bien, parce que ça permet de démarrer facilement un projet sans s’embêter avec la configuration Webpack (et ça, c’est bien).

Le routeur

Ensuite, quand vous avez une barre de navigation qui change le contenu de la page, vous êtes tenté de mettre une batterie de if. Et c’est là que le routeur prend son intérêt, puisqu’il suffira de déclarer les différents composants, et donner à ces composants le nom d’une variable qui sera alimentée par un binding. Et là, pouf, ça marchera. Et en bonus, on peut changer l’url (pour peu qu’on accepte de ne pas supporter IE 9). La méthode présentée semble un peu …​ astucieuse, mais c’est assez cool de pouvoir avoir une URL qui suit l’état de la page web.

Ca devient un peu moins drôle quand on aborde les modifieurs, comme .prevent. Comme on peut les ajouter derrière un événement, ça change son sens d’une façon …​ qui me satisfait assez peu intellectuellement.

Gérer l’état

Comme les composants n’ont que des relations hiérarchiques, pour communiquer des informations entre composants, ça n’est pas toujours trivial : le parent peut modifier l’état d’un enfant, mais l’enfant doit envoyer des événements auxquels le parent doit s’abonner. Et comme Vuex est assez verbeux (une fonction par mutation d’état), on peut essayer d’éviter ça de deux façons

$root

C’est le composant racine, instancié à partir du moment où on a fait new Vue(....) C’est clairement l’utilisation d’une variable globale pour stocker l’état. C’est sale. Avec une ou deux astuces, on peut simplifier ça, mais franchement, je trouve ça sale …​ Et franchement inmaintenable.

Par contre, ça peut rendre service pour les fonctions « globales », justement, comme par exemple l’authentification : en définissant une fonction login globale, on peut facilement authentifier l’utilisateur depuis n’importe quelle hiérarchie de composant (mais en y réfléchissant, c’est assez peu utile).

Partager un état

Là, ça parlera au javaiste en moi : si je crée un objet, que je passe à la construction d’un conteneur (et que le conteneur mémorise comme data), il sera partagé entre tous les conteneurs qui utilisent cet objet. Et ça fera un chouette état partagé.

Vuex

C’est quoi Vuex ? ou plutôt qu’est-ce que ça offre ? Avant tout, comme Vuex enregistre tous les changements de l’état global, ça permet de voyager dans le temps …​ et par exemple de rejouer les bugs de l’utilisateur (classe !). Du copu, quand changer ? Par exemple, quand on a déja 5 morceaux du modèle codant l’état, et qu’on en ajoute encore.

Migrer à Vuex

D’abord, il faut créer le Store. Ensuite il faut créer les mutations. Et les actions. Et il faudra injecter le store dans l’instance root. Avant de tout refactorer pour remplacer le $root par $store.Ca a l’air bien compliqué, en fait.

Commencer Vuejs

Le plus simple, c’est évidement de lire le guide (qui est effectivement bien fichu). Ensuite, utilisez vue-devtools, et les fichiers .vue. Si vous utilisez VSCode, vetur est bien pratique (anecdote marrante, le présentateur nous parle d’emacs, de vi, d’Atom, …​ et c’est tout !).

Conclusion

J’ai trouvé ce tour d’horizon du monde Vue assez rapide. Pour tout dire, j’aurais vraiment apprécié de voir quelques exemples en live-coding (le cas le plus typique étant Vuex, dont je ne comprend pas l’intérêt).

Et même si je l’ai déja dit, je vais me répéter.

Cette présentation n’a malheureusement pas changé l’opinion que j’ai de Vuejs. C’est chouette, et évidement bien mieux que les saloperies que sont React ou Angular. Malheureusement, ça n’est pas au niveau de Ractivejs, que je continue à croire être le meilleur framework JS existant. Pour tout dire, et c’est quand même une interrogation majeure, je ne comprend pas pourquoi Vuejs a percé et pas Ractivejs, puisqu’ils offrent globalement les mêmes fonctionnalités, avec à mon sens une plus grand expressivité de Ractivejs.

Une question de modèle

Je suis tombé sur cette question sur Twitter la semaine dernière

Et aussi curieux que ça puisse paraître, ma réponse est un grand oui.

Si demain un site veut utiliser mon CPU pour miner des cryptomonnaies, ce sera avec plaisir.

Parce que le modèle économique de la publicité sur internet a pour moi des limites terribles

  • Comme il s’agit d’un modèle de l’attention, il limite le contenu visible en garnissant les pages web de bandeaux (animés ou non) de pop-ins et autres instrument réduisant mon écran à un panneau publicitaire géant
  • Comme il s’agit d’un modèle de l’attention, il pousse les sites web vers le titre PUTACLIC, l’absence de contenu réel et une économie de l’attention qui réduit à néant les sites de qualité.

Bon, alors, évidement, ce nouveau mode de fonctionnement a des inconvénients clairs :

  • OH MON DIEU MON CPU EST UTILISE ! (parce qu’un CPU d’ordinateur moderne ne fait rien environ … 95% du temps – statistique à vue de nez)
  • Rien n’interdit à un site web de faire du minage et d’afficher de la publicité

Mais je pense que l’émergence d’une économie utilisant mon CPU d’une façon correcte, au lieu de squatter mon écran, pourrait être intéressante.

Chtijug et barbecue

Gravitee

Bon, je connais les speakers depuis …​ 10 ans facile. Et ça fait plaisir de les voir sur scène !

Gravitee, un API Manager

Donc l’API management (voir la session chez Kiabi – et la page Wikipedia de définition), ça permet de créer et de publier des API, de les maintenir en état de marche, et enfin de collecter des statistiques d’usage.

D’un point de vue architecture, il y a principalement deux composants

  1. Un portail d’API, permettant l’enregistrement d’utilisateurs, la découverte des API.
  2. Une gateway, qui va exécuter les appels en les dispatchant auprès des services backend.

Pour les clients, ça peut être

  • Une façon d’exposer une API
  • Un reverse proxy
  • Un ESB pour les API REST (mais ça c’est faux : il y a tout un tas de différences entre l’API manager et l’ESB)

Gravitee, le produit

Existe depuis 2015, et nos speakers ont créé la société GraviteeSource pour fournir le conseil, la formation autour du produit.

Démonstration de création d’API

A partir d’un serveur exposant l’API, on peut facilement créer les éléments dans Gravitee grâce …​ à un wizard ! Il faut noter que, dans le wizard simple, la notion de plan de consomation (pour pouvoir facturer facilement, évidement). Par ailleurs, on peut importer facilement de la doc RAML/SWAGGER/Markdown. Et c’est fini, l’API est déployable

Consomation d’API

Une fois l’API créée, il faut créer une souscription pour pouvoir l’utiliser.

Et là, les petits gars, vous avez déja de quoi remplir quelques rapports de bugs pour améliorer vos présentations 😉

Cela dit, les écrans d’administration sont sacrément bien fichus, avec une vision complète des temps de réponse et de la qualité des réponses.

Réécriture de la réponse

L’un des éléments intéressants d’un API manager, c’est la possibilité de modifier les requêtes pendant leur exécution grâce à des politiques de transformation préconçues (des transformations simples) ou …​ du Groovy (j’aime beaucoup), ou aussi de créer un cache au niveau de la gateway.

Développement de policy

Comme gravitee est développé en Java avec des mécanismes de plugins typiques, ajouter une policy, c’est assez facile, et c’est parti …​ avec un archétype Maven ! Et je dois dire que le code produit par la génération d’archétype est, un peu comme pour Wisdom, assez complet.

Web multi-écrans

J’ai déja vu la présentation sur Youtube, mais en live, ça n’est évidement pas pareil …​

Un truc marrant dès le début de la présentation : Hubert nous parle de 2008 et de ses deux écrans. De mémoire, avec mon voisin de derrière, en 2009, on bossait dans une boîte où chaque poste avait 3 écrans sur deux machines avec Synergy …​ Et encore, ça n’était pas ma première fois avec plusieurs écrans.

Donc, plusieurs écrans, et des interfaces avec plusieurs écrans. Dans le web.

Un truc très intéressant dans sa présentation, c’est qu’il intègre un avis contraire, celui de quelqu’un qui affirme ne travailler qu’avec un seul écran.

Et Hubert enchaîne ensuite avec les différentes techniques permettant la communication : window.open, et autres hacks. J’ai malheureusement un trou dans mes notes. Dans mes souvenirs, il y a un ou deux hacks, et une technologie parfaite pour les applis du futur, mais pas forcément disponible partout.

Cela dit, il y a une faille dans cette présentation (formellement impressionante) : le cas d’usage est quand même super limité : faire du web, sur plusieurs écrans, sans serveur …​ mis à part TiddliWiki, je connais peu de projets sur ce créneau. D’ailleurs, même les applications comme Atom, Brackets, Code ont un serveur web (oui, dans le même process, mais conceptuellement, il y a quand même un client, et un serveur). Personnellement, quand j’ai le genre de besoin dont Hubert parle (avoir des clients qui communiquent entre eux), je reste simple et je mets du websocket sur mon serveur.

Conclusion

Les sujets étaient assez spécifiques, mais les speakers étaient très chouettes, et la soirée s’est finie tranquillement sur les pelouses de Norsys

Un mastodonte est-il plus léger qu’un oiseau ?

Ouais, bon, je tente le titre accrocheur.

Donc, j’ai entendu parler toute la semaine dernière de mastodon, un réseau social de microblogging décentralisé.

Autrement dit, un équivalent de twitter (avec une limite des messages à 500 caractères) qui présente l’avantage (en termes de scalabilité) de permettre l’ajout de nouvelles instances au réseau. Pour être plus clair, le réseau social n’est plus un unique site web, mais un ensemble de sites web sur des serveurs différents, dans des pays différents.

Ca me plaisait pas mal (moins d’adhérence à la silicon valley, plus de possibilité de survie du réseau, tout ça tout ça.

J’attendais juste de trouver une instance « sympathique ».

Et soudain, grâce à Camille Gévaudan, la lumière

Donc j’y suis allé, j’y ai créé un compte.

Pour l’instant, c’est sûr que le réseau est encore peut-être un peu jeune. Mais

  • Les fonctionnalités sont équivalentes à celle de Twitter
  • La liberté est plaisante
  • Le nombre d’instances est déjà élevé

Je vais donc tenter la migration complète vers mastodon : envoyer le flux RSS de Shaarli vers mastodon, puis générer un flux RSS de mastodon et l’envoyer vers Twitter.

Fiddler pour débugger à distance

Vous connaissez Fiddler ? C’est un très bon proxy de débuggage http pour Windows.

Eh bien aujourd’hui, j’ai découvert que je pouvais l’utiliser pour intercepter les requêtes entre un serveur Apache (sur une autre machine) et mon serveur web Java (lui aussi sur une autre machine). Le pire, c’est que ça n’est même pas compliqué.

Il suffit de régler le proxy pour accepter les requêtes distantes

2016-11-04-20_54_19-telerik-fiddler-options

Et de régler le proxy que fiddler utilisera pour recevoir les requêtes pour que ce soit l’autre machine

2016-11-04-20_56_38-telerik-fiddler-options

Et là, les requêtes arriveront bien d’Apache dans Fiddler pour repartir aussi sec vers le serveur.

Très cool.

 

Développeurs, il est temps de changer le monde !

A la suite de mon article précédent, j’ai réfléchi (un peu).

Et plusieurs idées ce sont assemblées dans ma tête. Je vais essayer de les articuler correctement, mais ça n’est pas si facile …

Vous vous souvenez de la matinée sur le rôle social du développeur à Devoxx ce printemps ? Non ? Dans ce cas-là, j’en ai parlé :

Et je vous invite à relire ces articles pour bien comprendre de quoi il s’agit. L’idée que j’ai tiré, sans originalité, il est vrai, de ces quatre conférences, c’est que la révolution industrielle de l’informatique va changer la donne, comme les précédentes. Pour mémoire, la révolution de l’imprimerie n’a pas vraiment été une bonne chose pour les moines copistes.

Il est déjà évident que la plupart des tâches pilotées par des workflows sont maintenant totalement définies par l’ordinateur (pensez par exemple aux centres d’appels, à la gestion des interventions des grandes entreprises, les remboursements de notes de frais, …).

Mais d’autres domaines vont bientôt tomber dans l’escarcelle des informaticiens : la bancassurance, la médecine. Le plus important étant évidement l’implémentation de la loi. En effet, si la loi est implémentée par du code (c’est le cas du code des impôts, par exemple), ce n’est plus vraiment le politicien qui choisit comme l’impôt est prélevé, mais le code écrit par un informaticien, quand bien même c’est un sous-traitant d’une grosse SSII en contrat avec le gouvernement.

Or actuellement, nos représentants politiques (députés, maires, ministres), sont là pour … nous représenter, parce que leur connaissance de la loi est plus grande, parce qu’ils sont des personnes clé.

En conséquence, on retrouve par exemple dans l’assemblée nationale (je ne retrouve plus les statistiques que j’avais pu consulter il y a quelques années)

  • des avocats
  • des notaires
  • des médecins
  • des fonctionnaires (je sais, ça n’est pas un métier, mais un statut), au premier rang desquels une palanquée d’inspecteurs des impôts.
  • et un agriculteur

Est-ce qu’il y a des informaticiens dans le tas ? je ne crois pas, non.

Est-ce qu’il y a des gens qui comprennent ce qu’est réellement la révolution numérique ? Je suis à peu près certain que non.

Alors ?

Qu’est-ce qu’il faut faire ?

Vous vous doutez bien de la terrible réponse que je vais apporter : nous, les pionniers du digital, devons trouver des représentants, des champions, et les aider à prendre des responsabilités politiques, pour éviter que les politiques ne décident un jour que toutes ces histoires d’ordinateurs sont décidément trop dangereuses pour leur pouvoir, ce qui arrivera forcément.

Pas de chti jug sur Typescript pour moi

Ce soir, c’est chtijug sur Typescript. Et en plus, le lieu a l’air sympa.

Pas parce que je n’aime pas Cyril et ses amis, bien au contraire, je trouve le boulot du chijug vraiment chouette.

Mais plutôt parce que … comment dire … tout cet écosystème Javascript me fatigue à un point fou.

Je vous explique.

J’ai fait ma première page web avec du Javascript en 1999 … ou 2000. Bon, la wayback machine a une version datant de juillet 2001. Enfin bref. A l’époque, faire du Javascript était un sale boulot.

Heureusement, jQuery a tout changé. Et pendant quelques années, faire du web dynamique était raisonnablement simple conceptuellement et techniquement.

Et puis un jour, l’apocalypse de la sur-architecture s’est pointée sous les traits de nodejs. Je ne vais pas refaire l’article contre nodejs, parce qu’il suffit de regarder quelques twits de Mario Fusco ou Sam&Max pour comprendre

Et c’est quoi le rapport avec Typescript ?

Pour être honnête, Typescript n’est pas une solution, mais un élément du problème.

En effet, de mon point de vue, les langages modernes ont été créés pour permettre aux gens d’être plus productifs que l’assembleur ou le C, par exemple. Seulement, et au risque de choquer mes camarades Javaistes, le Javascript n’est pas ce genre de langage.

Non.

Comme l’écrivait Douglas Crockford il y a … un moment, le javascript n’est pas le langage qu’on croit. Et franchement, une fois qu’on comprend que le Javascript est un langage fonctionnel s’exécutant dans un environnement peu commode, il se passe une certaine épiphanie qui permet de mieux en comprendre la réelle simplicité. Une simplicité qui rend des monstruosités comme Angular, React, ou Typescript, aussi pratiques qu’un 38 tonnes en ville.

C’est aussi pour ça (en plus de ne pas assister à une conf sans doute intéressante sur un langage qui doit sans aucun doute avoir de bons côtés) que j’ai décidé de ne plus me lancer dans des projets front-end en utilisant autre chose que des bibliothèques simples (voire élémentaires) qui remplissent proprement une fonction simple et claire. Des outils comme

  • RequireJS
  • RactiveJS
  • jQuery
  • underscoreJS

Et sorti de là, comme disait il y a bien longtemps mon prof d’info, point-barre. Du coup, forcément, ce talk sur Typescript présentait un problème d’intérêt fondamental : comment diable pouvais-je m’intéresser à un langage dont la finalité actuelle est précisément de faire quelque chose qui me répugne au plus haut point ?

#devoxxfr – L’Expérience Développeur et votre API

Et comment on fait de belles api alors ?
Evidement, ce talk parle d’apis rest/http. Mais à mon avis, ça peut se projeter sur d’autres domaines comme les interfaces entre modules (quels qu’ils soient).

Première chose à envisager : quels sont les utilisateurs ?

Donc d’abord, rendre l’api compréhensible.

Et rendre la documentation « inutile » : proposer des exemples de code, faire des guides d’utilisation (des howto, typiquement), et avoir un exemple complet d’utilisation. Toute cette documentation, écrivez-la avec des outils « connus ».
Permettre aux utilisateurs de contribuer de la doc est également une bonne façon de créer de la documentation facilement.

#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.