Security

Jump to: navigation, search

Magic quotes

Analyse sur : http://de2.php.net/manual/fr/security.magicquotes.php

La fonction setslashes du fichier pool/functions.php doit être utilisée uniquement dans le cas pour lequel elle est prévue comme indiqué dans son commentaire :

* Add slashes if require (ie magic_quote_gpc=Off). Should be use each time we get back a Get, Post or Cookie (G,P,C)

En effet, c'est dans ces cas là, que le magic_quote_gpc intervient.

C'est d'ailleurs de cette façon qu'est proposée une telle fonction dans le livre "php 5 avancé" page 184.

Pour le reste :

magic_quote_runtime

Pour le moment, OF le considère à ON comme préconisé et par défaut. En tout cas, il n'a pas à être traité (si on le traite), au même endroit que le gpc puisque la provenance est "opposée" :

gpc=entrée utilisateur devant être également une entrée base de données

et

runtime=sortie de base de données et devant être affiché (donc sortie utilisateur).

A la limite, si on veut se pencher là-dessus, il faut également se pencher sur le "cross site scripting" qui permet notamment d'injecter du javascript. Le risque se situe, je pense, essentiellement dans les commentaires des résas. Pour le moment, voici ce qui est fait :

  • lorsqu'on récupère un commentaire (avant de le mettre en base) :
$comments=ereg_replace('[ [:cntrl:]]',' ',nl2br(htmlentities($comments)));

cela doit bloquer le cross site scripting pour l'html, et cela remplace les retours lignes par des < br />. Les caractères non visibles (cntrl) sont également virés.

  • avant d'afficher un commentaire (qui vient donc de la base) dans le cahier :
$comments=addslashes($booking->getComments());
  • avant d'afficher un commentaire (qui vient toujours de la base) dans le champ commentaire (dans le cas d'une modif de résa par exemple) :
str_replace('< br />',"\n",stripslashes($comments))

le but est de remettre les retours lignes puisque les < br /> ne seront pas interprétés, et de supprimer les slashes qui viennent (à confirmer) du magic_quote_runtime. Eventuellement, là on peut faire un test, à voir...

magic_quote_sybase

Il n'est pas traité, et considéré à Off, comme par défaut. Attention !!! Le mettre à On, dégrade la sécurité.

Authentification par certificats SSL

Afin de restreindre l'accès de la partie gestion des clefs aux pcs qui se trouvent dans les clubs (et non pas aux membres à partir d'un pc à la maison), nous pouvons envisager l'utilisation d'authentification par certificat SSL.

Résumé du fonctionnement :

sur le serveur OF, nous disposons d'un certificat CA SSL. Nous générons pour chaque club un certificat client signé par notre CA certificat. Ensuite, il n'y a plus qu'à ajouter qq lignes dans la configuration d'apache pour restreindre l'accès à une partie du site web (en https) aux possesseurs d'un certificat client signé.

Problèmes de cette technique :

  • on va devoir utiliser du https (niveau ressource serveurs, c'est plus couteux en CPU, mais ça devrait rester largement raisonnable)
  • le plus gros problème : il va falloir gérer les certificats clients des clubs (!) (sachant qu'ils ont une durée de validité qu'il serait bon de mettre à 1 an je pense)

plus d'explication : http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html