Hébergeurs : bloquer l’accès à certaines fonctions PHP

Posted on by Kevin Decherf

Si safe_mode est efficace, il n’en est pas moins trop efficace au point d’empêcher le bon fonctionnement d’un certain nombre de sites …

Si vous souhaitez bloquer seulement quelques fonctions (safe_mode ou pas), vous avez à votre disposition la directive disable_functions à mettre dans le fichier php.ini.

disable_functions=mail,fopen,exec

A noter que cette astuce est très efficace avec des solutions comme SuPHP permettant d’avoir un php.ini séparé par site.

Related Posts:

  • Pierre Bourdon

    Le mieux reste quand même d’avoir une sécurité efficace à un niveau au dessus (droits UNIX par exemple, genre pas faire tourner les process de tout le monde en www-data). Car disable_functions c’est bien beau, mais il suffit qu’on trouve une faille et/ou une utilisation détournée d’une fonction autorisée et tout est par terre. Et les failles sont surement beaucoup plus présentes dans les fonctions de PHP que dans la gestion des droits du kernel.

    Cf. le bordel avec curl et les URLs en file:// par exemple.

    D’ailleurs, c’est ce genre de pseudo-sécurités qui bloque le plus le développement d’alternatives à PHP chez les hébergeurs gratuits : la plupart font reposer toute la « sécurité » de leur système d’hébergement sur disable_functions ou safe_mode…

  • http://blog.kdecherf.com/ Kevin Decherf

    @Pierre Bourdon
    Oui bien entendu, ma solution n’est pas là pour jouer l’alternative aux jails ou autre ;-)
    Concernant les limitations de disable_functions, c’est là aussi l’intérêt d’avoir des php.ini séparés en fonction des sites et des besoins.

  • Pierre Bourdon

    En vrai, je vois deux utilisations possibles de disable_functions, dont une à laquelle je n’avais pas pensé en écrivant le commentaire #1.

    La première de ces utilisations, c’est la protection de la plateforme d’hébergement. Celle là est ridicule pour toutes les raisons évoquées dans #1, j’espère que l’on est plus ou moins d’accord là dessus.

    La deuxième c’est de servir de dernier bouclier en cas de faille trouvée dans le site et exploitée. On y met les fonctions qui ne sont pas utiles au site, et comme ça on réduit fortement les possibilités d’atteinte au système (au moins via des exploits génériques, après…). C’est une utilisation de disable_functions qui me semble un peu plus intéressante, mais assez obsolète façe à ce qu’on pourrait faire si PHP supportait nativement la signature de code. Ainsi, l’interpréteur posséderait la clé publique Y pour n’exécuter que le code signé par la clé privée qui correspond à Y. Ça éviterait de nombreux problèmes, dont celui de l’exploit d’un site vulnérable.