[Sécurité] Options magic_quote_gpc, magic_quote_runtime et magic_quote_sybase

Hello,

Une question par rapport à ces directives :

magic_quote_gpc échappe les tableaux GET, POST et COOKIE.

Si (cas particulier) magic_quote_sybase est activée, certains caractères qui étaient échappés par magic_quote_gpc ne le sont plus !

magic_quote_runtime travail sur toutes les données provenant de l'éxtérieur (y compris SGBD).

Pourquoi PHP n'activent-ils pas la directive magic_quote_runtime par défaut plutôt que magic_quote_gpc ?..

Ca couvrirait toutes les éventualités en une seule fois...

Merci

Hello,

- parce que ça foutrait un beau bordel dans les programmes existants.
- l'expérience magic_quote_gpc a montré que ça ne résolvait aucune problème de sécurité, bien au contraire. D'ailleurs si je ne m'abuse les magic_quote_XXX vont être supprimés de PHP 6.
- parce que ça sert à rien : tu fais un "select" en base de données, pour afficher le contenu par exemple, il va t'ajouter des slashs partout ! Ca n'a aucun sens. Et pour les (rares) cas où ça peut servir, bah le mieux c'est que le développeur fasse le addslashes() lui même.... surtout qu'il est bien le seul à savoir s'il y en a besoin ou non.

Effectivement vu sous cette angle ça peut causer plus de problème qu'en résoudre.

Il existe plusieurs façons de cerner le problème (en jouant sur ini_get ou les flags .htaccess)... Mais le mieux n'est-il pas de tester si magic_quote_gpc est activée, et dans tous les cas supprimer ses effets (si activée) et echapper manuellement ce qui doit l'être avec une fonction PHP ou spécifique (mysql_real_escape, etc) ?

Je crois que j'ai vu quelque chose en ce sens dans le code source d'un système de gestion...

...Et je ne comprenais pas pourquoi ils avaient fait ça !

Le problème c'est que mon application pourrait être utilisée sur d'autres configurations PHP que les miennes (et accessoirement une multitude de SGBD), ce qui peut-être problématique...

D'où cette vision d'ensemble.

Yep, la plupart des "grosses applications" ou framework, utilisent une batterie de tests en tous sens pour "gèrer les magic_quotes". Pour la portabilité, pas le choix.

De plus, les magic_quotes ne font pas le même boulot que les fonctions dédiées, du coup typiquement, une variable provenant d'un formulaire va subir ce traitement :

1) addslashes automatique de PHP (magic_quotes_gpc)
2) stripslashes du développeur, pour corriger le problème
3) mysql_real_escape_string(), parce que c'est la seule solution efficace

=> les 2 premiers points auraient pu être évités si cette saleté de magic_quotes n'avait pas été inventé. :D


D'autre part, un client développe son site en se basant sur le fait que "PHP ajoute les slashs tout seul". Du coup il ne fera aucun test dans ses scripts (très très fréquent). Le jour où il change d'hébergeur (où que l'hébergeur change le paramètre...), patatra : son site est complètement exposé à un piratage, et il ne le sait même pas...


Bref, bien que partant d'une bonne intention, ce truc pourri la vie de beaucoup de développeurs et/ou webmasters, et c'est pourquoi il est retiré de PHP 6.


Note : et le "php_flag" dans ".htaccess", ça ne marche pas chez tous les hébergeurs non plus...