bower est marqué en pré-requis dans ce journal c'est donc un nième outil à installer.
Comme il pourrait être en prérequis d’un projet en PHP. Encore une fois, rien à voir avec la plateforme.
mais va assurer sa propre mise à jour de manière autonome...
Pas nécessairement : seulement si les devs prennent la peine de fournir une version pré-empaquetée. Exactement comme en node donc...
Non, je ne vois toujours pas de rapport entre le nombre d'utilisateurs et les risques de sécurité
J’ai parlé de « millions d’utilisateur » pour une chose : indiquer que c’est quelque chose de testé, y compris en production et à large échelle.
Les récents événements ont montré que même les librairies les plus utilisées ne sont pas exemptes de bugs/failles depuis des années
Ça tombe bien, personne n’a prétendu ça.
Maintenant, faisons simple. Tu prends 200 développeurs de tous niveaux. Aux cent premiers, tu leur fait coder un CMS où ils doivent faire toutes leurs requêtes SQL à la main. Au cent autres, tu leur fait coder un CMS avec obligation d’utiliser un ORM. À ton avis, quel groupe aura statistiquement le plus d’injections SQL ? Petit indice : le groupe 2 en aura 0. Ça veut pas dire que ce sont des meilleurs codeurs, et qu’ils n’introduiront aucun bug ni aucune faille. Mais au moins il ne tomberont pas dans ce piège bien précis. Ajoute à cette image un système de template qui échappe les variables par défaut (en opposition à coder à coups de <?php echo $row["user_comment"] ?>), un système de routage qui évite les pièges genre <?php include $_GET['module']."/".$_GET['page']; ?>, et tu te trouveras certes avec 150.000 dépendances, mais un code vachement plus sûr (et non, je n’ai pas dit à 100% sûr).
Je te rejoins sur un truc : ce qui fait la sécurité, c’est la qualité du code. Et la qualité du code, elle passe par des bonnes pratiques, qui incluent :
Factorisation et réutilisation du code: utilisation de librairies externes éprouvées tant que possible.
Automatisation maximale (tests, génération de code, gestions des asset). Le « bower » dont tu te plains.
Alors oui, dans la qualité du code il n’y a pas que ça (loin de là), mais ce dont tu te plains (150.000 dépendances, outillage lourd) sont deux aspects très important de la qualité du code. D’où le fait que je réagisse assez violemment à ta remarque « ah, de mon temps, on avait pas à s’encombrer de tout ça, pas de dépendances, on faisait nos requêtes SQL avec amour » (oui, je caricature ;)). Ce bon vieux temps, c’est aussi un bon vieux temps où on voyait passer dans les CVE des dizaines de SQL injection par semaine sur une base de code totale (beaucoup !) moins large. Ce qui a endigué l’épidémie de SQL injection (et je suis optimiste. Disons, vaguement contenu, vu qu’il y a encore beaucoup de projets dans la nature en mode « YOLO les ORM c’est pour les noobs »), c’est pas un coup de baguette magique qui a rendu les devs plus intelligent, c’est l’exemple de Rails et les émules qu’il a fait dans le monde PHP.
rails : qui se vantait d'une protection native des sql injections et s'en est mangé une monstrueuse il y a 2 ans...
C’est un excellent exemple que tu nous sors là. Déjà, ce n’est pas une injection SQL à proprement parler (tu ne peux pas injecter de commande SQL arbitraire). Je te refais la faille en PHP :
$user=User::findOne($_SESSION["userid"]);foreach($_POST["user"]as$attr=>$val){$user->set($attr,$val);// ici $attr et $val sont correctement échappés : pas d’injection SQL}$user->validate();$user->save();
La faille ? Simple, l’utilisateur ayant le contrôle des entrées, il peut très bien envoyer en données POST user[is_admin] = 1.
Pourquoi c’est un exemple intéressant ? Parce qu’on a là des développeurs expérimentés, qui savent ce qu’est qu’une injection SQL, qui sont tombés le panneau. Je vais te faire une confession : j’ai un jour, comme beaucoup, succombé au syndrome NIH. J’ai fait un rails-like dans mon langage favori (Objective-C. On a tous nos perversions inavouables). Devine quoi ? Quand la faille pour rails a été révélée, j’étais bien évidemment tombé dans le même panneau. En quoi cette remarque est pertinente sur ce qui nous intéresse ? Après tout, tu vas me dire : le truc fait à la main a la faille, le framework connu a la faille, 1 partout balle au centre.
Sauf que cette histoire a deux ans. Presque tout le monde l’a oubliée. Contrairement aux SQL injections qui sont martelées à la tête de tous les développeurs (ce qui n’empêche pas certains de continuer à en introduire régulièrement, parce que les ORM c’est trop usine à gaz...), le détail de cette faille n’est connu presque de personne.
Un dev qui partira sur Rails ne sera pas affecté. L’erreur a été corrigée. Lesson learned, comme disent les anglais. Par contre, un wanabee « moi j’aime pas les dépendances, je vais tout refaire à la main », je te fiche mon billet qu’il a plus (bien plus !) d’une chance sur deux de retomber dans ce panneau.
Les devs de framework ne sont pas des dieux qui codent mieux que toi, mais ils ont généralement fait les erreurs que tu vas faire avant que tu ne les aies faites. Et les ont corrigées avant que tu les fasses. Et celles qu’ils n’ont pas encore faites mais qu’ils vont faire, ben tu vas les faire aussi. Profite de leur expérience.
[^] # Re: C'était mieux avant
Posté par Moonz . En réponse au journal Installer un serveur Firefox Accounts et Firefox Sync. Évalué à 5. Dernière modification le 24 février 2016 à 20:18.
Comme il pourrait être en prérequis d’un projet en PHP. Encore une fois, rien à voir avec la plateforme.
Pas nécessairement : seulement si les devs prennent la peine de fournir une version pré-empaquetée. Exactement comme en node donc...
J’ai parlé de « millions d’utilisateur » pour une chose : indiquer que c’est quelque chose de testé, y compris en production et à large échelle.
Ça tombe bien, personne n’a prétendu ça.
Maintenant, faisons simple. Tu prends 200 développeurs de tous niveaux. Aux cent premiers, tu leur fait coder un CMS où ils doivent faire toutes leurs requêtes SQL à la main. Au cent autres, tu leur fait coder un CMS avec obligation d’utiliser un ORM. À ton avis, quel groupe aura statistiquement le plus d’injections SQL ? Petit indice : le groupe 2 en aura 0. Ça veut pas dire que ce sont des meilleurs codeurs, et qu’ils n’introduiront aucun bug ni aucune faille. Mais au moins il ne tomberont pas dans ce piège bien précis. Ajoute à cette image un système de template qui échappe les variables par défaut (en opposition à coder à coups de
<?php echo $row["user_comment"] ?>), un système de routage qui évite les pièges genre<?php include $_GET['module']."/".$_GET['page']; ?>, et tu te trouveras certes avec 150.000 dépendances, mais un code vachement plus sûr (et non, je n’ai pas dit à 100% sûr).Je te rejoins sur un truc : ce qui fait la sécurité, c’est la qualité du code. Et la qualité du code, elle passe par des bonnes pratiques, qui incluent :
Alors oui, dans la qualité du code il n’y a pas que ça (loin de là), mais ce dont tu te plains (150.000 dépendances, outillage lourd) sont deux aspects très important de la qualité du code. D’où le fait que je réagisse assez violemment à ta remarque « ah, de mon temps, on avait pas à s’encombrer de tout ça, pas de dépendances, on faisait nos requêtes SQL avec amour » (oui, je caricature ;)). Ce bon vieux temps, c’est aussi un bon vieux temps où on voyait passer dans les CVE des dizaines de SQL injection par semaine sur une base de code totale (beaucoup !) moins large. Ce qui a endigué l’épidémie de SQL injection (et je suis optimiste. Disons, vaguement contenu, vu qu’il y a encore beaucoup de projets dans la nature en mode « YOLO les ORM c’est pour les noobs »), c’est pas un coup de baguette magique qui a rendu les devs plus intelligent, c’est l’exemple de Rails et les émules qu’il a fait dans le monde PHP.
C’est un excellent exemple que tu nous sors là. Déjà, ce n’est pas une injection SQL à proprement parler (tu ne peux pas injecter de commande SQL arbitraire). Je te refais la faille en PHP :
Le formulaire :
Gestion du formulaire :
La faille ? Simple, l’utilisateur ayant le contrôle des entrées, il peut très bien envoyer en données POST
user[is_admin] = 1.Pourquoi c’est un exemple intéressant ? Parce qu’on a là des développeurs expérimentés, qui savent ce qu’est qu’une injection SQL, qui sont tombés le panneau. Je vais te faire une confession : j’ai un jour, comme beaucoup, succombé au syndrome NIH. J’ai fait un rails-like dans mon langage favori (Objective-C. On a tous nos perversions inavouables). Devine quoi ? Quand la faille pour rails a été révélée, j’étais bien évidemment tombé dans le même panneau. En quoi cette remarque est pertinente sur ce qui nous intéresse ? Après tout, tu vas me dire : le truc fait à la main a la faille, le framework connu a la faille, 1 partout balle au centre.
Sauf que cette histoire a deux ans. Presque tout le monde l’a oubliée. Contrairement aux SQL injections qui sont martelées à la tête de tous les développeurs (ce qui n’empêche pas certains de continuer à en introduire régulièrement, parce que les ORM c’est trop usine à gaz...), le détail de cette faille n’est connu presque de personne.
Un dev qui partira sur Rails ne sera pas affecté. L’erreur a été corrigée. Lesson learned, comme disent les anglais. Par contre, un wanabee « moi j’aime pas les dépendances, je vais tout refaire à la main », je te fiche mon billet qu’il a plus (bien plus !) d’une chance sur deux de retomber dans ce panneau.
Les devs de framework ne sont pas des dieux qui codent mieux que toi, mais ils ont généralement fait les erreurs que tu vas faire avant que tu ne les aies faites. Et les ont corrigées avant que tu les fasses. Et celles qu’ils n’ont pas encore faites mais qu’ils vont faire, ben tu vas les faire aussi. Profite de leur expérience.