Magazine Internet

Les 4 plus importantes astuces de sécurité pour PHP

Publié le 13 novembre 2008 par Dator

PHP est un langage qui grandis de jour en jour et a une certaine maturité dans les développement. Néanmoins, certains failles restent béhantes sur des sites crées par des personnes ne connaissant pas les recoints de ce langages.

1. Les Register Globals

Jusqu’à la version 4.2.0 de PHP, les register_globals était activé par default. Depuis, il sont désactivés. Rappelons de même que cette fonctionnalité est totalement absente dans la futur version 6.0.0 de PHP.

Quand le register_globals est activé, PHP injecte dans le code des variables suplémentaires comme les requêtes HTML … Le problème est que un petit malin peut grâce à une simple manipulation de l’information de la requêtes passer une protection.

Imaginons, que nous avons un système de connexion à une partie administration simple.
Seulement en changeant un petit peu l’adresse, il peut totalement passer la protection.

//index.php?auth=true
if($auth){
// On peut voir les informations confidentiel.
}

Les informations sur register_globals se trouve dans le php.ini .

2. Les rapports d’erreurs (Error Reporting)

Quand on développe un site complexe, il est intéressante d’avoir un rapport d’erreur détaillé avec la ligne dans le code, une partie du code, le code d’erreur, le fichier ou se situe l’erreur . Moi, j’appelle ça des informations sensible, car le moindre petit malin qui remarque une erreur, peut réussir à exploiter une faille que vous n’aurez surement jamais cru ouverte.

La bonne approche pour le développement :

error_reporting(E_ALL);
ini_set('display_errors','On');

La bonne approche pour la mise en production (quand le site est en ligne) :

error_reporting(E_ALL);
ini_set('display_errors','Off');
ini_set('log_errors', 'On');
ini_set('error_log', '/path/to/error/log');

ou

error_reporting(E_ALL | E_STRICT)

3. La faille XSS (Cross-Site Scripting)

Sous ce nom barbare se cache la pire des failles PHP qui puisse exister, car c’est la plus simple et la plus ouverte . L’erreur du développeur est de ne pas filtrer le contenu passer dans les champs de formulaire par exemple.

Nous allons prendre exemple d’un simple formulaire :


Le PHP (action.php) va nous envoyer une variable sous cette forme de façon tout à fait normal :

$_POST['pseudo'];

Le soucis est que si moi, petit malin, je met un code vraiment très simple dans le champ et que le développeur ne filtre pas ses champs, il va se trouver dans une situation très embêtante.
Avec uniquement ce bout de code dans le champ:

while(1){
alert('toto');
}

Je vous conseille donc de filtrer vos champs de cette façon là :

$clean_message = strip_tags($_POST['pseudo']);

et ensuite

htmlentities($clean_message, ENT_QUOTES, 'UTF-8');

4. Les données critiques

Pour finir, une faille qui peut être critique pour les gros sites de partages de documents ou autres (et même les petits sites).

Pour cela il faut protéger les données grâce au .htaccess, un petit script que apache va lire et lancer très simplement.

Pour protéger toute donnée, il vous faut donc un .htaccess avec ce code à l’interieur :

deny from all

Résumé :

  1. Mettre les register_globals à Off.
  2. Désactivé error_reporting dans l’environnement de production.
  3. Faire attention à filter vos données pour eviter la faille XSS .
  4. Protéger vos données avec les .htaccess.

Article original écrit par Dator et publié sur Dator.fr, le 2008. | Lien direct vers cet article | © Dator.fr - 2008
Mot clés: PHP


Retour à La Une de Logo Paperblog

A propos de l’auteur


Dator 51 partages Voir son profil
Voir son blog

l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte

Dossier Paperblog