Ma frustration est au plus haut car cela vient de se reproduire. Si vous avez lu mon analyse précédente intitulée CVE-2022–29622 : (In)vulnerability Analysis , vous vous doutez peut-être à quoi je fais référence. Même histoire, autre victime. Cependant, les dates sont importantes dans ce cas. Ma précédente analyse d'invulnérabilité date de 2022, aujourd'hui je vais analyser un autre problème de 2018.

Vous pouvez demander : "Pourquoi devez-vous faire face à quelque chose de 2018 ?" Excellente question ! Parce que j'ai récemment activé Dependency Track pour extraire les informations de vulnérabilité de l'index OSS de Sonatype.

Aujourd'hui, alors que je parcourais SCA pour voir si nous avions des composants vulnérables, et si c'était le cas, prioriser les travaux de remédiation. Je suis tombé sur quelque chose de très surprenant. Koa.JS a une vulnérabilité critique ?! Après mon habituel "#FFS, toute ma semaine a besoin d'être réorganisée.", je me disais : "Respirez profondément et regardez de quoi il s'agit. Tu te souviens de ce qui s'est passé la dernière fois..."

Et c'est ce que j'ai fait. Tout d'abord, le titre indique clairement que le "problème" a été trouvé en 2018. Maintenant, pourquoi aurais-je une vulnérabilité dans une bibliothèque qui est toujours maintenue et que je continue à mettre à niveau vers la dernière version ? À ce stade, la partie investigatrice de mon cerveau s'est déclenchée.

Que sait-on/voit-on à ce stade ?

1. Il y aurait eu une vulnérabilité dans Koa en 2018 avec une gravité critique attribuée
2. Selon Sonatype OSS Index et Dependency Track, le problème m'affecte en 2022 lors de l'exécution de la dernière version de Koa

• Quelles versions de la bibliothèque Koa.JS ont été affectées par la "vulnérabilité"
• Si la "vulnérabilité" est présente dans le dernier Koa.JS

Analyse des problèmes

Voyons ce qu'est/était la "vulnérabilité". Permettez-moi de lier rapidement le problème connexe # 1250 de GitHub ici. Je vais simplement copier-coller l'exemple (PoC ?) ci-dessous afin que nous puissions l'analyser.

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

app.use(async ctx => {
  ctx.redirect("javascript:alert(1);")
});

app.listen(3000);

"En tant que développeur d'une application Web ou d'un service Web, je peux rediriger votre navigateur où je veux si vous visitez mon site Web."

C'est ce que signifie le code ci-dessus. Dans le PoC ci-dessus, aucun vecteur d'attaque n'est présenté pour qu'un acteur malveillant puisse exploiter quoi que ce soit.

Si vous vouliez fournir un « PoC » approprié pour cette non-vulnérabilité (oui, je viens de le dire), cela ressemblerait à ceci :

const Koa = require('koa');
const app = new Koa();
// Try: http://localhost:3000/?vector=javascript:alert(1);
app.use(async ctx => {
  ctx.redirect(ctx.request.query.vector);
});

app.listen(3000);

En parlant d'une vulnérabilité XSS, si tout ce que j'ai entré comme valeur du vectorparamètre était affiché dans un contexte HTML de manière non sécurisée, l'application que j'ai implémentée serait vulnérable au Cross Site Scripting. (Plus à ce sujet plus tard)

Zoom sur la façon dont Sonatype a présenté cela et l'analysant un peu plus loin :

"Open Redirect menant à Cross-Site Scripting" ? 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. Dans le premier, il n'y avait pas de vecteur d'attaque, donc il n'y avait pas de redirection ouverte. Mon PoC avait un vecteur d'attaque, pas de filtrage, donc il y avait une redirection ouverte. Mais, comme vous pouvez le voir, qu'il y ait eu ou non une redirection ouverte dépendait de moi, le développeur et non de Koa.JS. Encore mieux, qu'il y ait eu ou non une redirection dépendait aussi de moi. La question de savoir si j'incluais l'entrée fournie par l'utilisateur en tant que/dans l'URL de redirection de manière non sécurisée dépendait également de moi. De quelle vulnérabilité Koa.JS parlons-nous alors ? Techniquement, il n'y avait pas de vulnérabilité et quelqu'un lui attribuait toujours une gravité critique. Pas vraiment professionnel.

Quoi qu'il en soit, «exploitons» ladite «vulnérabilité» mise en œuvre par le bon PoC. Veuillez noter que j'ai dû changer le port de service de 3000 à 4444 car j'avais déjà quelque chose qui écoutait sur le port 3000.

Nous pouvons voir que l' Locationen-tête de réponse a la valeur javascript:alert(1). Ensuite, le navigateur redirige vers…

Hein, je suis en sécurité ! Aucune boîte d'alerte n'apparaissait. Oui, je pourrais entrer https://google.comcomme valeur du vectorparamètre de requête et être redirigé vers Google, donc mon application (PoC) est vulnérable à la redirection ouverte, mais pas à cause de Koa, mais parce que j'ai transmis des données utilisateur non filtrées à ctx.redirect. Ce n'est pas quelque chose qui m'inquiète, je ne ferais jamais ça.

Une chose importante à noter dans les commentaires sur les problèmes sur GitHub est la suivante :

Le problème vient du fait que Koa imprime un lien hypertexte HTML dans le corps de la réponse de redirection et cela peut déclencher une attaque de script intersite.

Ah, ça a un peu plus de sens ! Voyons si c'est toujours le cas.

Non, ce n'est plus le cas. Il n'y a pas de corps de réponse. Je suppose que je peux conclure que cette "vulnérabilité" ne m'affecte pas. Je peux simplement aller le marquer comme faux positif dans Dependency Track.

Analyse de contexte

Je propose "l'analyse de contexte" à adopter par tous les professionnels de la sécurité et à effectuer avant de signaler les "problèmes". Laissez ceci être un autre exemple et vous montrer comment c'est fait. (Je vous recommande tout de même de lire CVE-2022–29622 : Analyse de la (in)vulnérabilité, car cela explique beaucoup mieux l'importance du contexte.)

1. Koa.JS prêt à l'emploi ne vous redirige nulle part. Par conséquent, il y a et il n'y avait pas de "redirection ouverte" comme indiqué par Sonatype OSS Index.
2. Sur la base du "PoC" fourni sur GitHub, il y avait une opportunité pour un développeur de faire quelque chose de stupide qui pourrait conduire à XSS. Mais, voir #1 ci-dessus. Koa.JS n'a fait aucune redirection par lui-même. Voir #2 ci-dessous.
3. Un développeur doit avoir implémenté son application de manière non sécurisée pour que la "vulnérabilité" signalée soit présente. Cela signifie à peu près que Koa.JS même s'il aurait pu faire mieux, vous ne pouvez pas l'appeler vulnérable. C'est contextuellement inapproprié. La vulnérabilité en question ne peut être présente que dans une application Web implémentée de manière non sécurisée .

Permettez-moi de vous donner un exemple de la meilleure façon de gérer des situations comme celle-ci. Regardez ce problème que j'ai soumis à Swagger Parser et comment il a été communiqué. Analysons le rapport de problème :

1. Le titre indique « Comportement de résolution non sécurisé ». Je ne parle pas de LFI (Local File Inclusion) dans le titre. En effet, bien qu'il existe un potentiel d'inclusion de fichiers locaux SI JE MESS CHOSES, c'est vraiment à moi en tant que développeur de savoir avec quoi je travaille et comment je travaille avec. Le comportement par défaut était (peut-être est-il toujours) non sécurisé. Mais, la bibliothèque toute seule, sans mon implication ne fera rien.
2. Ensuite, j'indique clairement de quelle version de la bibliothèque je parle. Je rends le contexte encore plus clair en énumérant les conditions dans lesquelles le comportement par défaut non sécurisé de la bibliothèque affecterait une application. Cela montre assez clairement que la bibliothèque elle-même n'est pas vulnérable, mais elle a un comportement non sécurisé qui peut être amélioré pour aider les développeurs.
3. Maintenant que le contexte est défini, je fournis un PoC fonctionnel, un extrait de code vulnérable (que j'ai écrit en tant que PoC, il ne fait pas partie de Swagger Parser !) et le résultat réel de l'exploitation d'une application/service vulnérable qui utilise le bibliothèque de manière non sécurisée.
4. J'ai fait quelques recherches et j'ai découvert qu'en tant que développeur, je pouvais réellement configurer la bibliothèque de manière à atténuer le problème. (dans une certaine mesure) j'ai partagé cela avec les développeurs. Si rien d'autre, ils peuvent au moins mettre à jour la documentation pour sensibiliser.
5. J'ai fourni un contexte supplémentaire, une analyse et un exemple de la façon dont les choses pourraient être améliorées.

Conclusion

Tout d'abord, Sonatype devrait faire mieux avec l'index OSS et s'assurer que les informations de version sont disponibles pour chaque vulnérabilité dans la base de données. C'est le strict minimum. (Points bonus pour la suppression complète de cette entrée spécifique de la base de données.)

Je soupçonne que Dependency Track souffre de FOMO, par conséquent, il est prêt à signaler les problèmes uniquement en fonction de la correspondance du nom du composant si le numéro de version n'est pas disponible. Je comprends dans une certaine mesure qu'ils ne risqueraient pas de manquer une vulnérabilité critique. Le problème avec ce comportement (faux positifs) est qu'il n'encourage pas l'adoption de l'analyse de la composition logicielle. Cela effrayera les développeurs comme les faux positifs de l'analyse de code statique. Contreproductif.

Contexte! Le contexte sanglant, les gens! Je propose:

1. « Analyse de contexte » à adopter par tous les professionnels de la sécurité et à effectuer avant de signaler des « problèmes »
2. Distinguer les « comportements précaires » de la « vulnérabilité »
3. Comprendre la différence entre une bibliothèque de logiciels et une application/un service