Il n'y a pas si longtemps, j'ai écrit sur une vulnérabilité qui affectait Koa.js en 2018. J'étais frustré de devoir faire face à un problème de 2018 alors que la date était 2022, et j'utilisais la dernière version de Koa. 4 ans ont passé. C'est une longue période. Le problème n'est sûrement plus là ! ? Et c'était et ce n'était pas en même temps. Cela signifie que j'avais tort et raison en même temps. Alors, voici une mise à jour du post précédent pour vous dire comment:

• J'ai accusé à tort Sonatype et Dependency Track de ne pas fonctionner avec les informations de version dans des cas spécifiques
• Je peux avoir raison et tort à la fois sur une vulnérabilité

L'index OSS contient des informations sur la version

Si vous avez lu mon message précédent, vous vous souvenez probablement que j'ai conclu que le problème ne m'avait pas affecté. La bonne nouvelle est que j'avais raison. La mauvaise nouvelle est que j'ai accusé à tort Sonatype de ne pas avoir les numéros de version dans les données fournies par OSS Index pour Dependency Track. Il s'avère qu'ils ont l'information. Ce n'était tout simplement pas visible là où je m'attendais à ce qu'il soit visible. Voir la capture d'écran ci-dessous prise le 22/11/2022.

Il est fort probable que Dependency Track (DT) ne fonctionne pas précisément avec ce qui est affiché sur la page ci-dessus, mais je ne me souciais pas de vérifier à quoi ressemblaient les données que DT récupère à partir de l'index OSS. DT vient de montrer un lien vers OSS Index, où je pourrais en savoir plus. J'ai cliqué et atterri sur cette page.
Il a été porté à mon attention par Sonatype aujourd'hui que les numéros de version sont disponibles ; Je dois chercher ailleurs. En effet, si vous vous connectez à votre compte et que vous recherchez Koa ou cliquez sur le bouton "Voir les détails de koa" dans la capture d'écran ci-dessus, vous pouvez le trouver. Voir la capture d'écran ci-dessous.

J'avais donc tort. Sonatype a les informations dans la base de données. Le problème vient donc de la couche de présentation. Il serait préférable qu'ils aient les versions affectées répertoriées sur la page où la vulnérabilité est réellement discutée afin que nous puissions voir et vérifier si nécessaire.

J'ai accusé à tort Sonatype OSS Index de ne pas avoir les informations de version. J'ai également accusé à tort Dependency Track d'être disposé à signaler uniquement sur la base du nom de la dépendance si les informations de version n'étaient pas disponibles. (Il me reste à savoir si cette dernière est vraie ou fausse, je n'ai pas vérifié.)

N'abandonnez pas tout de suite ! Les choses les plus intéressantes à discuter sont la vulnérabilité réelle et les modifications (espérons-le) à venir du rapport de vulnérabilité dans l'index OSS. Commençons par la vulnérabilité.

Script intersite

Sonatype a attribué XSS à Koa sur la base du processus de réflexion ci-dessous.

Koa est l'entité qui écrit l'URL de la réponse HTML, pas le développeur utilisant Koa

Il est tout à fait raisonnable de s'attendre à ce que le développeur valide l'URL fournie, probablement par rapport à une liste d'autorisation, pour empêcher une redirection ouverte et non Koa car Koa n'aurait aucune idée des URL que vous voudriez autoriser ou non. Cependant, en tant que développeur, je ne pense pas avoir à me soucier de la désinfection XSS d'une URL que je transmets à une méthode redirect().

Koa semble se soucier de XSS dans ce contexte car ils ont déjà du code pour l'empêcher, une entité HTML encodant l'URL lorsqu'ils l'écrivent dans le HTML

Je suis d'accord dans une certaine mesure. Je ne suis pas d'accord avec est le suivant, par exemple.

Je ne pense pas que je devrais avoir à m'inquiéter de faire une désinfection XSS pour une URL que je passe à une méthode redirect ()

Si vous transmettez une URL valide et sûre à une méthode de redirection que vous (le développeur) avez fournie, vous n'avez pas à vous soucier de XSS (évidemment). Si vous transmettez entièrement ou partiellement des données fournies par l'utilisateur, c'est quelque chose dont vous devez toujours vous soucier, que vous soyez développeur ou professionnel de la sécurité. Pourtant, il n'est pas exagéré de s'attendre à ce que Koa aide le développeur.

Permettez-moi de vous donner un excellent exemple qui, je l'espère, aide à comprendre d'où je viens. Dans l'exemple ci-dessous, je transmets les données fournies par l'utilisateur au navigateur dans le corps de la réponse. Je le fais sans aucune validation, désinfection ou encodage.

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = ctx.query.payload;
});

app.listen(4444);

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=<img%20src=x%20onerror=alert(1)> HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 28
< Date: Wed, 23 Nov 2022 10:59:17 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
<img src=x onerror=alert(1)>%

• Pensez à quoi et comment je passe au navigateur dans le corps de la réponse
• Considérez (et probablement mieux contrôler explicitement !) la valeur de l'en-tête Content-Type pour la réponse
• Sachez que Koa, par défaut, ajuste automatiquement la valeur de l'en-tête Content-Type en fonction de la valeur passée à ctx.body. (Essayez de transmettre, par exemple aaa, et voyez comment cela change)

Si l'on considère l' ctx.bodyexemple « XSS » ci-dessus, il semble que nous reprochions à Koa d'avoir mis en œuvre des mesures spécifiques pour prévenir une catastrophe lors de l'utilisation de ctx.redirect(). Citant encore Sonatype :

Koa semble se soucier de XSS dans ce contexte car ils ont déjà du code là-bas.

Cela signifie-t-il que si Koa ne se souciait pas de XSS dans ce contexte, de la même manière qu'ils ne s'en souciaient pas (et ne devraient pas) s'en soucier en ce qui concerne ctx.body, personne ne l'aurait signalé comme une vulnérabilité XSS ? C'est assez drôle. J'ai remarqué quelques similitudes avec mon analyse précédente sur Formidable documentée ici et ici .

Après avoir dit tout ce que j'ai dit jusqu'à présent, il se trouve qu'un XSS est là… et pas en même temps. Comment est-ce possible? Simple! Il est là, mais vous ne pouvez pas l'exploiter à moins que :

1. La victime utilise un ancien navigateur Web, ET
2. Il existe une redirection ouverte implémentée par le développeur à l'aide de Koa's ctx.redirect(), AND
3. Le développeur fait entièrement confiance à toutes les données fournies par l'utilisateur et les transmet textuellement àctx.redirect()

La page de rapport de Sonatype indiquait, comme vous pouvez le voir sur la capture d'écran d'aujourd'hui, "Ouvrir la redirection menant au Cross-Site Scripting". Mon message précédent remettait en question la partie "redirection ouverte":

Tout d'abord, il n'y avait pas de redirection ouverte. Il n'est ouvert que si vous l'ouvrez et la différence entre les deux PoC (l'original et le mien) le montre clairement.

Sonatype convient également que Koa n'est pas responsable d'empêcher les redirections ouvertes. Leur préoccupation, ma préoccupation et la principale préoccupation de tous les autres était le XSS. Impliquer la redirection ouverte était tout simplement déroutant. En même temps, ce n'était techniquement pas déraisonnable, comme nous le verrons plus tard. (Cela aura également un impact sur le score de vulnérabilité.)

Comme mentionné précédemment, exploiter avec succès le comportement de Koa nécessite une redirection ouverte. Mais:

• Koa n'est pas responsable d'empêcher les redirections ouvertes (comme conclu précédemment)
• Koa ne s'exécutera pas ctx.redirect()sans l'accord du développeur
• Koa n'oblige pas les développeurs à utiliser des redirections

Il existe donc une autre couche de protection : les cas d'utilisation. Quelle est la probabilité qu'un développeur ne veuille pas contrôler l'endroit où un navigateur est redirigé ? Très improbable. Cela signifie que, très probablement, les développeurs transmettront des données contrôlées par l'utilisateur à ctx.redirect()ajouter à un autre morceau de chaîne. Ainsi, quelque chose de similaire aux exemples ci-dessous est le plus susceptible de se produire :

ctx.redirect(`http://website.example.org/search?q=${userInput}`);
ctx.redirect(`/search?topic=${userInput}`);

Score de vulnérabilité

Trois (3) conditions doivent être remplies pour que le bogue soit exploitable, comme indiqué à la fin de la section précédente.

• La version de navigateur utilisée dépend de l'utilisateur final
• L'utilisation de la méthode de redirection et la manière dont elle est utilisée dépendent du développeur

Ce qu'il faut également souligner, c'est que l'utilisation de la méthode de redirection de manière non sécurisée est le vecteur d'attaque. Un vecteur d'attaque est nécessaire pour une exploitation réussie. Koa ne fournit pas le vecteur d'attaque ; le développeur le fait.

Corrélons cela avec la définition de « vulnérabilité logicielle » fournie par le NIST :

La partie que je voudrais souligner est "pourrait être exploitée". Prenez Koa comme bibliothèque de logiciels. Pouvez-vous l'exploiter sans créer d'abord le vecteur d'attaque requis ? Non. Ainsi, du point de vue de Koa, une bibliothèque de logiciels, aucun vecteur d'attaque n'est présenté ; sans cela, l'exploitation est impossible. Si nous interprétions strictement la définition (ce que je fais), nous ne pourrions pas appeler le comportement de Koa une vulnérabilité.
Essayons de calculer un score CVSS sans vecteur d'attaque :

Il n'y a pas de score s'il n'y a pas de vecteur d'attaque. Je dirais que cela correspond à la définition de la vulnérabilité logicielle fournie par le NIST.
Expérimentons et créons un scénario imaginaire où un vecteur d'attaque existe.

Il y a encore plusieurs problèmes ici, autres que le vecteur d'attaque imaginaire. La complexité de l'attaque a été définie sur Élevée car une exploitation réussie nécessite un ancien navigateur. Un attaquant doit convaincre les victimes de télécharger et d'installer un ancien navigateur.
En ce sens, l'interaction utilisateur est requise, même si les mesures de base de l'interaction utilisateur ne concernent pas vraiment cela. Dans ce scénario, si l'exploitation du XSS nécessite une interaction de l'utilisateur dépend de la façon dont l'application Web a utilisé les redirections et non de Koa. Il convient également de mentionner que le JavaScript injecté ne s'exécuterait pas tout seul car il nécessitait une interaction de l'utilisateur en premier lieu : cliquer sur le lien dans la réponse HTML.

Alors, que pouvons-nous faire pour forcer un score de vulnérabilité sur cela ? Nous devons sélectionner quelque chose. Un vœu pieux, en supposant le pire, tout ce que vous préférez. Une chose est sûre, vous faites un calcul que vous n'êtes pas censé faire en premier lieu, et le résultat est tellement éloigné de la réalité que je ne trouve même pas les mots.

La prochaine grande chose est l'Impact Metrics. Vous devez savoir ce que l'application Web est sur le point de dire l'impact. Mais nous ne calculons pas un score de vulnérabilité pour une application Web… Compte tenu du contexte, ce XSS n'a aucun impact sur Koa. Koa ne gère ni ne traite les informations confidentielles par elle-même. Le bogue n'a aucun impact sur la disponibilité ou l'intégrité. Cela nous laisse avec le score final de 0,0, même après avoir forcé un vecteur d'attaque dans le calcul.

Donc la question est, rapportons-nous des faits ou de la fiction ?

Sonatype a porté à mon attention les directives officielles pour Scoring Vulnerabilities in Software Libraries , qui ont été publiées en 2019 avec CVSSv3.1. J'avoue que je ne le savais pas, ce qui est à la fois bon et mauvais. Bien parce que cela aurait abouti à un post de diatribe, mauvais parce que peut-être que si je l'avais vu plus tôt, j'aurais perdu tout espoir avant de mettre tant d'efforts à essayer d'expliquer que ce n'est pas la bonne façon de procéder. Alors, que disent les directives officielles ?

Lors de la notation de l'impact d'une vulnérabilité dans une bibliothèque… L'analyste doit noter le pire scénario de mise en œuvre raisonnable. Lorsque cela est possible, les informations CVSS doivent détailler ces hypothèses.

La réponse est donc que le score de vulnérabilité est basé sur la fiction.

En outre, qu'est-ce qu'un « scénario de mise en œuvre raisonnable dans le pire des cas » ? Si nous avons analysé de nombreux projets utilisant Koa et constaté que la plupart des développeurs implémentaient des redirections ouvertes en utilisant la ctx.redirect()méthode de Koa, il pourrait être raisonnable de supposer le pire. J'ai effectué une recherche rapide de code dans les projets JavaScript ctx.redirect(sur GitHub. J'ai obtenu 16 827 résultats de code. En cherchant context.redirect(j'ai reçu 15 751 résultats de code. Ce serait 32 578 résultats de code à analyser. Certains d'entre eux utiliseront Koa, d'autres Express et d'autres encore. (Bien sûr, le contexte peut être appelé par n'importe quel nom, pas seulement ctxou context, donc il pourrait y avoir encore plus de code à regarder.)

La question est la suivante : est-ce que la transmission de données fournies par l'utilisateur sans cervelle est si fréquente ? J'ai adopté une approche semi-automatisée de l'analyse en écrivant un petit script pour vérifier tous les projets qui correspondaient aux critères de recherche. Malheureusement, je n'ai pas pu dépasser les 1 000 premiers hits car GitHub a rejeté d'autres demandes :

{
    "message":"Only the first 1000 search results are available",
    "documentation_url":"https://docs.github.com/v3/search/"
}

Sur la base de ce que j'ai vu et compte tenu de ce qui est discuté dans la section suivante ("L'ancien navigateur Web"), je ne pense pas qu'il soit raisonnable de supposer qu'une implémentation dans le pire des cas serait raisonnable. Pas dans ce cas précis.

Les directives officielles indiquent également que :

Lors de la notation d'une vulnérabilité dans une implémentation donnée à l'aide de la bibliothèque impactée, le score doit être recalculé pour cette implémentation spécifique.

C'est raisonnable et atténue dans une certaine mesure l'aspect science-fiction de la situation. C'est ainsi que ce problème de Koa, avec le score de vulnérabilité de 9,8, a fini par être de 0,0 dans notre cas.

La bonne chose est que Sonatype a convenu que le score de vulnérabilité de 9,8 était déraisonnable, et ils sont prêts à le réduire. Je l'apprécie, et probablement beaucoup d'autres aussi.

De plus, Sonatype m'a dit que lorsqu'ils ont ajouté le problème à leur système, ils pensaient qu'il serait préférable que leurs clients soient au courant de cette situation potentiellement inattendue. Ils ont dit, "il valait mieux alerter que d'ignorer ce que nous avons vu et avoir potentiellement un résultat négatif". Et, bien sûr, ils avaient raison.

Je ne me suis jamais demandé si les problèmes de sécurité devaient être communiqués ou non. Oui, les problèmes de sécurité doivent être rendus visibles. Ce qui m'inquiète, c'est la façon dont ces problèmes sont communiqués :

• Est-il approprié d'appeler quelque chose une vulnérabilité ou plus approprié de l'appeler une faiblesse de sécurité ou un comportement par défaut non sécurisé, et ainsi de suite ?
• Le score de vulnérabilité attribué est-il raisonnable ?
• Suffisamment de détails et de contexte sont-ils fournis ?

Parlons maintenant un peu des anciens navigateurs Web.

L'ancien navigateur Web

Sans les bonnes personnes de Sonatype, je n'aurais pas pensé aux anciens navigateurs Web, probablement plus jamais.

Je continuerai à ne pas considérer les anciens navigateurs à l'avenir également. Tout d'abord, il y a trop de choses à garder à l'esprit ; Je ne peux pas m'inquiéter des anciens navigateurs Web. Deuxièmement, quel âge a ( ne cliquez pas sur le lien si vous n'avez pas le sens de l'humour ! ) un ancien navigateur Web ? Que signifie vraiment "ancien" ? Si quelqu'un n'utilise qu'un navigateur d'environ 1 an, il est fort probable qu'il ait déjà des problèmes beaucoup plus importants que XSS.

Pourtant, j'ai fait quelques recherches et j'ai trouvé que:

• Google Chrome 48.0.2564.109 (64 bits) de 2016 (!) n'affichait même pas le corps de la réponse. Comme le problème de Koa a été découvert en 2018, je pensais que remonter jusqu'en 2016 devrait suffire, mais il s'est avéré que ce n'était pas le cas.
• Firefox 4.0 de 2011 affichait le corps de la réponse, mais les utilisateurs devaient cliquer sur le lien pour que la charge utile JavaScript s'exécute. (Bien sûr, c'est un lien!)
• Firefox 52.0 de 2017, 1 an avant que le problème Koa XSS ne soit signalé, n'affichait déjà pas le corps de la réponse avec la charge utile JavaScript. Firefox vient de lancer une erreur indiquant "Erreur de contenu corrompu" en raison d'une "violation du protocole réseau".

Koa 0.0.1 est sorti en 2013, il y a donc eu quelques années où le problème aurait pu être exploité. À partir de là, il serait probablement acceptable de signaler ce problème (toujours pas avec un score de 9,8) jusqu'à Koa 2.5.0 en 2018. Après cela, cependant, rien ne justifie quoi que ce soit au-dessus de 1.0.

En fouillant, j'ai trouvé quelque chose d'intéressant sur Wikipédia . Permettez-moi de citer :

Firefox 15 est sorti le 28 août 2012… Firefox 15 a introduit des mises à jour silencieuses, une mise à jour automatique qui mettra à jour Firefox vers la dernière version sans en avertir l'utilisateur, [65] une fonctionnalité que les navigateurs Web Google Chrome et Internet Explorer 8 et supérieur ont déjà mis en œuvre

Ainsi, tous les principaux navigateurs Web disposaient d'une fonction de mise à jour automatique avant la sortie de la première version de Koa, ce qui signifie qu'il est probable que la majorité des utilisateurs utilisaient un navigateur Web à jour. Voyons l'état au moment du « big bang » : 2013.

• Firefox 15 : A renvoyé une erreur indiquant « Erreur de contenu corrompu », ce qui signifie que le corps de la réponse n'a pas été affiché à l'utilisateur.
• Chrome 24.0.1312 (WebKit 537.17) : Il n'affichait aucun corps de réponse. En regardant l'onglet réseau des outils de développement, il n'y avait presque rien de visible, j'ai donc dû exécuter Wireshark pour voir si le navigateur exécutait la demande en premier lieu. Dans Wireshark, il était visible que Chrome avait contacté mon service PoC et avait reçu la réponse avec la charge utile JavaScript. Il n'a pas rendu le corps de la réponse. Mieux encore, il ne s'est rien passé.
• Internet Explorer 11 (11.0.9600.19180) : Il a récupéré la réponse de mon service PoC, que j'ai vérifié à l'aide de Wireshark. Il n'a pas montré le corps de la réponse à l'utilisateur. Il est revenu avec la page d'erreur intégrée classique qui dit : « Cette page ne peut pas être affichée ».

Après avoir fait les recherches ci-dessus, revenons une seconde à une citation de Sonatype :

Koa semble se soucier de XSS dans ce contexte car ils ont déjà du code pour l'empêcher, une entité HTML encodant l'URL lorsqu'ils l'écrivent dans le HTML

Bien que cette affirmation soit correcte, le fait qu'aucun des principaux navigateurs n'autorisait l'exploitation au moment de la sortie de la première version de Koa, la citation suggère quelque chose d'intéressant, autre chose que ce que la phrase voudrait suggérer. Veuillez noter que je suis sur le point d'écrire des spéculations car je ne peux pas savoir précisément comment les développeurs de Koa pensaient. Je peux facilement imaginer que le ou les développeurs ont testé le comportement en question à l'aide d'un navigateur Web à jour. Ils ont peut-être trouvé que l'encodage HTML convenait car il était déjà impossible d'obtenir du code JavaScript injecté exécuté à partir de la hrefpropriété duaétiquette. Cela soulève une question sérieuse. Ayant passé les cinq dernières années de plus du côté du développement logiciel, cela s'applique également à moi : en tant que développeur, si je suis sur le point de créer une nouvelle technologie Web pour le côté backend, dois-je me soucier des anciens navigateurs Web ? Et si je devais, quelle est la recommandation officielle de la communauté de la sécurité concernant la date à laquelle je dois remonter dans le temps pour considérer les anciens navigateurs Web ? Ne devrions-nous pas considérer que la meilleure pratique de sécurité pour les utilisateurs finaux consiste à maintenir leur navigateur à jour, et la fonction de mise à jour automatique est également là pour aider à cela ? De plus, si nous nous attendons à ce que les développeurs gardent à l'esprit et testent avec d'anciens navigateurs, ne pouvons-nous pas nous attendre à ce que les professionnels de la sécurité fassent de même et nomment tous les navigateurs Web et leurs versions qui contribuent à un problème spécifique au lieu de simplement se référer aux "anciens navigateurs". ” ? Ce ne serait que juste.

Une chose est sûre, il n'y a plus rien à craindre depuis des années maintenant...

Le navigateur moderne

Dans mon analyse, à l'aide de mon navigateur Web, j'ai vérifié le corps de la réponse et je l'ai trouvé vide. Je n'ai pas vérifié si la réponse envoyée par fil avait un corps. Il s'avère que c'est juste Google Chrome qui a complètement ignoré le corps de la réponse ; par conséquent, cela ne s'est pas montré. C'etait assez bon pour moi. Raisonnablement, je dois ajouter.

Depuis lors, j'ai regardé la réponse de mon service Web de test en utilisant la dernière version de Koa. Nous pouvons voir ci-dessous qu'il y avait un corps de réponse HTML avec le code JavaScript injecté :

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=javascript:alert(1); HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: javascript:alert(1);
< Content-Type: text/html; charset=utf-8
< Content-Length: 71
< Date: Tue, 22 Nov 2022 17:55:12 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="javascript:alert(1);">javascript:alert(1);</a>.

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=%22><%2f HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: %22%3E%3C/
< Content-Type: text/html; charset=utf-8
< Content-Length: 61
< Date: Tue, 22 Nov 2022 22:18:49 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="&quot;&gt;&lt;/">&quot;&gt;&lt;/</a>.

Changements à venir

Vous trouverez ci-dessous la liste des mises à jour que Sonatype prévoit de mettre en œuvre concernant ce problème :

• Mise à jour de la ligne Résumé/Titre pour éliminer les malentendus (déjà arrivé)
• Réduire le score de vulnérabilité à 4,7 (déjà arrivé)
• Mentionnez que la vulnérabilité ne peut être exploitée que si un utilisateur utilise un navigateur plus ancien

Modifications supplémentaires que j'aimerais voir

En plus des changements mentionnés dans la section précédente, certaines choses pourraient encore être améliorées. Ceux-ci sont:

• Réduire davantage le score de vulnérabilité, en particulier pour les versions Koa publiées après 2018.
• Y compris le numéro de version d'au moins les principaux navigateurs Web et leurs dates de sortie incluses dans le rapport lorsqu'il s'agit des « anciens navigateurs ». Cela aiderait considérablement n'importe qui lors de "l'évaluation d'une vulnérabilité dans une implémentation donnée à l'aide de la bibliothèque impactée". Par exemple, si j'avais vu qu'un utilisateur devait utiliser un navigateur à partir de 2011, j'aurais marqué le problème comme "non affecté" dans SCA en une seconde. C'est beaucoup de temps gagné.
• Les versions de Koa concernées doivent être listées sur la page de la vulnérabilité .

Soit dit en passant, Sonatype a également mentionné avoir des vérifications intéressantes dans son offre commerciale qui, par exemple, effectuent de véritables vérifications au niveau du code pour voir si une application a été affectée par les vulnérabilités signalées. Cela semble bien, et compte tenu de la nature scientifique de la façon dont les scores de vulnérabilité sont calculés pour les bibliothèques, ces types de vérifications sont indispensables pour réduire la charge des équipes d'ingénierie, surtout si les choses continuent comme ça.

Conclusion

C'est à peu près toutes les mises à jour que j'ai. Je suis content d'avoir contacté Sonatype car ils sont très professionnels et sympathiques. Ce fut un plaisir de travailler avec eux sur ce sujet.

Concernant le XSS en Koa : c'est quelque chose dont aucun d'entre nous n'aurait dû s'inquiéter depuis plusieurs années maintenant.