PHP: Comment désactiver les fonctions dangereuses
Comment désactiver la fonction dangereuse eval ? Cela peut-il être fait avec ini_set function?
Aussi, comment désactiver les fonctions suivantes? Pouvons-nous les désactiver en utilisant ini_set function?
allow_url_fopen
allow_url_include
exec
Shell_exec
system
passthru
popen
stream_select
eval est l’une des fonctions les plus dangereuses que les méchants peuvent utiliser pour exploiter les choses. Il devrait y avoir un mécanisme pour désactiver cela sans avoir recours à php.ini file; mais cela devrait être fait par programme.
Eh bien, les gars je cherche une réponse suggérant de désactiver ces jolis compagnons dangereux sans aller dans php.ini file; Je veux dire comment les désactiver au moment de l'exécution ou par programme?
Merci d'avance....
Mettre à jour
Quelqu'un a-t-il entendu parler de PHP Script Shell Offender? Il utilisait principalement la fonction eval pour l'exploit. Les pirates peuvent utiliser leur code PHP sur votre site.
Ma question était que je ne voulais pas désactiver la fonction eval du fichier php.ini. Par exemple, j'ai développé mon propre framework MVC. Maintenant, les utilisateurs de la structure peuvent spécifier à partir du fichier de configuration de la structure si la fonction eval (et autres) doit être désactivée ou non. Donc, cela est laissé au choix des utilisateurs du framework. Une fois qu'ils spécifient de le désactiver; Je devrais être capable de désactiver la fonction eval par programme.
Voilà donc le scénario. Chercher des réponses/solutions utiles.
Merci encore.
Pour désactiver des fonctions, principalement pour des raisons de sécurité, vous pouvez utiliser la directive disable_functions dans votre fichier de configuration php.ini.
Mais, comme le dit la documentation:
Cette directive doit être définie dans php.ini Par exemple, vous ne pouvez pas définir cela dans Httpd.conf.
Je suppose que c'est trop "interne" pour pouvoir être configuré ailleurs qu'en PHP ... Et comme c'est lié à la sécurité, c'est à l'administrateur système de le configurer.
Néanmoins, la meilleure mesure de sécurité consiste à écrire du code propre/sécurisé, à filtrer toutes les entrées, à échapper à toutes les sorties ... Et ne laissez personne exécuter son propre code sur votre serveur!
Peur que vous soyez plutôt coincé en utilisant php.ini pour désactiver la plupart de ceux-ci. Cependant, la situation empire. eval() n'est techniquement pas une fonction, c'est une construction de langage, donc il NE PEUT PAS être désactivé avec disable_functions. Pour ce faire, vous devez installer quelque chose comme Suhosin et le désactiver à partir de là.
Un bon webmaster devrait considérer qu'une revue de sécurité est une partie essentielle de la configuration du site. N'essayez pas de résumer complètement cela, les gens sont déjà assez paresseux pour la sécurité. Si vous comptez utiliser des outils (comme un hébergeur Web), vous devez prendre l’initiative d’avoir au moins une connaissance sommaire de la gestion de celui-ci de manière responsable.
Cela dit, vous pouvez faire certaines choses pour paralyser gravement la plupart des tentatives de piratage, notamment:
-Disable base64_decode() utilisant disable_functions. Maintenant, il y a des façons de contourner ce problème, mais la grande majorité des scripts de piratage sont de nature générique, ce qui en détruit environ 95%, car ils ont besoin de l'existence de ces deux fonctions pour fonctionner correctement. Cela ne signifie pas que votre serveur ne peut pas être piraté, mais dans la plupart des cas, cela impliquerait la surcharge de renifler manuellement votre serveur pour détecter les vulnérabilités, et la plupart des pirates informatiques jouent les chiffres et n'ont pas le temps de le faire (NOTE: certains pirates ont temps pour cela, ce n’est pas une solution magique en soi).
-Filtrez toutes les entrées pour d'autres modèles de chaînes d'exploits communs tels que <?php, qui est fréquemment utilisé pour faire du bruit par une balise php d'ouverture non remarquée. Il existe plusieurs modèles de ce type. La meilleure pratique consiste à ajouter à la liste blanche des caractères spécifiques et à en rejeter tous les autres, entrée par entrée. Au minimum, filtrez les terminaisons nulles susmentionnées et les chaînes d’injection SQL possibles telles que '; -- (ne supposez pas que le simple fait d’utiliser pdo ou mysqli va filtrer TOUTES les tentatives d’injection, il existe encore quelques utilisent correctement les déclarations préparées).
-Tous les répertoires ne servant que des médias devraient avoir tous les accès de script désactivés, et tous les téléchargements et les médias ne devraient être placés que dans un tel répertoire. Il est préférable de ne mettre en liste blanche que les supports acceptables, plutôt que les scripts de liste noire, car il existe différentes manières d'exécuter un fichier de script (par exemple: php, php5, phtml, etc.) qui peuvent ne pas être disponibles individuellement sur un environnement de serveur donné. . Vous pouvez le faire avec un simple .htaccess placé dans le répertoire des médias, semblable à ceci:
php_flag engine off
AddHandler cgi-script .php .php3 .php4 .phtml .pl .py .jsp .asp .aspx .htm .html .shtml .sh .cgi
Options -Indexes -ExecCGI
<Files "\.(jpe?g|png|gif|bmp|tiff|swf|flv|mov|avi|mp4)$">
order deny,allow
deny from all
</Files>
Cette partie peut être écrite dynamiquement par php, de sorte que votre application serait capable de sécuriser des répertoires sensibles de la même manière, ce qui pourrait atténuer les souffrances des hackers, ce qui est généralement négligé. J'ajoute généralement un .htaccess similaire à presque tous les sites Wordpress sur lesquels je travaille dans le répertoire uploads, et je me suis souvent demandé pourquoi cela ne se fait pas tel quel, car il bloque de nombreuses tentatives de piratage et n'interfère pas avec l'application. de quelque façon que j'ai remarqué.
Malheureusement, si vous n'êtes pas sur un serveur Apache, vous devrez trouver une autre solution (sur IIS, il y a probablement un équivalent, mais je ne suis pas au courant de ce que ce serait personnellement).
-Vous devez également configurer votre .htaccess (ou web.config/etc) pour désactiver toutes les méthodes d'accès non nécessaires à votre application spécifique. Si vous n'utilisez pas de services Web RESTful, il n'y a vraiment aucune raison d'autoriser PUT ou DELETE, vous devriez certainement certainement également désactiver TRACE et n'avez probablement aucune raison de laisser OPTIONS ou HEAD activé. Il convient également de mentionner que toutes les méthodes de connexion non reconnues résolvent par défaut en GET, ce qui signifie que, à partir de la ligne de commande, je peux effectuer les opérations suivantes:
curl -X BOOGITY -d arg=badstuff -d arg2=morebadstuff yoursite.com
Dans cet exemple, BOOGITY n'a pas de sens, cependant, votre serveur l'interprétera comme suit:
curl -X GET -d arg=badstuff -d arg2=morebadstuff yoursite.com
Cependant, votre application ne le fera probablement pas. Pour éviter cela, vous devez configurer votre serveur de manière à ce qu'il n'accepte que GET en tant que GET et ne lui permette pas d'être la valeur par défaut.
Dans la plupart des cas, l'objectif principal n'est pas de rendre difficile l'exécution de modèles php spécifiques dans votre environnement, mais d'empêcher l'inclusion de code non autorisé (localement ou en externe) afin d'éviter tout problème. Si vous autorisez l'installation de modules ou autres dans votre CMS, les programmeurs bâclés créeront des exploits que vous ne pouvez pas vraiment faire si vous n'appliquez pas des paramètres d'API assez rigoureux qui rendent très difficile une mauvaise exécution, mais cela ne peut jamais être le cas. rendu impossible. Ne sous-estimez jamais la capacité d'un magasin de piratage offshore ou d'un auto-proclamé «php ninja» de travailler avec diligence avec votre système de la manière la plus sécurisée ou non conforme possible, de créer des vulnérabilités énormes et d'inventer un grand nombre de piratages giratoires pour le faire effectivement plus difficile à retirer que de le faire de la bonne façon.
/ rant de sécurité.
En bref: vous ne pouvez pas faire ça.
Mais je pense que vous ne comprenez pas vraiment comment eval et ces fonctions sont exploitées. Le problème survient lorsque les programmeurs ne nettoient pas correctement les ARGUMENTS qui leur sont transmis.
Le script pour délinquant shell Shell que vous avez mentionné est juste un simple script PHP transmettant des arguments à ces fonctions. Mais les attaquants avaient déjà un moyen d’injecter/de télécharger le script malveillant. Si vous n'utilisez ni ces fonctions ni les arguments de l'utilisateur, les attaquants ne peuvent pas exécuter de code arbitraire sur votre serveur à l'aide de eval () ou de proches.
Allez-vous héberger ce framework pour vos utilisateurs? Si vous autorisez les utilisateurs à télécharger et à exécuter du code, vous avez un problème plus grave entre vos mains.
Lisez à propos de l'exécution de code à distance et l'inclusion de fichiers à distance/local ici pour en savoir plus sur les attaques liées à ceci: Common PHP vulnérabilités
La directive disable_functions est uniquement disponible dans la configuration php.ini .
Désactiver des fonctions au moment de l'exécution n'aurait aucun sens, car vous seriez en mesure de modifier la liste des fonctions désactivées au moment de l'exécution pour réactiver également les fonctions.
Vous pouvez désactiver eval via https://github.com/mk-j/PHP_diseval_extension et contourner le problème selon lequel suhosin n'est pas compatible/stable avec php7.