Next - Le site de jQuery compromis, mais les bibliothèques ne sont pas touchées

Via son blog, jQuery vient de confirmer que son site internet avait été compromis il y a quelques jours, mais réfute par contre la contamination de ses bibliothèques, ce qui aurait eu des répercussions bien différentes.

Alors que tout le monde ou presque a les yeux tournés vers l'importante faille de sécurité qui touche le Bash de Linux, Unix et OS X, jQuery a également été victime d'un problème de sécurité. En effet, la société RiskiQ, spécialisée dans la sécurité informatique, annonce que le site jQuery.com aurait été victime d'une attaque, un point que l'équipe en charge du projet n'a visiblement pas été en mesure de confirmer, si l'on en croit ce billet de blog.

Mais nouveau rebondissement quelques heures plus tard : l'éditeur annonce avoir reçu plusieurs rapports concordants et indiquant que l'intégrité du site jQuery.com a bien été compromise. Selon jQuery, il s'agirait par contre d'événements distincts (drôle de coïncidence), mais utilisant le même vecteur d'attaque. Suite à cela, le site a été mis hors ligne, le temps de corriger le souci.

Dans tous les cas, l'équipe en charge du projet tient à préciser un point important : « à aucun moment nous n'avons eu de retours indiquant que des logiciels malveillants avait été distribués à partir de l'un de nos sites, et le code d'aucune bibliothèque jQuery sur notre site ou de nos CDN n'a été affecté ou modifié au cours des dernières semaines ». Une bonne nouvelle car, dans le cas contraire, les répercussions auraient été largement plus dramatiques.

Quoi qu'il en soit, jQuery annonce avoir pris quelques dispositions afin d'éviter que cela ne se reproduise : jQuery.com a migré vers un nouveau serveur et les mots de passe des comptes administrateurs ont été modifiés. Bien évidemment, l'équipe technique est sur la brèche afin de suivre de près l'évolution des événements.

Commentaires (33)

shadowfox

Il y a 9 ans

Des libs jQuery avec des backdoors et autre trucs sympas dispo sur le site officiel, cela ferait de gros dégâts…

hycday

j’ose à peine imaginer ce qu’on peut faire avec une lib jQuery vérolée, dispo sur une infinité de sites….attaques par DDOS, vols de cookies, redirection de physhing etc à peu prêt tout ce qui se fait, concentré en un point. Rien que pour ca, je préfère avoir controle des fichiers et ne jamais faire appel à des library hebergées ailleurs.

gvosnet

Voilà par exemple une bonne raison de ne pas faire pointer ses sites directement vers les libs de jQuery mais plutôt enregistrer les versions et les héberger sur ses propres sites.

Jarodd Abonné

Je n’ai jamais compris l’intérêt de charger ses librairies sur un site distant. En local c’est plus rapide, on peut aussi le mettre sur un CDN. Et s’il y a un problème, ça n’INpacte que notre site, pas des millions qui en dépendent.

bilbonsacquet Abonné

Jarodd a écrit :

Je n’ai jamais compris l’intérêt de charger ses librairies sur un site distant.

Les navigateurs limitent les connexions vers la même IP, d’où l’intérêt d’avoir des ressources ailleurs. jQuery héberge les scripts sur des CDN, c’est d’ailleurs ceux-ci qu’il faut pointer.

Mettre en place son propre CDN a un coup, en plus de devoir mettre à jour régulièrement les libs !

sebtx Abonné

hycday a écrit :

j’ose à peine imaginer ce qu’on peut faire avec une lib jQuery vérolée, dispo sur une infinité de sites….attaques par DDOS, vols de cookies, redirection de physhing etc à peu prêt tout ce qui se fait, concentré en un point. Rien que pour ca, je préfère avoir controle des fichiers et ne jamais faire appel à des library hebergées ailleurs.

Idem, chargé en statique par nginx tout comme les images, c’est plus sûr et on contrôle les mises à jour.

psn00ps Abonné

bilbonsacquet a écrit :

Les navigateurs limitent les connexions vers la même IP, d’où l’intérêt d’avoir des ressources ailleurs. jQuery héberge les scripts sur des CDN, c’est d’ailleurs ceux-ci qu’il faut pointer.

Mettre en place son propre CDN a un coup, en plus de devoir mettre à jour régulièrement les libs !

Ca va te coûter cher, je ne me jette pas à ton cou. " />

Homo_Informaticus

Toute facons faut etre sacrément allumé pour faire confiance a ces mecs et pointer les balises scripts vers leur serveurs. vaut mieux bien vérifier le code soit meme et héberger en local. Ne serait ce que sinon la NSA peut lire tous vos scripts PHP.

Jesuisserieux

Toujours la même manière à 2 balles de communiquer.
Déjà, ils communiquent car si c’est pas eux qui vous les faire, ce sont les hackers..car si le/les sites pouvaient garder cela pour eux ils le feraient.
Puis Phase 2: Promis on s’est fait Hacké mais vos données sont en sécurité…Mais bien sur…..et la marmotte " />

Adrian Shephard

Jarodd a écrit :

Je n’ai jamais compris l’intérêt de charger ses librairies sur un site distant. En local c’est plus rapide, on peut aussi le mettre sur un CDN. Et s’il y a un problème, ça n’INpacte que notre site, pas des millions qui en dépendent.

Du point de vue de tes utilisateurs, ton site n’est pas plus local que le site de hosting de Google par exemple, qui a des serveurs partout, et il est moins rapide.

Qu’en sais-tu ? " />

j-dub

Adrian Shephard a écrit :

Du point de vue de tes utilisateurs, ton site n’est pas plus local que le site de hosting de Google par exemple, qui a des serveurs partout, et il est moins rapide.

Y’a pas de point de vue de l’utilisateur là.
Quand la page appelle la librairie qui est en local relativement à elle même, ça va plus vite que de l’appeler d’un emplacement externe.

A moins ce soit stocké sur un disque antique " />

flagos_

Jarodd a écrit :

Je n’ai jamais compris l’intérêt de charger ses librairies sur un site distant. En local c’est plus rapide, on peut aussi le mettre sur un CDN. Et s’il y a un problème, ça n’INpacte que notre site, pas des millions qui en dépendent.

C’est au contraire plus rapide sur leur site. En général, les utilisateurs ont deja chargés les scripts (du moins pour les lpus connus) et du coup tu bénéficies du cache navigateur.

j-dub a écrit :

Y’a pas de point de vue de l’utilisateur là.
Quand la page appelle la librairie qui est en local relativement à elle même, ça va plus vite que de l’appeler d’un emplacement externe.

A moins ce soit stocké sur un disque antique " />

Si, on parle de javascript. C’est l’utilisateur qui la charge. A moins qu’on parle de javascript coté serveur mais il me semble que c’est encore anecdotique.

gvosnet a écrit :

Voilà par exemple une bonne raison de ne pas faire pointer ses sites directement vers les libs de jQuery mais plutôt enregistrer les versions et les héberger sur ses propres sites.

et donc de ne jamais bénéficier des mises a jour de sécurité lorsqu’un trou est découvert dans un script.

yotsumi

j-dub a écrit :

Quand la page appelle la librairie qui est en local relativement à elle même, ça va plus vite que de l’appeler d’un emplacement externe. 

Désolé mais tu te trompes :)
 
La librairie est chargée par ton navigateur, la requête partira de chez toi et ira jusqu’au serveur distant. Qu’elle soit chargée à côté de la page servie ou sur un autre serveur, le trajet sera toujours aussi long (rien n’est relatif dans ce contexte).
 
En fait si ça change un truc, le nombre de téléchargement parallèle sur un même domaine est limité par les navigateurs, c’est pour cela qu’on recommande de charger les assets depuis un CDN (qui soit dit en passant, sera généralement plus rapide que ton propre serveur, car déployé en plusieurs points géographiques et ultra optimisé niveau cache. Et avec un peu de chance, le script a déjà été mis en cache sur le navigateur du client s’il a déjà visité un site utilisant cette lib et ce CDN).

le-gros-bug

Homo_Informaticus a écrit :

Toute facons faut etre sacrément allumé pour faire confiance a ces mecs et pointer les balises scripts vers leur serveurs. vaut mieux bien vérifier le code soit meme et héberger en local. Ne serait ce que sinon la NSA peut lire tous vos scripts PHP.

Lire les scripts PHP avec du javascript vérolé par la NSA " />

le-gros-bug a écrit :

Lire les scripts PHP avec du javascript vérolé par la NSA " />

Meme qu’ils nettoient leurs trace avec AJAX !

flagos_ a écrit :

Si, on parle de javascript. C’est l’utilisateur qui la charge. A moins qu’on parle de javascript coté serveur mais il me semble que c’est encore anecdotique.

yotsumi a écrit :

Désolé mais tu te trompes :)
 
La librairie est chargée par ton navigateur, la requête partira de chez toi et ira jusqu’au serveur distant. Qu’elle soit chargée à côté de la page servie ou sur un autre serveur, le trajet sera toujours aussi long (rien n’est relatif dans ce contexte).
 
En fait si ça change un truc, le nombre de téléchargement parallèle sur un même domaine est limité par les navigateurs, c’est pour cela qu’on recommande de charger les assets depuis un CDN (qui soit dit en passant, sera généralement plus rapide que ton propre serveur, car déployé en plusieurs points géographiques et ultra optimisé niveau cache. Et avec un peu de chance, le script a déjà été mis en cache sur le navigateur du client s’il a déjà visité un site utilisant cette lib et ce CDN).

Anéfé j’avais oublié ce point de détail " />

" />

Aither99

Jarodd a écrit :

Je n’ai jamais compris l’intérêt de charger ses librairies sur un site distant. En local c’est plus rapide, on peut aussi le mettre sur un CDN. Et s’il y a un problème, ça n’INpacte que notre site, pas des millions qui en dépendent.

Les avantages sont multiples :

les requetes HTTP sont limité a 2 par noms de domaine.

tu économises en bandes passantes/ressources utilisé (argument valable seulement si tu as un très grand nombre d’utilisateurs).

si l’utilisateur n’a pas la ressources en local elle lui est servie par le serveur le plus proche.

ta lib est mise en cache par le navigateur(30j en général), et est mutualiser pour tout les utilisateurs du même CDN que toi, tu as donc de grande chance que l’utilisateur l’ai déjà dans sont cache.

(Avantage ou pas, chaqu’un perchera ça paroisse), en général tu n’appel pas la version mineur(tu appels 1.10 et non pas 1.10.0). tu profites donc des mises à jour de sécurité des qu’elles sont disponible

TheMyst Abonné

@ Aither99:
2 connexions HTTP par nom de domaine, des sources de ça ?

benjarobin Abonné

Mystou a écrit :

@ Aither99:
2 connexions HTTP par nom de domaine, des sources de ça ?

http://stackoverflow.com/a/14768266/808101
Donc c’était 2 à une époque, ce n’est plus le cas…

Khalev

flagos_ a écrit :

et donc de ne jamais bénéficier des mises a jour de sécurité lorsqu’un trou est découvert dans un script.

Avoir les bibliothèques en local ne t’empêche pas de faire les màj associées, comme tout ce que tu as en local…

RaYz

Homo_Informaticus a écrit :

Toute facons faut etre sacrément allumé pour faire confiance a ces mecs et pointer les balises scripts vers leur serveurs. vaut mieux bien vérifier le code soit meme et héberger en local. Ne serait ce que sinon la NSA peut lire tous vos scripts PHP.

On est vendredi mais quand même " />

flagos_ a écrit :

C’est au contraire plus rapide sur leur site. En général, les utilisateurs ont deja chargés les scripts (du moins pour les lpus connus) et du coup tu bénéficies du cache navigateur.

Comme avec un CDN.

Khalev a écrit :

Avoir les bibliothèques en local ne t’empêche pas de faire les màj associées, comme tout ce que tu as en local…

Sauf que c’est a toi de bouger ton boule alors que la dans l’autre cas, c’est fait automatiquement.

Surtout qu’aujourd’hui, il est pas rare que les failles et les scripts qui les exploitent soient publiées en meme temps. Ce qui fait que tu as interet a etre super réactif dès qu’un exploit est publié.

Et c’est typiquement ce qui emmerdant avec les failles comme celle de bash ou de heartbleed: il faut sauter sur son clavier pour fixer le truc des qu’on en entend parler.

Jarodd a écrit :

Comme avec un CDN.

Ben non. si c’est le CDN de ton hébergeur, c’est ta copie de fichier qui est stockée dessus, l’utilisateur devra la charger spécifiquement pour ton site.

Tandis que si tu appelles une lib jquery, ou même directement jquery lui même depuis le serveur central, ben la lib est deja en cache pour 90% des gens, car appelé depuis un autre site.

jpaul Abonné

flagos_ a écrit :

Sauf que c’est a toi de bouger ton boule alors que la dans l’autre cas, c’est fait automatiquement.

Surtout qu’aujourd’hui, il est pas rare que les failles et les scripts qui les exploitent soient publiées en meme temps. Ce qui fait que tu as interet a etre super réactif dès qu’un exploit est publié.

Et c’est typiquement ce qui emmerdant avec les failles comme celle de bash ou de heartbleed: il faut sauter sur son clavier pour fixer le truc des qu’on en entend parler.

$ bower update

Merci au revoir.

jpaul a écrit :

$ bower update

Merci au revoir.

Ouai donc c’est pas fait automatiquement. Ca reste a toi de le taper.

Ou alors tu le scriptes via cron, mais ca revient a la même chose que la premiere solution: tu deviens sensible si le serveur a été corrompu.

flagos_ a écrit :

Ben non. si c’est le CDN de ton hébergeur, c’est ta copie de fichier qui est stockée dessus, l’utilisateur devra la charger spécifiquement pour ton site.

Tandis que si tu appelles une lib jquery, ou même directement jquery lui même depuis le serveur central, ben la lib est deja en cache pour 90% des gens, car appelé depuis un autre site.

Bah il me semblait que le navigateur la mettait en cache. Là par exemple PCI utilise la version 1.9.1 de jQuery, sur ce fichier (comme d’autres) j’ai une réponse 304 Not modified, j’en déduisais que ces fichiers étaient lus depuis le cache, et non rechargés depuis le serveur.

Jarodd a écrit :

Bah il me semblait que le navigateur la mettait en cache. Là par exemple PCI utilise la version 1.9.1 de jQuery, sur ce fichier (comme d’autres) j’ai une réponse 304 Not modified, j’en déduisais que ces fichiers étaient lus depuis le cache, et non rechargés depuis le serveur.

Ah ben oui quand même. C’est juste que la première fois, tu as du la charger spécifiquement pour PCI.

Alors que si PCI tapait sur le serveur central, tu l’aurais deja eu en cache d’un autre site par ailleurs, et donc même pas besoin de la charger la premiere fois que tu arrives dessus.

Ca peut sembler etre de l’enculage de mouche, mais quand tu fais un site la première impression est très importante. Tout se joue sur les 5-10 premieres secondes et sur cette impression l’utilisateur va se faire un a priori negatif ou positif assez puissant.

Donc ouais, le temps de 1er chargement de la page compte énormément. Des petites économies comme ca sont plutot de bonnes pratique je dirais

Cat-le-Duck

Le plus drôle était le message affiché sur le site de jQuery.

Le pirate s’excusait du dérangement : il cherchait juste un boulot, il a indiqué la faille sur l’infra jQuery et à laissé une adresse pour être contacté.

Désolé j’ai pas pensé à prendre un screen sur le moment.

flagos_ a écrit :

Ouai donc c’est pas fait automatiquement. Ca reste a toi de le taper.

Ou alors tu le scriptes via cron, mais ca revient a la même chose que la premiere solution: tu deviens sensible si le serveur a été corrompu.

Non ça n’est pas fait automatiquement, mais il est de toutes façons de très mauvais goût de faire des mises à jour automatiques des dépendances sur la prod.

Globalement, le Javascript est exécuté dans un environnement extrêmement restreint qui limite grandement (mais pas totalement) toute tentative d’attaque à distance. Il n’y a aucun risque à laisser une librairie un peu ancienne, et comme dans tout projet de développement (ce n’est pas spécifique au dev web à ce que je sache), il est du devoir du développeur de surveiller que les dépendances ne sont pas obsolètes ou trouées, et ce n’est clairement pas un boulot qui peut être automatisé (ou alors tu fais confiance à tous les développeurs de toutes les librairies que tu utilises pour ne pas péter toutes leurs API… et ton projet)

Le site de jQuery compromis, mais les bibliothèques ne sont pas touchées

Sale temps pour les développeurs

Tiens, en parlant de ça :

ownCloud : faille béante dans les déploiements conteneurisés utilisant graphapi

Dangereuse, mais spécifique ?

Amazon re:invent : SoC Graviton4 (Arm), instance R8g et Trainium2 pour l’IA

Tout plus mieux qu'avant

Guéguerre des polices dans le cyber (OFAC et ComCyberMi)

CyberCom'

Sommaire de l'article

Introduction

ownCloud : faille béante dans les déploiements conteneurisés utilisant graphapi

Amazon re:invent : SoC Graviton4 (Arm), instance R8g et Trainium2 pour l’IA

Guéguerre des polices dans le cyber (OFAC et ComCyberMi)

#LeBrief : faille 0-day dans Chrome, smartphones à Hong Kong, 25 ans de la Dreamcast

OVHcloud Summit 2023 : SecNumCloud, IA et Local Zones

Transparence, discriminations : les questions soulevées par l’algorithme de la CAF

Plainte contre l’alternative paiement ou publicité comportementale de Meta

Économie de la donnée et services de cloud : l’Arcep renforce ses troupes

Plus de 60 % des demandes de suppression reçues par Google émanent de Russie

La Commission européenne et Google proposent deux bases de données de fact-checks

#LeBrief : des fichiers Google Drive disparaissent, FreeBSD 14, caméras camouflées, OnePlus 12

Le poing Dev – round 6

Produits dangereux sur le web : nouvelles obligations en vue pour les marketplaces

Usages et frugalité : quelle place pour les IA dans la société de demain ?

La NASA établit une liaison laser à 16 millions de km, les essais continuent

Semi-conducteurs : un important accord entre l’Europe et l’Inde

#LeBrief : PS5 Slim en France, Valeo porte plainte contre NVIDIA, pertes publicitaires X/Twitter

651e édition des LIDD : Liens Intelligents Du Dimanche

#Flock, le grand remplacement par les intelligences artificielles

Quoi de neuf à la rédac’ #9 : LeBrief 2.0, ligne édito, dossiers de fond

Encapsulation de clés et chiffrement d’enveloppes

Empreintes digitales : les capteurs Windows Hello loin d’être exemplaires

#LeBrief : succès du test d’Ariane 6, réparer plutôt que remplacer, Broadcom finalise le rachat de VMware

Hébergeurs, éditeurs, espaces de conversation ? La difficile régulation des réseaux sociaux

Silicium : un matériau indispensable et omniprésent, mais critique

Panneaux solaires en autoconsommation : on décortique le kit Play de Sunology

Un think tank propose d’autoriser les opérations de « hack back »

#LeBrief : Ariane 6 sur le banc de test, arrestation algorithmique, entraînement d’IA par des mineurs

Chrome : Google corrige plusieurs failles sévères, dont une déjà exploitée

Des cadres supérieurs invités à n’utiliser que des téléphones jetables à Hong Kong

La Dreamcast de Sega fête ses 25 ans

Démantèlement d’un groupe ukrainien de rançongiciels

Commentaires (33)