RE: [Spip] sécurité ? (était "Puisque certains dorment pas ......")

Général
1

Le dimanche, 27 avr 2003, à 19:06 Europe/Paris, Ivan a écrit :

L'éventuel problème de sécurité ne vient pas du fait d'avoir accès à tes
squelettes mais d'utiliser un outil dont le code est librement accessible à
tout le monde. Ce qui rend l'examen de son fonctionnement plus facile
(comparé à une solution non diffusée) et la détection des faiblesses à la
portée du pirate un peu connaisseur

oui, c'est vrai :slight_smile:

(et non hacker qui n'est pas forcément
un pirate).

argh, oui, victime du raccourci des médias :wink: oh le méchant hacker :-b ...bon, en tout cas le sens des mots évolue, juste voir le sens primaire de "geek" et de "nerd" :-p

À partir de là, je ne pense pas que les attaques sur les outils publics et
libres soient plus importantes que les attaques sur les autres interfaces en
général. Ni qu'un outil public et libre soit moins vite corrigé et patché
qu'un outil commercial ou un outil perso de développeur.

Je en disais pas ça... mais pour rebondir, je dirais qu'il serait peut-être (le "peut-être" est important ici!) bon de pouvoir changer très facilement certaines chose, genre "/ecrire"... non ?

--
Fabrice

2

Fabrice Girardot a écrit :

À partir de là, je ne pense pas que les attaques sur les outils
publics et
libres soient plus importantes que les attaques sur les autres
interfaces en
général. Ni qu'un outil public et libre soit moins vite corrigé et
patché
qu'un outil commercial ou un outil perso de développeur.

Je en disais pas ça... mais pour rebondir, je dirais qu'il serait
peut-être (le "peut-être" est important ici!) bon de pouvoir changer
très facilement certaines chose, genre "/ecrire"... non ?

Je ne suis pas persuadé que ça soit le plus important (par exemple de
choisir si c'est /ecrire ou /cequetuveux). Je dirais plutôt que plus un
produit est diffusé avec son code de fonctionnement accessible à tous, plus
ça permet d'en étudier les failles, un peu comme si les banques publiaient
leur plan sur internet et le fonctionnement de leur système de sécurité.
Bon, on a le droit d'être parano mais il faut aussi modérer le risque en
fonction des enjeux d'un site, qui, pour la plupart, ne sont pas vraiment
"stratégiques".
--
Ivan

3

Je dirais plutôt que plus un

> produit est diffusé avec son code de fonctionnement accessible à tous, plus

ça permet d'en étudier les failles, un peu comme si les banques publiaient
leur plan sur internet et le fonctionnement de leur système de sécurité.

Un des arguments du libre, c'est justement que plus de personnes ont accés au code, et plus nombreuses sont les personnes qui peuvent signaler les éventuelles failles de sécurité. Ya même des assocs ou des sites spécialisés dans ce genre de veille. C'est je crois comme ça que SPIP est passé de la 1.5.1 à la 1.5.2

A l'inverse, ya qu'à constater comme le champion des logiciels propriétaires à sources cachés, Microsoft, est aussi le champion des failles de sécurité.
ça me semble assez définitif.

A +,
JLuc

4

JLuc a écrit :

Je dirais plutôt que plus un
produit est diffusé avec son code de fonctionnement accessible à

tous, plus

ça permet d'en étudier les failles, un peu comme si les banques publiaient
leur plan sur internet et le fonctionnement de leur système de sécurité.

Un des arguments du libre, c'est justement que plus de personnes ont
accés au code, et plus nombreuses sont les personnes qui peuvent
signaler les éventuelles failles de sécurité. Ya même des assocs ou des
sites spécialisés dans ce genre de veille. C'est je crois comme ça que
SPIP est passé de la 1.5.1 à la 1.5.2

C'est pour cela que je disais "il faut modérer". Certes le code est public,
donc à portée de détection de failles de la part de personnes malveillantes
mais en même temps à portée de corrections rapides qu'un développeur seul,
ou son client n'auraient pas forcément vu dans son propre code. L'un dans
l'autre ça se compense. Et puis Spip n'exclut pas l'ajout de PHP
complémentaire non plus, ce qui n'en fait pas un outil fermé.

A l'inverse, ya qu'à constater comme le champion des logiciels
propriétaires à sources cachés, Microsoft, est aussi le champion des
failles de sécurité.
ça me semble assez définitif.

Tout à fait d'accord, parce qu'à cela s'ajoute une certaine culture
d'entreprise et un art du commerce particulier.
--
Ivan

5

Bon, tout doucement j'ai aussi envie d'ajouter mon grain de sel...

A la base tout a fait d'accord avec le principe de l'open source, de ses
possibilites et de ses avantages.
J'en profite assez pour ne pouvoir qu'en etre partisan.

mais...

> Je dirais plutôt que plus un
> produit est diffusé avec son code de fonctionnement accessible à
tous, plus
> ça permet d'en étudier les failles, un peu comme si les banques
> publiaient leur plan sur internet et le fonctionnement de leur
> système de sécurité.
>
Un des arguments du libre, c'est justement que plus de personnes ont
accés au code, et plus nombreuses sont les personnes qui peuvent
signaler les éventuelles failles de sécurité. Ya même des assocs ou
des sites spécialisés dans ce genre de veille. C'est je crois comme ça
que SPIP est passé de la 1.5.1 à la 1.5.2

en principe oui. le fait que plein de gens regardent le code fait que
les erreurs sont trouvees plus vite.
mais ca fait aussi que les mechants hackers (et pas les gentils geeks)
les trouvent egalement tres vite.
et le temps que 1) il y ait un patch et 2) tout le monde l'ait installe,
les hackers s'amusent !

A l'inverse, ya qu'à constater comme le champion des logiciels
propriétaires à sources cachés, Microsoft, est aussi le champion des
failles de sécurité.
ça me semble assez définitif.

Oui et non... voir plus haut... la securite par l'obscurite ne protege
pas, mais ca rend la tache plus difficile...
Mais ce qui est con, c'est leur politique de mises a jour. ca laisse aux
hackers TRES longtemps avant de pouvoir faire qqch.

Et c'est pas tout de sortir un patch, encore faut-il que les gens
l'installent !!
Et ne me dites pas que c'est de la theorie, y'a qu'a voir le probleme
actuel avec OVH, combien de personnes utilisent encore la 1.5.1 ?

Idem avec les derniers vers pour IIS et Apache, ils se basaient sur des
failles connues depuis plusieurs mois, mais que peu d'admins avaient
bouchees.

En ce qui concerne SPIP (revenons a nos moutons...), le probleme a la
base etait que selon le cas y'avait des trucs dans les fichiers des
squelettes que l'utilisateur n'est normalement pas cense voir (comme dit
: code PHP avec mot de passe d'acces a la base de donnees, code PHP
proprietaire que la societe ne souhaite pas diffuser ...) et que selon
le cas on peut lire en accedant directement au fichier.
Et c'est grave si ca tombe dans de mauvaises mains ! qui de vous fait un
dump des articles tous les jours des fois qu'un malintentionne efface la
base ?

La GPL d'ailleurs n'implique pas de mettre tes squelettes a la
disposition de tout le monde. C'est un choix que chacun peut faire, mais
il doit y avoir la possibilite de les planquer si on le veut. Je pense
que la meilleure solution est de faire un fichier zip avec les
squelettes que l'on propose au download, comme ca on a le controle du
contenu (par ex. en supprimant les mots de passe a l'interieur, ou alors
en supprimant certaines pages). Comme ca c'est clair si on les diffuse
ou pas.

C'est mon avis, pas la peine de me taper !!

Joel

6

Idem avec les derniers vers pour IIS et Apache,
ils se basaient sur des failles connues depuis
plusieurs mois, mais que peu d'admins avaient
bouchees.

Microsoft lui-même n'avait pas patché ses propres serveurs, si je ne
m'abuse.

CQFD !

:)))

JP

7

En ce qui concerne SPIP (revenons a nos moutons...), le probleme a la
base etait que selon le cas y'avait des trucs dans les fichiers des
squelettes que l'utilisateur n'est normalement pas cense voir (comme dit
: code PHP avec mot de passe d'acces a la base de donnees, code PHP
proprietaire que la societe ne souhaite pas diffuser ...)

Si tu mets du PHP dans tes squelettes, c'est que tu sais programmer.
Si tu sais programmer, tu es capable de faire include ("mon-fichier.php3"),
le "mon-fichier.php3" en question, qui contient tes données confidentielles
(codes d'accès, fonctions diverses et variées...), étant protégé par un
.htaccess.
Si tu ne le fais pas, c'est de la négligence, de la paresse ou de
l'incompétence.

(quand je dis "tu", cela ne t'est pas adressé personnellement ;-))

En tout cas il n'y a rien de compliqué ni d'insoluble dans tout cela.

Amicalement

Antoine.

8

> En ce qui concerne SPIP (revenons a nos moutons...), le probleme a
> la base etait que selon le cas y'avait des trucs dans les fichiers
> des squelettes que l'utilisateur n'est normalement pas cense voir
> (comme dit: code PHP avec mot de passe d'acces a la base de donnees,
> code PHP proprietaire que la societe ne souhaite pas diffuser ...)

Si tu mets du PHP dans tes squelettes, c'est que tu sais programmer.
Si tu sais programmer, tu es capable de faire include
("mon-fichier.php3"), le "mon-fichier.php3" en question, qui contient
tes données confidentielles(codes d'accès, fonctions diverses et
variées...), étant protégé par un.htaccess.

pas bete. le .htaccess je le pratique pas encore assez semble-t-il

Si tu ne le fais pas, c'est de la négligence, de la paresse ou de
l'incompétence.

dans mon cas plutot du confort (c'est le nom politically correct pour
'paresse'), pour eviter d'avoir 50 fichiers php avec juste 10 lignes
dedans.

(quand je dis "tu", cela ne t'est pas adressé personnellement ;-))

pas de probleme, je suis pas rancunier :wink:

En tout cas il n'y a rien de compliqué ni d'insoluble dans tout cela.

oui, c'est une solution qui me plait.
j'essaie ca

Joel