Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

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

Sale temps pour les développeurs

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

Le 26 septembre 2014 à 07h40

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)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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

votre avatar







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=" />


votre avatar







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.


votre avatar







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.


votre avatar







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.


votre avatar







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


votre avatar







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=" />


votre avatar







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 !


votre avatar







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=" />


votre avatar







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


votre avatar

@ Aither99:

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

votre avatar







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…


votre avatar







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…


votre avatar







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=" />


votre avatar







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.


votre avatar







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.


votre avatar

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

votre avatar

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.

votre avatar

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.

votre avatar

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.

votre avatar







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 !


votre avatar







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.


votre avatar







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=" />


votre avatar

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.

votre avatar

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=" />

votre avatar







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.


votre avatar







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.


votre avatar







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.


votre avatar







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.


votre avatar







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.


votre avatar







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


votre avatar

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.

votre avatar







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

Fermer