Discussion :

[Katleen Erna]

Des hackers exploitent les commentaires de YouTube par injection HTML, les failles XSS sont-elles trop sous-estimées par les webmasters ?

Des hackers ont trouvé plusieurs failles sur YouTube qu'ils se sont empressé d'exploiter ce week end. Les vulnérabilités touchent le système de commentaires du site de diffusion de vidéos.

Ils ont procédé via des injections HTML. En fait, en inscrivant un commentaire contenant du javascript après le tag <script>, il s'avère que YouTube supprimait le tag <script>, mais sans effacer les données qui le suivent. Au contraire, elles étaient mises en avant et affichées à l'écran. Grâce à cela, les hackers ont pu injecter du HTML directement dans la page visionnée, allant jusqu'à la modifier entièrement. Cette brèche ouvre la porte à de nombreuses attaques potentielles.

Dans le cas présent, c'est resté bon enfant : ouverture de pop ups, affichage de bannières et de messages ("Google can't code, YouTube hacked!"), écran noir.

Ces apparitions ont eu lieu ce dimanche 4 juillet entre 13h et 15h.

Pour l'anecdote, les pages les plus visées étaient celles consacrées au chanteur pour adolescents Justin Bieber. Les internautes voulant regarder ses vidéos étaient par exemple redirigés vers de faux sites annonçant sa mort.

Cet acharnement était originaire du forum 4chan qui s'est lancé dans une véritable croisade contre le jeune homme (qu'ils essaient d'envoyer faire un concert en Corée du Nord en truquant un vote).

S'étant arrêté au mauvais goût, les conséquences de cette vulnérabilité auraient pourtant pu être des attaques plus sérieuses touchant des millions d'ordinateurs.

Les webmasters ont parfois tendance à sous-estimer la faille XSS, qui présente pourtant de dangereux risques. En redirigeant un utilisateur sur une page extérieure au site, on pourrait tout aussi bien lui faire télécharger des malwares et autres logiciels malveillants. Les pirates auraient aussi pu rediriger les internautes vers de fausses pages YouTube pour une large campagne de phishing.

Le problème est en tous les cas réglé. YouTube a réagit au quart de tour et en seulement quelques heures, l'HTML a été géré correctement dans les commentaires.

Source : Un résumé de l'attaque fait par un "pirate" ; des explications du support de Google

Les Web Application Filters n'ont pas su détecter cet incident. Comment s'en protéger efficacement ?

Les webmasters sous-estiment-ils trop les failles de type XSS ? Sont-elles vraiment inoffensives ?

[Invité]

Cet acharnement était originaire du forum 4chan qui s'est lancé dans une véritable croisade contre le jeune homme (qu'ils essaient d'envoyer faire un concert en Corée du Nord en truquant un vote).

Les webmasters ont parfois tendance à sous-estimer la faille XSS

La sécurité est l'affaire de tous (tout le monde doit se sentir concerné) mais doit être laissé aux développeurs chevronnés et non au Webmasters

[FERDIKAM]

La sécurité est l'affaire de tous (tout le monde doit se sentir concerné) mais doit être laissé aux développeurs chevronnés et non au Webmasters

vous avez raison d'une part, mais le webmaster doit avoir un minimum de connaissances en développement pour être capable de résoudre aussi des problèmes de sécurités

[tsunamichups]

Une formation supplémentaire sur les sécurités ne ferait de mal à personne,
il est regrettable que dans les écoles, il n'y ait même pas une sensibilisation à cela ...

[Caly4D]

le club des 15-18 de jv.com ..... toute une histoire

[Invité]

La sécurité est l'affaire de tous (tout le monde doit se sentir concerné) mais doit être laissé aux développeurs chevronnés et non au Webmasters

Drôle de préambule, hiérarchie quand tu nous tient !
Dire un truc et son contraire dans la phrase qui suit a sans doute des vertus politiques mais en matière de sécurité, j'appellerai ça une faille ou même un fjörd.

Le webmaster est un développeur php, javascript ou html ?

Je retiens que c'est l'affaire de tous donc des webmasters en première ligne! Les attaques par injection sont relativement faciles à sécuriser par l'intermédiaire d'une petite routine de gestion de quotes qui doit être utilisée systématiquement , l'usage des quotes en dur doit être proscrit. L'ideal est de forcer l'utilisation de requètes paramétrées, je reconnais que c'est parfois très lourd. On peut cependant rendre obligatoire l'usage du '?' dans les insert et update issus de forms éditables par l'utilisateur.

Las ! Le (très) vieux LAMP ignore tout du SQL paramétré, on dit que Postgre l'autorise. Bonne raison pour se débarrasser de MySql , cependant pour ceux qui resteront avec ce jouet toute leur vie , ils doivent savoir que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$query="SELECT * FROM table where title='$name'";

est un aspirateur à hacker, c'est un peu comme publier le mot de passe ftp sur facebook en demandant de ne pas le répéter...
Cette syntaxe est alors nécessaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$query="SELECT * FROM table where title="+sqlQuote($name);

N'hésitez pas à ajouter autant de concaténations que nécessaire. Seul un bout de code executé peut régler sérieusement ce problème. La petite facilité qu'offre PHP de déployer les strings en mettant leur nom dans une autre est à proscrire définitivement , plus jamais ....


La sécurité bouleverse votre sainte hiérarchie et la divise en deux parties : ceux dont le job est d'être le plus paranoïaque possible, et ceux qui appliquent les règles de sécurité. Les deux parties d'un cerveau sont équipées de nerfs qui transmettent l'info : il en va de même pour l'équipe web qui doit savoir parler sans s'exclure . D'où la perversion de votre commentaire.

[JackDaniels93]

Les attaques par injection sont relativement faciles à sécuriser par l'intermédiaire d'une petite routine de gestion de quotes qui doit être utilisée systématiquement.

Cette syntaxe est alors nécessaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$query="SELECT * FROM table where title="+sqlQuote($name);

N'hésitez pas à ajouter autant de concaténations que nécessaire.

Ou on peut utiliser un bon framework comme Symfony qui sécurise déjà pas mal le bouzin !

[Invité]

Ou on peut utiliser un bon framework comme Symfony qui sécurise déjà pas mal le bouzin !

C'est vrai, mais comme souvent en programmation, dès qu'on sort des fonctions proposées par le framework ont doit tout décomposer et recommencer "comme en 40" !!

C'est là que le développeur très sécurisé par les couches de service, montre ses limites.
Comme le sujet du topic concerne YouTube, qui n'utilise manifestement pas de gestionnaire de contenu... C'est le cas aussi pour les petites interfaces d'administration généralement offertes aux users enregistrés ou encore dans la page "Contact" ou dieu sait quel form intéractif un peu ennuyeux à développer et qu'on s'empresse d'oublier.

La sécurité est une façon de penser différente du fonctionnel, si on est trop cool, on se remet à penser spec et on laisse trainer la faille qui vous clouera au sol des années plus tard.

C'est difficile de savoir quelle discipline appliquer. En tous cas on a impérativement besoin de tous les yeux disponibles et même plus : recourir aux services d'un cab d'audit ne me semble pas stupide. L'inatention vient de l'habitude , et seul un oeil neuf est vraiment efficace. On peut aussi avoir une approche "check list" , moins couteuse mais qui demande beaucoup de minutie

L'auteur de 20 000 lignes de code aura-t-il la perspicacité de retourner dans ses vieux forms pour y vérifier chaque ligne ? Selon moi , une autre personne devrait le faire.

[Fenn_]

Depuis PHP5 (plus vraiment récent maintenant...) on peut aussi utiliser l'objet PDO avec le driver nécessaire pour supporter les requêtes paramétrées...

[bugsan]

En l'occurrence il s'agit de faille XSS et non pas de SQL injection.

Ils n'ont même pas pris la peine d'échapper les '<' et '>' des commentaires. On se croirait revenu en l'an 2000 ...

[dissert]

La sécurité est l'affaire de tous (tout le monde doit se sentir concerné) mais doit être laissé aux développeurs chevronnés et non au Webmasters

La sécurité ne peut et ne doit être laissée aux développeurs chevronnés : ce n'est pas un aspect .

Tous les développeurs doivent la prendre en compte (et pas que les chevronnés), ainsi que tous les administrateurs (et en particulier les webmasters) et tous les utilisateurs.

Le développeur ne peut configurer un firewall, il ne peut pas non plus empêcher l'utilisateur de laisser trainer son mot de passe, par contre, il devra prendre en compte les bonnes pratiques de sécurité au niveau de son développement.

Chaque catégorie d'intervenant doit respecter les bonnes pratiques qui le concerne (en l'occurrence, en matière de sécurité).

[Invité]

Drôle de préambule, hiérarchie quand tu nous tiens !
Dire un truc et son contraire dans la phrase qui suit a sans doute des vertus politiques mais en matière de sécurité, j'appellerai ça une faille ou même un fjörd.

Le webmaster est un développeur php, javascript ou html ?

D'où la perversion de votre commentaire.

Ma phrase est en bon français et n'est ni idiote (hiérarchie ???quel rapport?) ni pervertie.

Comme le sujet du topic concerne YouTube, qui n'utilise manifestement pas de gestionnaire de contenu... C'est le cas aussi pour les petites interfaces d'administration généralement offertes aux users enregistrés ou encore dans la page "Contact" ou dieu sait quel form intéractif un peu ennuyeux à développer et qu'on s'empresse d'oublier.

La sécurité est une façon de penser différente du fonctionnel, si on est trop cool, on se remet à penser spec et on laisse trainer la faille qui vous clouera au sol des années plus tard.

C'est difficile de savoir quelle discipline appliquer. En tous cas on a impérativement besoin de tous les yeux disponibles et même plus : recourir aux services d'un cab d'audit ne me semble pas stupide. L'inatention vient de l'habitude , et seul un oeil neuf est vraiment efficace. On peut aussi avoir une approche "check list" , moins couteuse mais qui demande beaucoup de minutie

L'auteur de 20 000 lignes de code aura-t-il la perspicacité de retourner dans ses vieux forms pour y vérifier chaque ligne ? Selon moi , une autre personne devrait le faire.

La même direction que ma phrase en beaucoup plus développé.

La sécurité ne peut et ne doit être laissée aux développeurs chevronnés : ce n'est pas un aspect .

Tous les développeurs doivent la prendre en compte (et pas que les chevronnés), ainsi que tous les administrateurs (et en particulier les webmasters) et tous les utilisateurs.

Le développeur ne peut configurer un firewall, il ne peut pas non plus empêcher l'utilisateur de laisser trainer son mot de passe, par contre, il devra prendre en compte les bonnes pratiques de sécurité au niveau de son développement.

Chaque catégorie d'intervenant doit respecter les bonnes pratiques qui le concerne (en l'occurrence, en matière de sécurité).

Dans le cas présent c'est un problème de javascript donc de développement pas de firewall...
Oui tout le monde doit prendre en compte la sécurité en premier le webmaster mais comme celui-ci a beaucoup de choses à faire ( rajoute une fonctionnalité par-ci, une par-là... je caricature je sais) il est anormal de le rendre responsable d'un travail au dessus de ses compétences.
Il devrait être obligatoire que l'on fasse un audit externe ou une vérification par un développeur chevronné...

[dissert]

Oui tout le monde doit prendre en compte la sécurité en premier le webmaster mais comme celui-ci a beaucoup de choses à faire ( rajoute une fonctionnalité par-ci, une par-là... je caricature je sais) il est anormal de le rendre responsable d'un travail au dessus de ses compétences.

Il devrait être obligatoire que l'on fasse un audit externe ou une vérification par un développeur chevronné...

En fait, ce que je voulais dire, c'est que le webmaster et le développeur (je suis développeur) sont dans le même bateau. La sécurité est un point à prendre en charge parmi les 100.000 à prendre en charge.

En ce qui concerne le XSS, et le problème de Youtube, je suis à 100% d'accord : c'est la faute du développeur (ou, plus certainement, celle de ses profs qui ne lui ont pas appris ce qu'était un XSS et pas dit que c'était à lui de s'en occupper).

Si audit il y a à faire, c'est plus par un expert en sécurité, qui va regarder s'il y a un oubli à un certain niveau (ergonomique, de configuration ou mise à jours des softs, comme de respect des bonnes pratiques de dév), voire effectuer des pentests.

[icl1c]

Les webmasters sous-estiment-ils trop les failles de type XSS ? Sont-elles vraiment inoffensives ?

Oui, les webmasters sous-estiment ce type de faille.. Après tout, ils pensent que c'est que du js et que ça sera inoffensif pour leur site.. Avec les failles XSS, on peut faire du vol de cookies, vol de session, phishing, modification de la page, blocage du site, redirection vers du porn ..

Et pour revenir à la sécurité, le problème pour moi c'est que l'aspect sécurité est un point abordé à la fin de la formation et non tout au long.

De toute façon, on apprend la sécurité sur le tas en subissant les attaques..

[pi-2r]

ah les noellistes, une bande de kikoo-lol qui veulent dominer le monde grand coup de XSS et de piratage de blog

@ icl1c: +1

[Florimond]

< Source : Un résumé de l'attaque fait par un "pirate" >

...a, semble-t-il, été effacé. Quelqu'un l'aurait-il en cache?

[Invité]

Le fait est que la majorité des intervenants ont des connaissances voisines et peuvent prendre en charge les tâches qui incombent à leurs collègues. C'est normal de se spécialiser mais dans le cas du réseau il est un peu facile de se retrouver coincé par les droits et donc dans les petits arrangements des tenants du réseau.
Pour ce qui concerne la sécurité uniquement, la spécialité n'existe pas vraiment, on est tous du même coté de la sécurité pour des raisons business ou légales, voire philosophiques . Les règles concernent donc tout le monde. ceux qui ne comprennent pas se feront expliquer, ceux qui ne veulent pas se feront mettre à jour.

Dans le cas présent c'est un problème de javascript donc de développement pas de firewall...
Oui tout le monde doit prendre en compte la sécurité en premier le webmaster mais comme celui-ci a beaucoup de choses à faire ( rajoute une fonctionnalité par-ci, une par-là... je caricature je sais) il est anormal de le rendre responsable d'un travail au dessus de ses compétences.
Il devrait être obligatoire que l'on fasse un audit externe ou une vérification par un développeur chevronné...

Oui c'est du javascript donc.
La question est , que faire si on n'a pas d'auditeur neuf sous la main ? C'est un peu comme le ménage, si une fée du logis le fait, on peut en prendre l'habitude. On reconnait bien celui qui a un peu trop pris l'habitude de laisser ce genre de tache à un tiers.. Le but étant de ne pas se laisser déborder, si on peut le faire faire , c'est génial, sinon il faut retrousser les manches.

[benzoben]

[B][SIZE="3"]
Les webmasters ont parfois tendance à sous-estimer la faille XSS

Je ne suis pas sur qu'on puisse parler de "webmaster" pour un site comme Youtube!

[MysteryGummy]

Cet acharnement était originaire du forum 4chan qui s'est lancé dans une véritable croisade contre le jeune homme (qu'ils essaient d'envoyer faire un concert en Corée du Nord en truquant un vote).

En truquant les votes ? Je n'ai pas eu vent de ça... Ils centralisent leurs votes pour la Corée du nord et l'Israël c'est tout...

[xamtheone]

En l'occurrence il s'agit de faille XSS et non pas de SQL injection.

Ils n'ont même pas pris la peine d'échapper les '<' et '>' des commentaires. On se croirait revenu en l'an 2000 ...

En l'occurrence c'est plus vicieux. En temps normal les < et > sont échappés des commentaires youtube. L'attaque a juste exploité un bug: mettre 2 balises script faisait sauter l'échappement de la deuxième. La première était bien échappé en &lt;script&gt; mais la deuxième restait <script>.

Curieux, non?