Note du modérateur : Splitté de la discussion CMS, web-agency : complémentaire ?, car là on rentre dans un débat à part entière...

Je suis tombé par hasard sur ceci :
http://www.zdnet.fr/actualites/informatiqu...9,00.htm?xtor=1

Je crois qu'il a raison et ça corrobroe avec ce que je disais plus haut sur la sécurité des logiciels Open Source.

Hmm à mon avis, c'est plus subtile que tes propos (si je m'en remémore bien) et plus subtile que "un logiciel libre est totalement sur".

Ce qui compte surtout c'est qu'un soft (OSS ou proprio) soit patché rapidement, plus que son nombre de failles.

La licence ne fait pas la sécurité, même si je pense que en ayant un code libre, on est certes plus sensibles aux failles mais aussi on peut les corriger plus rapidement qu'un soft proprio (vu que les failles ne sont pas repérées sauf lors de la réalisation d'un audit ou si l'équipe a les compétences pour les trouver).

Sur le long terme, un soft OSS est à mon avis de meilleure qualité qu'un soft proprio sous réserve d'avoir les équipes adéquates. Un soft OSS peut en outre permettre de récolter l'avis de développeur n'ayant pas les mêmes connaissances ou pratiques de dev. Du coup, chaque développeur peut éclairer de son avis les éventuelles faiblesses / risques du soft OSS. Dans un soft proprio, si c'est toujours la même équipe qui bosse dessus, il se peut qu'ils ne voyent jamais la/les failles qu'ils ont créés/laissés.

Voir à ce sujet :
- http://blogs.zdnet.com/Ou/?p=352
- http://www.washingtonpost.com/wp-dyn/conte...6021100217.html

Alan Cox dit bien de faire attention au cliché du "si c'est libre, alors c'est forcément sur" et rien de plus...

Note : Quelques redondances avec NiCoS, j'ai mis un peu plus de temps à poster Excellents points, d'ailleurs

Les propos d'Alan Cox ne sont pas nouveaux. Dire que parmi le foisonnement des projets open source, une proportion significative est moins sûre que le noyau Linux (c'est la comparaison qu'il fait, sachant que le noyau linux est une des applications les mieux sécurisée de la planète...), c'est une évidence (il y a 133 000 projets open source sur sourceforge !). Bien sûr, comme il le souligne justement tout dépend de l'expérience et des compétences des développeurs.

La sécurité d'une application commence par le respect de bonnes pratiques : des choses aussi basiques que configurer PHP avec register_globals Off (en)) jusqu'au respect des règles du secure coding (en) rédigé par Open Web Application Security Project (OWASP).

Il va de soi que toutes les applications ne sont pas égales en la matière. Dan pourra témoigner quels sont les "mauvais de la classe" au vu des dizaines de dédiés qu'il administre... PHP Nuke est un bon exemple (d'après Secunia -> voir ici, 31 failles de sécurité, dont 16% seulement ont été patchées). phpBB en est un autre... Un petit tour sur Secunia, un site web dédié au rapport de vulnérabilité d'applications, propriétaire ou libres est donc assez intéressant. Cela démontre si besoin était que la sécurité n'est pas forcémment meilleure côté commercial/propriétaire que côté open source. Il y a de bons développeurs d'un côté comme de l'autre.

Chacun sait qu'aucune application n'est inviolable, et la question est plus de savoir :

1. Combien de failles sont découvertes / exploitées
2. Quelle est la criticité des failles découvertes
3. Parmi les failles trouvées, combien sont résolues
4. Parmi celles résolues, à quelle vitesse le patch est publié (surtout pour les failles critiques).
   
   Bien entendu, plus un système est répandu, plus le risque de rapport d'une faille est important (et aussi, plus l'intérêt de hacker le système est tentant pour le hacker...).

Si je prend l'exemple de MODx, nous avons un développeur spécialiste de la sécurité, Timon Reinhard (aka NetNoise), et jusque là nous avons eu une brèche sur la 0.9.1 de moyenne importance résolue très rapidement. Mais on peut dire que des projets comme Drupal, Joomla ou Typo3 sont globalement tout aussi sûrs et/ou dispose d'un support correct.

C'est là que le prestataire joue aussi un rôle important. Rôle de conseil dans le choix de la solution (et là, pour choisir en connaissance de cause il vaut mieux qu'il ai accès au code de l'application ou à défaut aux alertes de sécurité), mais aussi rôle de maîtrise de l'environnement applicatif.

Le prestataire maîtrise t-il la configuration de son serveur (s'il est sur un mutualisé, difficile à garantir. S'il est sur un dédié, qui administre son serveur) ? A t-il accès aux remontées de failles (par exemple, l'équipe de MODx a décidé de ne pas rendre public les remontées de faille dans le bugtracker -> afin d'éviter de donner la recette aux petits rigolos qui pourrait profiter de l'intervalle avant publication du patch) ?

Merci, je peux te retourner le compliment

Hum, le soucis des solutions Opensources, c'est qu'il leur manque un patcheur automatique : dès qu'un patch de sécurité sort, et bien qu'il soit appliqué, parce qu'au bout d'un moment, on se retrouve avec une pelleté de site clients à mettre à jour.

L'application que j'utilise, n'est pas opensources (du moins je ne veux pas qu'elle le soit encore) mais à l'avantage d'être multisites et donc une mise à jour est valable pour tous mes clients. Il y a malheureusement pas suffisamment d'applications multisites (je sais qu'il y a Dotclear, mais c'est pas des blogs que je faits à mes clients), ou alors l'accent n'est pas assez mis sur le fait qu'elles sont multisites.

Hmmmm, je ne sais plus la/lesquelles mais il me semble bien que ça existe pourtant (Drupal ?)... au moins pour la mise à jour du système (par exemple Textpattern). Mais c'est vrai qu'un système de patch auto, c'est intéressant !

Tellement que je vais voir avec l'équipe de dév si on ne peut pas mettre ça au programme de la prochaine version de MODx

Arf, j'ai donnée une idée de fonctionnalité, et c'est tant mieux

Pour ma part, les raisons principales de ne pas avoir choisi une solution open-sources ne sont pas spécialement lié à la sécurité (a part ce que j'ai dit sur les mises à jour).

De plus, depuis, j'ai reçu un message sur la ML PHP d'OVH concernant un site Joomla piraté :


Concrètement, je dirai que le logiciel libre n'est pas plus sûr que le logiciel propriétaire. Je pense simplement qu'il est plus facile de trouver une faille dans un logiciel libre que dans un logiciel propriétaire.

Maintenant, ce n'est pas un problème si on fait des mises à jours fréquentes, mais cela nécessite des connaissances... Et donc, une maintenance régulière... et donc, un dépendance.

En fait, ca peut être un problème si le projet est abandonné ou rencontre une évolution qui fait qu'une mise à niveau s'impose (dans ce car, les anciennes versions ne sont plus mises à jour malgré la découverte de failles).

Il y a aussi la tendance fashion victim des acteurs du libre qui passent de projets en projets et qui abandonnent les anciens projets pour en faire des nouveaux. Cet effet turn-over me laisse perplexe sur la perrennité d'un CMS open-source.


Je suis de l'avis de Dadou, et pourtant, cela serait si simple, un système à la update.rdf de Firefox... et une tâche cron quotidienne, par exemple...

Et apparemment dans l'intervalle il avait atteri dans le mauvais sujet (celui sur CMS et web agency)



Concernant cet article (un peu court au niveau de la démonstration, soit dit en passant) son point de vue c'est que "Dans un environnement pur et parfait, le logiciel libre ne serait pas plus sûr que les logiciels dont le code source est tenu secret." Il s'agit donc d'un raisonnement abstrait, dans l'absolu. "Ross Anderson montre en effet qu'un code source rendu public est aussi vulnérable qu'un code source privé."

A mon avis, je dirai que tout dépend de la situation : il s'agit d'un arbitrage entre l'avantage de fermer le code au public afin de rendre plus difficile (mais possible, mainte fois démontré par la réalité) à pirater et l'avantage de soumettre le code aux yeux du plus grand nombre pour qu'il soit amélioré et rendu plus sûr. La phrase "les responsables de Microsoft soutiennent depuis bien longtemps que Windows est plus sûr avec un code privé qu'il ne le serait si son codé était public." est une illustration parfaite de mon propos ! Ca veut dire : si je suis mauvais, mieux vaut ne pas faire de pub du code (ça tombe sous le sens)...

Bien sûr, mieux vaut laisser le code de Windows fermé parceque sinon ce serait un désastre complet vu la qualité de celui-ci... pardonnez moi de revenir à Windows, mais la suite du texte de l'article me ramène sur les OS puisque la méthodologie de test MTBF est calibré pour les systèmes d'exploitations (OS).

"Mais comment Ross Anderson a-t-il procédé pour parvenir à de telles conclusions ? Il a utilisé une application couramment employée par l'industrie informatique qui permet de tester le temps que met un système avant d'être affecté par une panne. Un standard qui porte le nom de MTBF et qui a déjà fait ses preuves dans les services de contrôle qualité de nombre de fabricants. Inutile de préciser que le protocole de test a été calibré pour ne repérer que les bugs qui mettent en danger la sécurité d'un OS."

Donc en matière d'OS je dirai quelque soit les conclusion de Ross Andersion d'un point de vue théorique que la réalité est là : Windows est un gruyère par rapport à Linux ou OS X (et de TRES loin, demandez à la NSA et au FBI pourquoi ils sont tous passé sous Mac OS X et Linux...).




Encore une fois, je vais être en désaccord avec toi.

Non pas sur le fait que la licence / le mode de développement n'est pas le critère discriminant concernant la sécurité d'une application (dans un sens, ou dans l'autre) mais c'est bien la qualité du code produit et le respect de certaines bonnes pratiques qui est le facteur n°1. Qu'il soit plus facile de trouver une faille dans un logiciel open source que dans un logiciel propriétaire, évidemment puisque le code est ouvert. Mais la médaille a son revers : le fait que le code soit fermé de permet pas de juger de la qualité de l'application sur l'aspect essentiel des techniques de conception et du respect de bonne pratiques... La confiance dans la sécurité d'un logiciel propriétaire est donc intrinsèquement fondée sur la réputation du (des) développeur(s) et/où de l'éditeur... On en arrive au sujet de la dépendance...

Concernant la dépendance maintenant, là je pense que la dépendance est du côté de l'application propriétaire. C'est naturel, puisque le modèle économique du développement d'applications propriétaire est par définition basé dessus ! Combien de développeurs maîtrisent l'application ? Un nombre restreint puisqu'on a pas accès au code... la boîte fait faillite ? Je suis potentiellement coincé avec une application propriétaire que je ne maîtrise plus... pire encore, si le format des données est lui aussi propriétaire et que je ne peux pas l'exporter et le transférer à un autre outil....

En revanche, si un projet open source s'arrête, je dispose du code et à supposer qu'une autre communauté ne reprenne pas le code, je demande à n'importe quel développeur compétent en php/mysql ou java, ou Ruby... etc qui peut reprendre la maintenance, le développement...etc. Je peux aussi exporter les données et les utiliser dans un autre système...

Je suis donc libre et totalement indépendant, au contraire...

Cf ce que j'ai dit ci-dessus sur la pérennité et la dépendance de l'open source vs propriétaire.
A mon avis une application propriétaire abandonnée est bien plus problématique...

Et au passage, qui peut garantir qu'une boîte sera encore là dans 5 ans ? La pérennité n'est pas plus du côté d'un éditeur que d'une communauté open source (en tout cas, pour celles qui réunissent des centaines voire milliers de designer/utilisateurs/développeurs depuis plusieurs années).



Une tendance "fashion victim" des acteurs du libre ? je ne vois pas grand chose bouger de ce côté là au contraire la plupart des prestataires ont suivi les acteurs principaux comme L*nagora ou S*ile : Typo3, SPIP, Joomla/Mambo c'est 90% du marché des CMS libre en PHP/MySQL et ça ne bouge pas vraiment (pour rester tendre ).

Après du as des indépendants comme Loupilo qui bosse avec SPIP et Textpattern, Vincent ou Claire qui travaille sur Drupal (le challenger n°1) ou sur d'autres systèmes "challengers", et enfin tu as des gens comme moi qui sont des passionnés qui suivent ce qui se fait outre-atlantique et qui traduisent+importent des systèmes "innovants" (enfin je pense, comme je l'ai fait pour Textpattern ou MODx).

Je ne suis pas sûr qu'il y ai plus d'effet turn-over dans une communauté open source que dans une entreprise...

C'est vrai qu'il n'est pas impossible de pirater une application ayant un code fermé, mais la tache est quand même plus ardue.

Quand bien même, il y a du pour et du contre dans les deux :

C'est vrai que les failles sont souvent plus vite trouvées et corrigées dans une solution opensources, mais elles sont souvent plus difficilement décelable dans une solution propriétaire. L'exemple de Windows n'est pas à mon sens un bon exemple, car la popularité de cet OS joue contre lui, en effet, plus une application est utilisée (que ce soit opensources ou propriétaire) plus elle est sujette aux tentatives d'intrusions.

Si je prend comme exemple ma petite application : Elle est propriétaire, elle contient probablement des failles de sécurité (que je corrige au fur et à mesure que je les trouves), mais comme elle est utilisée que par mes clients sur mes serveurs (je ne la diffuse pas non plus), elle devient tout de même beaucoup plus difficile à casser.

Dans les deux cas, l'application peut être codé avec ses pieds ou avec intelligence. Il est qu'au court de ma carrière professionnelle, j'ai souvent allumé des prestataires d'applications dites "progicielle" qui sont en règles générales truffés de bugs (la dernière en date, un CMS développé en Java, dont la consommation en mémoire réussissait seule à mettre à genoux ma machine perso, alors qu'elle était capable de faire fonctionner plusieurs grosse applis en même temps sans broncher (du style 3D studio max et photoshop en même temps).

Entièrement de l'avis de Dadou.



Bien au contraire ! Une application open-source abandonnée combine les inconvénients ! D'une part, son code est ouvert donc les failles sont plus faciles à trouver, et d'autre part, le développement étant arrêté, il n'y a pas de correctif à mettre en place.

Alors que dans le cas d'une application propriétaire, certes, il n'y a pas de suivi de l'application, mais au moins, ses failles ne sont pas publiques. Et dans l'hypothèse où la boîte se casse la gueule, alors c'est que l'application est pas très utilisée et donc, par extension, qu'elle ne fait pas l'objet de convoitises de la part des acteurs du hacking.

Quand à l'effet de mode, il est bien présent. Avant, tout le monde ne jurait que par PHPNuke... Aujourd'hui, qui encore l'utilise ? Et demain ? Les CMS, même les propriétaires, sont voués à être abandonnés car il y aura toujours mieux. C'est dans quelques années que les gens subiront le choix du libre aujourd'hui.

Pour la migration d'un logiciel vers un autre "plus à la mode" ou plus adapté, cela coutera moins cher au client si le 1er soft est libre que s'il est proprio (sous réserve que la boite retenue connaisse le premier outil). Sinon va falloir ajouter une partie de reverse engineering dont le client aurait pu se passer...

Pour le coté évolution qui casse la compatibilité avec la version précédente, en général un script de maj est fournie... charge au client et/ou au prestataire (qui peut ne pas être le prestataire initial) de faire la mise à jour...

D'accord, mais quel rapport avec le sujet initial?

Personnellement, si j'utilise une solution propriétaire plutôt que open-sources ce n'est pas pour une question de coûts, mais pour diverses raisons qui ont fait que les produits disponible en open-sources ne me convenaient pas.

Je ne suis pas contre l'open-sources, bien au contraire, je l'utilise au quotidien pour mes besoins personnels.

Il est vrai que je laisse moins de choix à mes clients : mon serveur, mon application, mais une application en permanence remise à jour sans qu'ils aient la moindre manipulation à faire. Dans le cas d'une solution open-sources, ils peuvent plus facilement me demander de faire leur site internet chez l'hébergeur de leur choix, ensuite pour faire des économie, ils ne prennent pas de contrat de maintenant, et en gros 6 mois après, vu qu'ils n'auront pas fait de mise à jour (je les connais, déjà qu'ils ont du mal à trouver du temps pour mettre à jour le contenu rédactionnel, alors les mises à jours...) ils auront une application open-sources mais qui sera loin d'être sécurisé. Et si ils se font "pirater", vers qui ils vont se tourner : moi.

Un aspect que je n'avais pas envisagé, mais qui risque effectivement d'être problèmatique... Sérieusement, se mettre à l'Open Source, c'est une bonne solution marketting, ça fait "vendeur", mais une mauvaise solution de fidélisation client.

Là, c'est un autre débat - tous les projets de la boite où je travaille ne sont pas OSS, on cherche à prendre le meilleur outil en fonction des besoins du client...



Ce n'est pas à toi de supporter leur choix. S'ils ne prennent pas de contrat de maintenance, ben tant pis pour eux...



J'ai personnellement des clients avec des solutions OSS que je suis (et qui me sont donc fidèles) depuis plus de 3 ans et sans aucun soucis (on les conseille, on fait des évolutions, on fait des mises à jour si nécessaires) et sans contrat de maintenance particulier d'ailleurs. Ils nous font des demandes ponctuellement qu'on assure. Cet argument n'est pas recevable...

Ben, oui et non. Même quand il n'y a pas de contrat de maintenance, dès qu'il y a un problème, c'est vers le prestataire qui à réalisé le site qu'ils se tournent. En gros si le site se fait "pirater", ils vont m'accuser de ne pas leur avoir fournis une solution assez fiable.

Le type de client que je côtoie n'est pas vraiment à l'aise avec l'outil informatique, et pour eux quand tu leur livre un produit, il doit être zéro défaut, ils ont énormément de mal à comprendre qu'un produit informatique à des défauts à la livraison. Les discussions interminable avec un client pour essayer de lui faire comprendre que c'est lui qui est en faute, ben c'est une perte de temps assez conséquente.

Par exemple, j'en ai eu un dernièrement, qui s'est acheté un ordinateur portable pour pouvoir aller sur internet, lire la messagerie associée a son site. A la livraison du site j'ai été jusqu'à lui configurer Outlook pour lire ses e-mails (prestation offerte). Et bien, un mois plus tard monsieur est venu en râlant parce que sa messagerie ne fonctionnait plus et que je devait lui remettre en état (il avait mis le CD de restauration de l'ordi, mais pour lui c'était ma faute).

Leur choix sont souvent dus à une incompréhension de l'outil informatique associé à un besoin de réduire les coûts.

Je comprends ton point de vue mais pour le coup, je pense que c'est au prestataire de bien délimiter son périmètre et sensibiliser son client. Ce n'est pas forcément évident mais je pense qu'il faut aussi apprendre à dire non à son client si la demande ne rentre pas dans le périmètre d'intervention ou si cela va trop loin.

On peut compatir avec lui, trouver ça dommage, comprendre son problème mais lui faire comprendre que son problème ne rentre pas dans le cadre de la prestation qu'il a acheté. A trop donner, on se fait bouffer et on ne récolte que les problèmes je trouve parfois...

Exemple concret de faille de sécurité... MODx vient de subir une attaque par des petits malins qui ont utilisé une faille dans le gestionnaire de fichier de FCK Editor...

On a eu quelques sites hackés cet après-midi, et deux heures après un fix publié, qui ne concerne (soit dit en passant) que les personnes hébergées sur des serveurs avec register_global sur On (comme quoi, ma remarque sur l'importance de la config du serveur est bien un facteur non négligeable...)