spécifications V2
Configuration technique :
Apache 2.0
PHP5
spécifications sécurité :
PHP :
- empêcher les inclusions PHP
L'inclusion se fait principalement par la méthode $_GET. On doit empêcher de pouvoir injecter du code à travers les variables. Par exemple on transforme une url index.php?v=12 en index.php?v=12;phpinfo();
Cela permet de récupérer les informations sur la configuration php par exemple.
Pour contrer cela, on vérifie tout ce qu'on récupère. Voir ci dessous get sécurisé.
- empêcher les injections PHP / mySQL
Les injections php / mysql sont très similaire à l'inclusion php à la différence qu'on essaye d'executer du code mysql. Avec l'exemple précédent, on suppose que v est pour une requete, ce qui donnerait
SELECT * FROM article WHERE id=$v;
Et bien on pourrait remplacer v=12 par index.php?v=12; DELETE * FROM article WHERE id != 0 ce qui a pour résultat final d'effacer une base de donnée. Voir ci dessous get sécurisé.
- empêcher les injections HTML / javascript
Dans ce cas au lieu d'injecter du code php, on essaye d'injecter du code javascript. On peut par exemple injecter du code comme onclick="" ou autre. Voir ci dessous empêcher injection html / javascript
Authentification :
- ne pas tout baser sur les cookies. On utilise les cookies en priorités, mais si désactivé on passe par les session uniquement côté serveur
- sécuriser les sessions en ne pas les utilisants n'importe comment :
- inclusion d'un fichier de vérification : secure
- ne pas utiliser session_register (session_start() à la place
- ne pas utiliser session_unregister (unset($_SESSION['nom_de_la_variable'])
- ne pas utiliser session_is_registered() (isset($_SESSION['nom_de_la_variable'])
- encoder plutôt en sha1 qu'en md5 (md5 va devenir déprécié)
- si besoin d'une haute sécurité, ajouter SSL
- ne jamais activer les variables globals (register_globals = off)
- dans le cas d'une déconnection manuel, utiliser session_destroy()
- supprimer les session, ne pas les stocker continuellement.
Sécurité des formulaires
- Toujours faire les vérifications au niveau php, ne jamais se contenter du javascript (php doit au minimum vérifier ce que vérifie javascript)
- Toujours vérifier qu'on ne puisse pas injecter de code (htmlentities)
Administration
- le dossier d'administration doit être protégé au minimum par un htaccess
- les fichiers de configuration doivent être protégés au cas ou ils seraient lancé indépendement.
- les paramètres de configuration sont stockés dans une base de donnée. Dans le cas ou on ne veut pas utiliser de base de donnée, on peut prévoir une sauvegarde via un fichier xml.
- la première installation doit se faire facilement et être uniquement dépendante des fonctions de base du site (mot de pass administrateur, infos base de donnée). Le fichier d'installation doit être sécurisé pour qu'on ne puisse pas relancer l'installation des données à l'insu de l'administrateur.
Graphique
- la seule obligation est que le fichier soit compatible au minimum avec IE / FF, mais tester sur autant de navigateur différents est un gros +.
- la charte graphique est assez large, il n'y a pas de restriction, celle ci pouvant être adapté selon les nécessités. L'idée finale est de proposer plusieurs présentations différentes.
- Un plus est de penser la charte graphique selon l'accessibilité (par exemple pour personne mal voyante). Cela peut venir d'un css entièrement dédié à ça.
Utilisateur
L'interface utilisateur doit être la plus simple et la plus direct possible. Les liens doivent être imbriqués le moins possibles et doivent être le plus explicite et intuitif possible.
get sécurisé
dans 98% des cas, les variables passés par get sont des mots ou des valeurs numériques. Ainsi, pour empêcher l'injection de code, on peut vérifier tous les GET reçu et de les vérifier à l'aide d'une simple fonction.
function checkrequest($nom)
{
if ( $_REQUEST[$nom] == eregi_replace('^[a-z0-9_]', '', $_REQUEST[$nom]) )
return $_REQUEST[$nom];
else
return false;
}
Dans cet exemple on accepte les caractères suivants : a à z, A à Z, 0 à 9, _ On peut ajouter des caractères si nécessaires (exemple : . @ pour transmettre une adresse mail)
On donne donc le nom de la variable. Si cette dernière valide, on renvoit la variable, sinon on ren
voit false.
Cela ressemble à :
foreach($value as $_GET)
if ( !checkrequest($value) ) exit();
Dans notre cas si une erreur existe, on quitte complètement le script, mais tout autre traitement peut être envisagé (un exit() ne sert pas à grand chose, c'était uniquement dans le cas de notre exemple).
problèmes liés aux spécifications
Toutes les spécifications de la V2 sont sensés être appliqués (et sont appliquables). Cependant elles sont parfois plus une perte de temps qu'autre chose (mais il faut quand même le faire). Dans le cas ou on fait fonctionner un module qui ne respect pas toutes les spécifications V2, il faut écrire dans un rapport en quoi ce n'est pas conforme à la V2 afin de le corriger plus tard (ne pas laisser un module non conforme à la V2).
