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

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

Sale temps pour les développeurs

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

26/09/2014 2 minutes
33

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.

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (33)


shadowfox
Le 26/09/2014 à 07h 44

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


hycday
Le 26/09/2014 à 07h 56

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
Le 26/09/2014 à 08h 02

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é
Le 26/09/2014 à 08h 07

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é
Le 26/09/2014 à 08h 17







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é
Le 26/09/2014 à 08h 24







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
Le 26/09/2014 à 08h 26







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. <img data-src=" />



Homo_Informaticus
Le 26/09/2014 à 08h 29

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
Le 26/09/2014 à 08h 30

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 <img data-src=" />


Adrian Shephard
Le 26/09/2014 à 08h 31







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.



Jarodd Abonné
Le 26/09/2014 à 08h 47

Qu’en sais-tu ? <img data-src=" />


j-dub
Le 26/09/2014 à 09h 16







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 <img data-src=" />



flagos_
Le 26/09/2014 à 09h 28







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.



flagos_
Le 26/09/2014 à 09h 29







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 <img data-src=" />







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.



flagos_
Le 26/09/2014 à 09h 30







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
Le 26/09/2014 à 09h 32







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.&nbsp;





Désolé mais tu te trompes :)

&nbsp;

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

&nbsp;

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
Le 26/09/2014 à 10h 12







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 <img data-src=" />



Homo_Informaticus
Le 26/09/2014 à 10h 17







le-gros-bug a écrit :



Lire les scripts PHP avec du javascript vérolé par la NSA <img data-src=" />





Meme qu’ils nettoient leurs trace avec AJAX !



j-dub
Le 26/09/2014 à 10h 29







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 :)

&nbsp;

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

&nbsp;

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 <img data-src=" />



<img data-src=" />



Aither99
Le 26/09/2014 à 10h 42







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é
Le 26/09/2014 à 11h 19

@ Aither99:

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


benjarobin Abonné
Le 26/09/2014 à 11h 29







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
Le 26/09/2014 à 11h 30







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
Le 26/09/2014 à 11h 36







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 <img data-src=" />



Jarodd Abonné
Le 26/09/2014 à 11h 48







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.



flagos_
Le 26/09/2014 à 11h 50







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.



flagos_
Le 26/09/2014 à 11h 52







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é
Le 26/09/2014 à 11h 53







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.



flagos_
Le 26/09/2014 à 11h 59







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.



Jarodd Abonné
Le 26/09/2014 à 12h 14







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.



flagos_
Le 26/09/2014 à 12h 22







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 26/09/2014 à 14h 00

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.


jpaul Abonné
Le 26/09/2014 à 15h 10







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)