[spip-dev] Sécurité

Dev
1

Dans un article d'aujourd'hui, le journal du net met en avant les failles les plus souvent relevées dans les applications web :

http://solutions.journaldunet.com/0301/030116_failles.shtml

Bon, je sais qu'un gros travail a été fait au niveau de l'authentification par nos gentils développeurs, et je n'ai aucun doute quant au code de SPIP. Mais, en matière de sécurité, mieux vaut être prudent :wink:

Avec Apache, on évite déjà pas mal de problèmes - liées aux requêtes unicodes (IIS) -, d'ailleurs cela continue de remplir la moitié de mes logs :smiley:

Par contre, qu'en est-il du SQL injection ou des buffer overflow ?

Je n'ai jamais constaté de dysfonctionnement de ce côté, mais peut-on être assuré - rassuré :wink: - sur ces points-là

Claude

2

Salut

claude a écrit :

Dans un article d'aujourd'hui, le journal du net met en avant les
failles les plus souvent relevées dans les applications web :

http://solutions.journaldunet.com/0301/030116_failles.shtml

Bon, je sais qu'un gros travail a été fait au niveau de
l'authentification par nos gentils développeurs, et je n'ai aucun doute
quant au code de SPIP. Mais, en matière de sécurité, mieux vaut être
prudent :wink:

Avec Apache, on évite déjà pas mal de problèmes - liées aux requêtes
unicodes (IIS) -, d'ailleurs cela continue de remplir la moitié de mes
logs :smiley:

Par contre, qu'en est-il du SQL injection ou des buffer overflow ?

Je n'ai jamais constaté de dysfonctionnement de ce côté, mais peut-on
être assuré - rassuré :wink: - sur ces points-là

Claude

Comme dit le bon vieil adage en matière de sécurité : "La sécurité d'un
système ne vaut que celle de son maillon le plus faible".

Je ferais quelques remarques :
- 80% des pbs de sécurité sont le fait de "script-kiddies" qui trouvent
facilement des outils permettant de contourner les mécanismes basiques
de sécurité.
- Spip semble relativement "secure" ;-). Il y a pas (ou peu ??)
d'"exploits" publiés, peut-être parce que Spip est, pour l'instant,
moins utilisé que les nukes ?? ou mieux codé ?? Amha, c'est la deuxième
solution qui est la bonne ;-)).
- Dans les problèmes de sécurité que j'ai pu rencontrer, c'est très
souvent des pbs de mauvaises configurations d'OS serveur, d'apache, de
php ou de mysql qui sont en cause. Sans parler des mises à jour de
sécurité qui ne sont même pas faites les 3/4 du temps !!
- La "qualité" du couple login/motdepasse est bien évidemment
primordiale (Dans pratiquement 10% des nukes le couple bien connu :
God/Password n'a jamais été effacé de la base après l'installation !!).
- Bcp de gens (d'admins !!!) n'hésitent pas à donner leur login/mdp sur
simple demande plutôt que de créer un utilisateur temporaire sur leur
système.

Pour le SQL injection, cela me semble difficile avec Spip car il utilise
une syntaxe intermédiaire. L'avis des dév ??
Pour les javascripts "malveillants", Spip les ignore si on a pas
désactivé certaines choses.
Pour les buffers overflow, c'est plutôt du coté des mécanismes de
sécurité du serveur qu'il faut regarder.

A+ Yann

3

yann wrote:

Salut

claude a écrit :

[...]

Comme dit le bon vieil adage en matière de sécurité : "La sécurité d'un
système ne vaut que celle de son maillon le plus faible".

Bien pour ça que je (me) pose la question :wink:

Je ferais quelques remarques :
- 80% des pbs de sécurité sont le fait de "script-kiddies" qui trouvent
facilement des outils permettant de contourner les mécanismes basiques
de sécurité.

ok

- Spip semble relativement "secure" ;-). Il y a pas (ou peu ??)
d'"exploits" publiés, peut-être parce que Spip est, pour l'instant,
moins utilisé que les nukes ?? ou mieux codé ?? Amha, c'est la deuxième
solution qui est la bonne ;-)).

Malheureusement, AMHA, ça ne veut pas dire grand-chose : avant que certains progs soient très utilisés (open-ssh), personne ne s'était penché sur la sécurité qu'ils offraient réellement - celle de leur code :frowning:

- Dans les problèmes de sécurité que j'ai pu rencontrer, c'est très
souvent des pbs de mauvaises configurations d'OS serveur, d'apache, de
php ou de mysql qui sont en cause. Sans parler des mises à jour de
sécurité qui ne sont même pas faites les 3/4 du temps !!

là encore, ok !

- La "qualité" du couple login/motdepasse est bien évidemment
primordiale (Dans pratiquement 10% des nukes le couple bien connu :
God/Password n'a jamais été effacé de la base après l'installation !!).
- Bcp de gens (d'admins !!!) n'hésitent pas à donner leur login/mdp sur
simple demande plutôt que de créer un utilisateur temporaire sur leur
système.

De ce côté, pas de login/MDP par défaut, c'est déjà ça - mais, je ne parlais pas des bévues des utiliseurs, mais bien du code de base fourni par SPIP :wink:

Pour le SQL injection, cela me semble difficile avec Spip car il utilise
une syntaxe intermédiaire. L'avis des dév ??

Ben vi, un avis ?

Pour les javascripts "malveillants", Spip les ignore si on a pas
désactivé certaines choses.

Heu, quoi, par exemple ?

Pour les buffers overflow, c'est plutôt du coté des mécanismes de
sécurité du serveur qu'il faut regarder.

Tu veux dire du côté d'Apache ?

Claude

4

Fil wrote:

- Spip semble relativement "secure" ;-). Il y a pas (ou peu ??)
d'"exploits" publiés, peut-être parce que Spip est, pour l'instant,
moins utilisé que les nukes ?? ou mieux codé ?? Amha, c'est la deuxième
solution qui est la bonne ;-)).

En plus c'est souvent les dévs qui trouvent les trous, les corrigent et les
signalent :wink:

Pour le SQL injection, cela me semble difficile avec Spip car il utilise
une syntaxe intermédiaire. L'avis des dév ??

Non, c'est pas la question de la syntaxe intermédiaire qui nous protège,
juste le fait qu'on fait gaffe à nos requêtes.

Pour les javascripts "malveillants", Spip les ignore si on a pas
désactivé certaines choses.

Spip est plus ou moins vulnérable au "cross-site-scripting", dont le mode
opératoire est assez marrant, et la dangerosité reste à prouver. En gros, on
t'envoit un mail avec un iframe sur le site de l'attaquant ; iframe dans
lequel l'attaquant fait faire à ton navigateur un 'post' ou un 'get' d'un
javascript sur spip, et spip te retourne le javascript que tu lui as passé
(sans forcément le savoir), et ton brouteur affiche le javascript en
question... au final le mail malicieux fait s'afficher une fausse news sur
ton écran, qui provient (en apparence) du site légitime. Pigé ? :wink:
Cette attaque permet aussi de voler un cookie, mais spip est relativement
bien protégé contre le vol de cookie (du moins dans l'espace privé).

Pour le reste, pas de trou connu.

Ouf, je respire un bon coup :smiley:

Claude

5

Re

claude a écrit :

yann wrote:
> Salut
>
> claude a écrit :
>
[...]
> Comme dit le bon vieil adage en matière de sécurité : "La sécurité d'un
> système ne vaut que celle de son maillon le plus faible".

Bien pour ça que je (me) pose la question :wink:

>
> Je ferais quelques remarques :
> - 80% des pbs de sécurité sont le fait de "script-kiddies" qui trouvent
> facilement des outils permettant de contourner les mécanismes basiques
> de sécurité.

ok

> - Spip semble relativement "secure" ;-). Il y a pas (ou peu ??)
> d'"exploits" publiés, peut-être parce que Spip est, pour l'instant,
> moins utilisé que les nukes ?? ou mieux codé ?? Amha, c'est la deuxième
> solution qui est la bonne ;-)).

Malheureusement, AMHA, ça ne veut pas dire grand-chose : avant que
certains progs soient très utilisés (open-ssh), personne ne s'était
penché sur la sécurité qu'ils offraient réellement - celle de leur code :frowning:

Voir la réponse de Fil :wink:

> - Dans les problèmes de sécurité que j'ai pu rencontrer, c'est très
> souvent des pbs de mauvaises configurations d'OS serveur, d'apache, de
> php ou de mysql qui sont en cause. Sans parler des mises à jour de
> sécurité qui ne sont même pas faites les 3/4 du temps !!

là encore, ok !

> - La "qualité" du couple login/motdepasse est bien évidemment
> primordiale (Dans pratiquement 10% des nukes le couple bien connu :
> God/Password n'a jamais été effacé de la base après l'installation !!).
> - Bcp de gens (d'admins !!!) n'hésitent pas à donner leur login/mdp sur
> simple demande plutôt que de créer un utilisateur temporaire sur leur
> système.

De ce côté, pas de login/MDP par défaut, c'est déjà ça - mais, je ne
parlais pas des bévues des utiliseurs, mais bien du code de base fourni
par SPIP :wink:

>
> Pour le SQL injection, cela me semble difficile avec Spip car il utilise
> une syntaxe intermédiaire. L'avis des dév ??

Ben vi, un avis ?

Voir réponse de Fil :wink:

> Pour les javascripts "malveillants", Spip les ignore si on a pas
> désactivé certaines choses.

Heu, quoi, par exemple ?

Notamment le fait que Spip "parse" le texte d'un article comme du texte
non exécutable

> Pour les buffers overflow, c'est plutôt du coté des mécanismes de
> sécurité du serveur qu'il faut regarder.

Tu veux dire du côté d'Apache ?

Là, je dirais plutôt du coté de l'OS serveur et de php :wink: puisqu'il
s'agit des piles-mémoires utilisées par les applications ou processus en
cours.
On ne peut provoquer un buffer overflow pour "l'application apache" que
soit en passant par php ou en passant par l'OS serveur.
Une explication pas mal (surtout compréhensible) du buffer overflow à
http://www.securiteinfo.com/attaques/hacking/buff.shtml
De toutes façons, quand quelqu'un utilise le buffer overflow, ce qui
l'interresse, c'est de prendre la main sur tout le serveur. Pour lui
l'application php n'est qu'une porte d'entrèe.

A+ Yann