Nombreux sont les sites web qui font appel à des bibliothèques JavaScript tierces obsolètes

Nombreux sont les sites web qui font appel à des bibliothèques JavaScript tierces obsolètes
et sont donc vulnérables à des attaques

Selon une recherche menée par une équipe de scientifiques du College of Computer and Information Science de Northeastern (située à Boston, dans le Massachusetts, aux États-Unis), les fonctionnalités de site web dépendant de bibliothèques JavaScript tierces (comme JQuery) peuvent créer des vecteurs d’attaques, exposant les sites web qui les utilisent à des attaques.

Ils ont effectué une étude sur l’utilisation côté client des bibliothèques JavaScript et l’implication résultante sur la sécurité sur le web. « En utilisant des données provenant de plus de 133 000 sites web, nous avons montré que 37 % d'entre eux comprennent au moins une bibliothèque avec une vulnérabilité connue », ont-ils assuré.

« Bien que JavaScript soit la norme de facto pour le développement client sur le Web, ses vulnérabilités de sécurité sont de notoriété publique. L’un des problèmes courants et persistants est le Cross-Site Scripting (XSS), qui permet à un attaquant d’injecter du code malveillant (ou HTML) dans un site Web. En particulier, si une bibliothèque JavaScript accepte l'entrée de l'utilisateur et ne la valide pas, une vulnérabilité XSS pourrait s'infiltrer, et tous les sites Web utilisant cette bibliothèque pourraient devenir vulnérables », ont noté les chercheurs.

Ils ont expliqué qu’étant donné qu’il y a des milliers de bibliothèques JavaScript (ils se sont appuyés ici sur la communauté cdnjs.com qui affichait 2379 projets en août 2016), il est préférable pour eux de se focaliser sur les plus populaires étant donné qu’elles seront plus représentatives et donc plus conséquentes. En tout, ils se sont concentrés sur 72 bibliothèques qui leur ont permis de couvrir 73 % des bibliothèques les plus populaires, d’après l’outil d’analyse Wappalyzer.

Dans le catalogue qu’ils ont constitué, ils ont noté que les bibliothèques populaires comme Angular et jQuery ont respectivement jusqu'à 110 et 66 versions distinctes, bien que la moitié des bibliothèques disposent de moins de 26 versions.

http://www.developpez.com/public/ima...raction-js.png

Qu’en est-il des bibliothèques vulnérables ?

Pour avoir une vue représentative de l’utilisation de JavaScript sur le web, les chercheurs ont fait des collectes sur deux échantillons de données via des indexations automatisées : le premier était constitué des 75 000 sites figurant en tête de liste sur le baromètre Alexa, le second était constitué de 75 000 sites pris au hasard dans la zone .com. « Nous avons effectué les deux indexations automatisées en mai 2016 sur des adresses IP dans une gamme de / 24 aux États-Unis. Nous avons observé un taux d’échec d’environ 5 % et 17,2 % respectivement dans ALEXA et COM, ce qui nous a laissés avec des données issues de 71 217 et 62 086 domaines uniques ».

« Bien qu’il n’y a que 21 % des sites figurant dans le Top 100 qui utilisent une bibliothèque affichant une vulnérabilité connue, ce pourcentage augmente à 32,2 % dans le Top 1000 pour se stabiliser dans le Top 5000 et rester autour de la moyenne globale de 37,8 % pour tous les 75 000 sites Web. Cela indique que même les sites relativement importants (mais pas les plus importants) ont un taux de vulnérabilité comparable à la moyenne des sites figurant dans COM, qui est dominé par de petits sites ».

Les chercheurs ont trouvé que, du côté d’Alexa, 36,7 % des inclusions jQuery ont au moins une vulnérabilité connue, 40,1 % du côté d’Angular, 86,6 % pour Handlebars et 87,3 % pour YUI 3. Du côté de COM, cette proportion passe respectivement à 55,4 %, 38,7 %, 87,5 % et 13,7 %.

http://www.developpez.com/public/ima...js-connues.png

Les chercheurs se sont également intéressés à la question de savoir la vitesse à laquelle les bibliothèques tierces JavaScript sont mises à jour sur les sites. Ils ont exprimé ce temps en nombre de jours. Sur les sites référencés par Alexa, la médiane était de 1476 jours pour les sites JQuery disposant d’une vulnérabilité connue (soit plus de 4 ans) et 2243 jours du côté de COM (soit plus de 6 ans). Les sites s’appuyant sur ces bibliothèques sont donc restés vulnérables tout ce temps.

http://www.developpez.com/public/ima...Maj-js-lib.png

Les bibliothèques JavaScript tierces, telles que Angular, Bootstrap et jQuery, sont fréquemment utilisées sur les sites Web aujourd'hui. Bien que de telles bibliothèques permettent aux développeurs Web de créer des applications hautement interactives ainsi que des sites web visuellement attrayants, les vulnérabilités dans ces bibliothèques pourraient augmenter la surface d'attaque des applications/sites Web qui dépendent d’elles. Par conséquent, il est très important de s'assurer d’utiliser les versions récentes et corrigées de ces bibliothèques.

Source : résultat de l'étude (au format PDF)

Voir aussi :

:fleche: Une attaque JavaScript ciblant les unités de gestion de mémoire permet de contourner la protection ASLR sur au moins 22 microarchitectures de CPU
:fleche: JavaScript : Twitter a transféré tout son trafic mobile vers un nouveau stack Node.js, Express et React

Tellement évident et pourtant, suis le premier a ignorer ces mises a jour. Merci pour topic.

:applo:

Regle simple :

• Ne jamais faire confiance a une requete venant d'un autre ordinateur (client, serveur, calculatrice, prise electrique, object connecte, ...)
• La prestation informatique n'a jamais ete gratuite
• L'entreprise n'a que faire de la securite. C'est une telle evidence ...

Personnelllement, l'etude peut interessante, car on doit savoir qu'elle est le pourcentage de site infecte. Par contre, la conclusion est tellement evidente avant meme cette etude. Il y a rien a faire, a part demander au navaigateur d'identifier les sites a risques. Peut-etre cela fera reagir les proprietaires. Apres-tout ils l'ont bien fait avec le https.

Citation:

---

Envoyé par koyosama

Regle simple :
a part demander au navaigateur d'identifier les sites a risques. Peut-etre cela fera reagir les proprietaires. Apres-tout ils l'ont bien fait avec le https.

---

Ca c'est une super idée, comme ça les hacker n'auront même plus à devoir chercher quelles sont les technologies et versions sur le serveur.

J'ai toujours pris l'habitude de concevoir un site sans utiliser JS. Une fois le site terminé j'ajoute une surcouche en pure JS pour l'ergonomie.

Ça rend le dev un peu plus lent et complexe mais je trouve cette approche très satisfaisante.

@Gecko,

Tu gagnes tellement en productivité en utilisant des frameworks tels qu'Angular que je ne peux pas approuver cette vision où tu te contrains à faire du JS pure.
Faire du JS pure c'est dans l'idéal des choses, mais si faire du JS pure suffisait, des frameworks tels que jQuery ou moment n'auraient jamais existé pour assurer la compatibilité inter-navigateurs+versions ou faciliter le développement.
Ré-écrire du JS ne te rendra ni plus safe (penses-tu créer moins de bug que d'autres ?), ni plus ergonomique (comment fais-tu sans appels XHR en 2017 ? En utilisant ActiveXObject et XMLHttpRequest ?)

A+

Citation:

---

Envoyé par yildiz-online

Ca c'est une super idée, comme ça les hacker n'auront même plus à devoir chercher quelles sont les technologies et versions sur le serveur.

---

Ils ont deja cette outils. Je ne vois pas ce qui est choquant. Et la securite par l'obscurite, c'est la chose qu'on repete 50000 fois, que cela sert a rien. Sans compter que le hacker n'a plus besoin de chercher maintenant.
Ils se parlent entre eux, ont des commerce entre eux.

Et apres avoir lu x articles, etudes, ... La securite vu par les developeurs et les utilisateurs de sites sont juste obsolete. Le but comme les accidents de la route est de reduire la negligence.

Personnellement, je trouve debile qu'un hacker doit faire du click par click pour decouvrir un site est pas securise quand il peut faire un mega robot avec une base de donees de failles qui detectent. En plus la plupart des antivirus fait ce genre de chose deja. Je trouve ce raisonement absurde.

Citation:

---

Envoyé par koyosama

Ils ont deja cette outils. Je ne vois pas ce qui est choquant. Et la securite par l'obscurite, c'est la chose qu'on repete 50000 fois, que cela sert a rien. Sans compter que le hacker n'a plus besoin de chercher maintenant.
Ils se parlent entre eux, ont des commerce entre eux.

---

T'as pas un peu l'impression de tout mélanger? il y a une différence entre la sécurité par l'obscurité de son artefact(donc maîtrisé), et cacher l'environnement sur lequel on tourne (sur lequel on a pas un contrôle total)

Tu détectes une faille dans ton code, tu coupes, tu fixes, tu releases, c'est ta responsabilité, et utiliser l'obscurité pour ne pas faire ça ne sert à rien effectivement.
Tu détectes une faille dans un composant de ton écosystème, tu fais quoi? tu l'annonces à tout le monde et tu coupes jusqu'a ce que le composant aie été patché?

Ce qui est répété 50 000 fois sur la sécurité d'un système, c'est bien de ne pas en divulguer les composant et leur version:

quelques exemples pris au hasard pour apache httpd:

https://doc.ubuntu-fr.org/tutoriel/securiser_apache2
https://technique.arscenic.org/lamp-...eu-de-securite
https://wiki.debian-fr.xyz/S%C3%A9curiser_Apache2
http://supertos.free.fr/supertos.php?page=1675

j'arrête là, vu qu'ils disent tous la même chose: masquer les composants et versions du système

Citation:

---

Envoyé par Gugelhupf

@Gecko,

Tu gagnes tellement en productivité en utilisant des frameworks tels qu'Angular que je ne peux pas approuver cette vision où tu te contrains à faire du JS pure.
Faire du JS pure c'est dans l'idéal des choses, mais si faire du JS pure suffisait, des frameworks tels que jQuery ou moment n'auraient jamais existé pour assurer la compatibilité inter-navigateurs+versions ou faciliter le développement.
Ré-écrire du JS ne te rendra ni plus safe (penses-tu créer moins de bug que d'autres ?), ni plus ergonomique (comment fais-tu sans appels XHR en 2017 ? En utilisant ActiveXObject et XMLHttpRequest ?)

A+

---

Le problème, c'est que très souvent, il n'y a pas besoin de javascript quelconque sur le site.
Il suffit de voir un peu ce qu'apporte CSS3 et HTML5, ainsi qu'à quoi sont employés les librairies les plus utilisées.

Dans la plupart des cas, il s'agit simplement d'animation, et dans la grande majorité des cas du cas de l'animation, c'est possible de le faire en CSS3.
L'arrivée de librairies comme JQuery ont permis l'unicité de plusieurs bases de code à travers plusieurs navigateurs, à un moment où chaque navigateur faisait "ce qu'il voulait", ce qui aboutissait à des implémentations et des comportements très souvent différents.

Le concept de webapp peut être utile dans certains cas, mais cette mode du "cloud" et de tout utiliser sous forme de webapp (je vise aussi les desktop apps basées sur un serveur embarqué, tels que Slack, Atom.io ou encore Visual Studio Code, héritier de Atom.io à ses débuts, si je me souviens bien) rajoute énormément de problèmes de sécurité potentiels, ainsi que de compatibilité.
Des programmes tels que Excel ou Word, des éditeurs graphiques comme draw.io (un excellent éditeur tout de même, je dois le dire) ou encore des programmes permettant de "composer de la musique en ligne" sont, en soi, inutiles et très limités, ils nécessitent beaucoup de javascript, énormément de chargement côté client (et un chargement du site global très gros, rendant ledit chargement lent, voire interminable sur les connexions les plus hasardeuses) et nécessitent aussi de maintenir une base de code disponible uniquement dans 1 seule catégorie de technologies/outils (ou plusieurs technologies, selon le cas d'utilisation, mais ça reste très limité).

On se retrouve donc, avec ces webapps, avec un chargement lourd, lent, "gros", un projet souvent difficile à maintenir, l'utilisation forcée d'Internet pour utiliser les webapps (cet argument n'étant bien entendu pas valable pour les desktop apps sur serveur embarqué décrites dans le concept) et un gros potentiel de sécurité perdue, avec une perte plus grande à chaque nouveau script intégré au projet, chaque script étant un nouveau maillon pouvant affaiblir la chaine de dépendances globales du fonctionnement de l'app.
Le dernier problème pouvant être apporté étant évidemment le cas où le site distant où sont chargés les scripts serait hors-ligne ou indisponible, ou si le script requis n'est plus accessible;
la solution d'héberger soi-même chacune des dépendances reste impossible à mettre en oeuvre à terme, tout simplement parce que plus il y a de scripts à charger, plus le serveur hébergeur nécessitera de puissance pour satisfaire les requêtes en nombre important pour chaque chargement de page (pouvant être pallié par vérification avec un hash ajouté au fichier par exemple, pour pouvoir stocker la version voulue en cache), pouvant donc provoquer (provoquant donc, dans la plupart des cas) un self-inflicted DDOS, qui serait assez ironique bien évidemment.

Aussi, le développement de ces apps est souvent complexe ou lent, vu qu'il utilise dans la plupart des cas un outil qui n'est pas du tout adapté au travail.


Autre point, aujourd'hui, les navigateurs les plus utilisés implémentent tous les APIs et librairies les plus "courantes" (et "primaires") d'une façon dont le fonctionnement résultat est similaire, et seules les APIs/librairies les plus "exotiques" auront une implémentation différente chez certains navigateurs, voire une absence totale d'implémentation (Je prend par exemple la norme WebRTC ainsi que la librairie webrtc javascript, implémentée aujourd'hui en partie par les grands habituels, Chrome et Firefox, et en cours de complétion, où Safari (oui, il est encore vivant :P) a tout simplement refusé d'implémenter cette norme, sans raison apparente (Coup de flemme des développeurs ? Ou simplement Apple qui continue dans sa lancée pour mettre le plus de bâtons dans les roues de ses développeurs ? A voir, mais ce n'est pas le débat présent ici.)).
D'autres navigateurs comme Safari ou Internet Explorer n'implémentent qu'assez peu des librairies "récentes", mais dans ces cas:
IE reste un navigateur assez présent dans l'administration (allez savoir pourquoi... Il semblerait que la raison de cette présence est des vieux sites dont les organismes gestionnaires ne veulent pas s'occuper, qui ne verront donc sans doute jamais de mise à jour), mais étant un navigateur officiellement "mort", il est tout à fait légitime (et même recommandé dans tout cas apportant un risque de sécurité ou de protection de vie privée de l'utilisateur) de refuser d'implémenter un set de fonctionnalités compatibles avec ce navigateur, et d'afficher une belle fenêtre d'avertissement (ou d'alerte) indiquant l'obsolescence de ce navigateur ainsi qu'un risque d'atteinte à la sécurité de l'utilisateur.
Safari par contre, est officiellement encore en développement, mais il implémente tellement "peu" de normes qu'il serait aussi légitime d'afficher une alerte, pour les mêmes raisons citées pour la partie IE. Par contre, il me semble que l'userbase de ce navigateur est plus présente.


Concernant `XMLHttpRequest`, c'est (toujours) la librairie utilisée pour faire de l'AJAX, même dans la plupart des cas recommandée (Lien MDN), son utilisation est très simple, elle est compatible avec les nouveaux concepts d'asynchrone et de promise introduits avec l'ES2015 et ses implémentations sur les navigateurs les plus récents reste légère, performante et "sécurisée".


Pour ma part, je conçois aussi généralement mes sites sans l'utilisation de Javascript, et les rares cas où j'en aurai besoin, je travaille avec du vanilla js (natif), et à ce jour, je n'ai pas eu de problèmes dans le cas où le projet sur lequel je travaille prendrait de l'ampleur, ayant toujours gardé mon code source clair, "simple" et bien découpé.

CSS3 et HTML5 sont là, mais les clients ne suivent pas*, tu n'imagines même pas le nombre de fois où il m'arrive de checker si une fonctionnalité est supportée ou non par IE, d'où la nécessité d'utiliser des librairies.

Je comprends les gens qui ne sont pas trop fan de JS, mais c'est dommage de vouloir limiter son utilisation, ce qui le rend mauvais ce sont surtout les navigateurs, JS reste un langage.

* : support d'Internet Explorer exigé pour mon cas


A+

Citation:

---

Envoyé par yildiz-online

https://doc.ubuntu-fr.org/tutoriel/securiser_apache2
https://technique.arscenic.org/lamp-...eu-de-securite
https://wiki.debian-fr.xyz/S%C3%A9curiser_Apache2
http://supertos.free.fr/supertos.php?page=1675

j'arrête là, vu qu'ils disent tous la même chose: masquer les composants et versions du système

---

La tu essaies securiser la communication entre le navigateur et serveur. Sauf que voila cette securite ne marche pas si tu utilise pas navigateur.
On parle ici de vielles librairies qui laissent ces failles expres, qui peuvent donnes des comportement innatendues comme envoyer un signal automatique au serveur. Vu que la lib est autorise par le serveur. Le but c'est d'expliquer qu'il faut mettre a jour ces libs. En plus j'ai dit plus haut qu'il faut pas faire confiance aux donnees venant d'un autre serveur qui correspond a la bonne pratque de developpement et complete ton information avec apache. Et merci je sais comment marche le protocol HTTP et les serveurs HTTP.

J'arrive pas comprendre qu'on puisse prevenir les gens, quand le navigateur il faut le mettre a jour, mais les libs javascript non. On le fait pour java et pour flash. Donc non cela me choque pas.

Ensuite je peux voir la stack d'un site, tu peux cacher le serveur mais tu pourras cacher les vielles libs. Tu peux le cacher autant que possible, mais on parle pas de faille serveur mais de faille client. Et pour etre franc, tu as des chances que les meme personnes qui ont laisse les vielles libs sur le site aient pas envie plus que cela de securiser le serveur.

Crois moi prevenir les gens donnent plus d'impact que de rien faire. Un ecosysteme cela change que si les individus changent leur mode consommation. On sait tres bien que le probleme recside plus sur le fait que le code n'est pas compatible aux changements hein ...

Citation:

---

Envoyé par koyosama

La tu essaies securiser la communication entre le navigateur et serveur. Sauf que voila cette securite ne marche pas si tu utilise pas navigateur.

---

Non, tu mélanges tout, ça réduit l'information technique fournie au client, et peu importe que ce client soit un navigateur, un curl, un telnet, le résultat sera le même.

Citation:

---

Envoyé par koyosama

On parle ici de vielles librairies qui laissent ces failles expres,

---

Non, on parle de sites qui utilisent des librairies qui contenant des failles dans d'anciennes versions et qui n'on pas été mise à jour vers une version plus sûre.

Citation:

---

Envoyé par koyosama

J'arrive pas comprendre qu'on puisse prevenir les gens, quand le navigateur il faut le mettre a jour, mais les libs javascript non. On le fait pour java et pour flash. Donc non cela me choque pas.

Ensuite je peux voir la stack d'un site, tu peux cacher le serveur mais tu pourras cacher les vielles libs. Tu peux le cacher autant que possible, mais on parle pas de faille serveur mais de faille client. Et pour etre franc, tu as des chances que les meme personnes qui ont laisse les vielles libs sur le site aient pas envie plus que cela de securiser le serveur.

Crois moi prevenir les gens donnent plus d'impact que de rien faire. Un ecosysteme cela change que si les individus changent leur mode consommation. On sait tres bien que le probleme recside plus sur le fait que le code n'est pas compatible aux changements hein ...

---

Ce que tu sembles ne pas comprendre, c'est que centraliser l'information sur les sites vulnérables ne peut que compromettre leur sécurité, si un site n'est pas mis à jour, cela peut être du à plusieurs raisons, tu n'as peut être jamais eu d'audit de sécurité sur tes logiciels, mais si c'était le cas, tu saurais que dans certains cas, il y a des mises à jour que l'on ne peut pas faire(pour des questions de coût de l'opération), et qu'alors, on accepte le risque en connaissance de cause, ce risque est basé sur 2 facteurs, la criticité de la faille, et la probabilité d'en être victime.

En centralisant les informations sur les sites, tu augmentes la probabilité d'en être victime, sans fournir de solution viable pour fixer le problème, tu réduis donc drastiquement la sécurité.