Général
- Présentation
- Les Symboles
- Les Métacaractères
- Les Ancres et Classes
- Les options
- Constantes prédéfinies
- Equivalences
- Créer un motif
- Les POSIX
- Les PCRE
- Les Plus des PCRE
- Les Assertions Part I
- Les Assertions Part II
- Motif conditionnel
- Mysql et les regex
- Url Rewriting
- Optimisation
- Aide mémoire
Les PCRE
Les POSIX
Pratique
Linux
Spécial php
- Conseils et Astuces
- Délimiteur PCRE
- Créer une bdd
- Utiliser du BBcode
- Le binaire
- Faire un panier
- Cases à cocher
- Citations imbriquées
- Colorateur syntaxique
- Les list-box ou combo-box
- Faire un diaporama
- Isset ou empty ?
- Une légende au survol
- Site en plusieurs langues
- Requêtes dynamiques
- Gestion des smiley
- Faire un moteur de template
- Timestamp php/mysql
- Timestamp mysql
- Matcher une adresse email
- Controler des données
Les billets de fred
- Les POSIX... mise en pratique !
- Limiter l'accès à un répertoire
- Alternance de couleurs
- Magic_quotes
- Désactiver les short_tags
- Require ou include : Bench
- Cohérence dans les chaines de caractères
- "echo" : lapin ou tortue ?
- Gérer un formulaire avec plusieurs boutons
- Le formulaire a t'il été soumis ?
- J'ai décidé de grossir
- La guerre des étoiles
- La guerre des boutons
- Headers already sent
- IP, IP, IP, houra !
- Créer un itérateur avec PHP5
- On vous conduit vers la lumière
- Comment utiliser MySQL avec PHP
- Non aux booléens !
- Php.ini : dist /recommended
- Include : gouffre ou fêlure ?
- Simple comme les sessions !
- Simplifier le traitement des erreurs
- Structurez vos applications
- Franchement, t'es trop for !
- Notice: Undefined variable (ou index)
- Proscrire les variables auto déclarées
Variables auto-déclarées : Pourquoi c'est mal ?
Une caractéristique qui a fait le bonheur de nombreux développeurs PHP est la déclaration automatique des variables. Mais les temps changent et désormais, il est recommandé de ne pas utiliser cette fonctionnalité !On parle de quoi là ?
Vous savez, lorsque vous créez par exemple un cookie dont le nom est "utilisateur", sur toutes les pages de votre site, vous pouvez utiliser directement la variable $utilisateur qui est automatiquement créée par PHP à l'initialisation du script. Il en va de même pour les données transmises dans les liens, les formulaires ou les sessions. C'est très pratique, et surtout extrêmement simple à utiliser.Cette fonctionnalité qui existe depuis la création de PHP est actuellement remis en cause et désormais le paramètre de configuration "register_globals" est à "off". Cela implique que les variables ne sont plus déclarées automatiquement et vous devez accéder aux tableaux $_GET, $_POST, $_COOKIE, $_SESSION, etc. afin de traiter vos données.
Pourquoi avoir fait une telle chose ?
Tout simplement à cause de notre bêtise ! Oui, vous .. moi .. nous tous avons usé et abusé par le passé de cette fonctionnalité sans toujours trop réfléchir, et nous avons engendré des anomalies et autres trous de sécurité par manque de discernement !Heu .. je ne comprends pas bien là !
Si je fais "echo $utilisateur;", d'où vient cette variable ? De la session ? D'un formulaire ? D'un cookie ? C'est une variable locale ? En fait, rien ne permet de connaître sont origine et si par distraction, vous partez par exemple du postulat que votre variable est locale, vous risquez de bien mauvaises surprises.Voici un petit exemple. En voulant bien faire, on a séparé la partie traitement de la partie présentation, ce qui nous donne ceci :
Admin.php
<?php
if( $login == 'admin' and $pass == 'passadmin' ) {
$admin = true;
} else {
$admin = false;
}
require 'affichage/affichage.inc.php';
?>
affichage.inc.php (dans un répertoire "affichage" protégé par un .htaccess, mais on a oublié de le mettre !)
<?php
if( $admin == true ) {
echo 'Phrase secrète réservée à l\'administrateur';
}
?>
Dans cette situation, si on utilise l'URL suivante :
http://www.monsite.com/affichage/affichage.inc.php?admin=1
La phrase secrète s'affiche !
Cela peut vous paraître trivial, mais de nombreux trous de sécurité étaient basés sur ce principe.En fait, register_globals à "on" n'est pas un trou de sécurité, mais il les favorise si l'on n'est pas attentif.
Le danger est d'autant plus grand avec les sessions car normalement, l'utilisateur ne peut pas modifier leur contenu. Dans le cas de pages réservées aux membres, au lieu de redemander l'identifiant et le mot de passe à chaque fois, on place une donnée en session indiquant que la personne est authentifiée. Seulement, si on n'utilise pas le tableau $_SESSION, mais directement une variable auto-déclarée, vous vous exposez au risque qu'un utilisateur déclare cette donnée dans l'URL de la page.
C'est très pénible de devoir écrire $_SESSION['xxxx'] !
Oui, mais disons que c'est pour notre bien et aussi parce que nous l'avons bien cherché en développant des scripts bourrés de fautes d'inattention.
Si je dois changer mes vieux scripts, je vais avoir trop de boulot !
Je suis entièrement d'accord avec vous, mais ce n'est pas une raison pour continuer les nouveaux développements avec les variables auto-déclarées. Laissez le register_globals à "on" pour que vos vieux scripts fonctionnent encore, mais faites comme s'il était à "off".
Remarque : Pour les sessions, vous devez obligatoirement utiliser le tableau $_SESSION et ne plus jamais faire appel à session_register car cette fonction permet justement de déclarer automatiquement les variables de sessions, ce qui entre en conflit avec le register_globals à "off".
Par Frédéric Bouchery
