Quels risques de sécurité y a-t-il à permettre à quelqu'un de télécharger des scripts PHP?

Question

Supposons qu'un partenaire veuille télécharger un script PHP sur mon serveur Apache. Quel genre de chaos pourrait être causé par cela?

Quels paramètres PHP constituent des menaces? Si ces paramètres PHP sont complètement désactivés, cela permettrait-il d'insérer PHP sur mes serveurs) alors être en sécurité?

Ce sont des paramètres PHP que je connais qui posent un problème de sécurité. Quels autres sont dangereux?

Écriture sur le serveur:

fwrite

file_get_contents

FILE_APPEND

Ouverture de fichiers sur le serveur:

fopen

file_get_contents

comprendre

effrayer

url_get_contents

curl_init

curl_setopt

Suppression de fichiers:

dissocier

désarmé

Existe-t-il d'autres failles de sécurité auxquelles je devrais penser avant d'autoriser les partenaires à ajouter des fichiers .php sur mon serveur? J'imagine qu'il y a peut-être beaucoup de choses que je ne connais pas.

Je m'inquiète également des scripts de boucle qui pourraient utiliser tous mes RAM et CPU, attaques d'accès par porte dérobée, logiciels malveillants, etc.). et plus de se produire?

S'il y a du Javascript, JQuery ou d'autres langages incorporés dans le script PHP, sont-ils aussi dangereux? Et quel type de paramètres dans d'autres langages devrais-je désactiver pour protéger mon serveur?

Comment des sites Web comme jsfiddle et codepen sécurisent-ils leurs sites tout en permettant aux utilisateurs de publier leur propre code?

hmrojas.p · Answer

C'est très dangereux, car vous autorisez quelqu'un à télécharger un fichier PHP avec un code inconnu et des intentions inconnues, donc si vous avez besoin de cette fonctionnalité dans le cadre de votre site Web, vous devez durcir votre serveur, pour exemple:

Définissez un seul répertoire pour télécharger les fichiers PHP des utilisateurs, vous devez appliquer les bonnes autorisations utilisateur (lecture, écriture ou exécution) pour ce répertoire, n'oubliez pas de créer un utilisateur spécifique pour ce répertoire, pas d'utiliser root utilisateur.
Vous pouvez créer un fichier .htaccess pour le répertoire, puis vous pouvez définir des paramètres spécifiques pour ce répertoire ( Configuration du fichier .htaccess ).
Validez l'utilisateur d'entrée, même vous devez définir un format de nom spécifique et une taille maximale pour les fichiers PHP, si un fichier PHP ne correspond pas à ce format ou à son la taille est plus grande que ce qui est autorisé, alors l'application ne devrait pas permettre à l'utilisateur de télécharger ce fichier.
Utilisez la canonisation avant d'utiliser les fonctions de fichier, par exemple: realpath , basename . Cela vous aide à éviter les attaques de traversée de chemin.
Vous devez désactiver PHP les fonctions à haut risque, par exemple: exec, Shell_exec. Vous pouvez le faire via le fichier php.ini, par exemple, vous pouvez ajouter la ligne suivante pour désactiver les fonctions pour OS exécution des commandes et gestion des paramètres:
```
disable_functions =exec,passthru,Shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source 
```
La ligne suivante permet de désactiver les fonctions d'inclusion ou d'ouverture de fichiers à partir de sources externes:
```
allow_url_fopen=Off allow_url_include=Off 
```

fichier php.ini de documentation officielle

Ce sont là quelques recommandations de base. Vous devez analyser votre application Web et vos besoins pour définir les bons paramètres pour votre serveur et votre application Web.

J'espère que ces informations vous aideront.

Jacco · Answer

Si vous autorisez quelqu'un à télécharger et à exécuter un script PHP sur votre serveur, vous donnez effectivement à cette personne le droit de faire tout ce qu'elle pourrait faire, si elle avait un accès ssh avec un nom d'utilisateur/mot de passe pour traiter le script PHP s'exécute en tant que.

Donc, si la personne en question exécutait le script via Apache, elle pourrait faire tout ce que l'utilisateur Apache sur votre serveur pourrait faire.

Comme risque supplémentaire, cette personne pourrait utiliser l'accès donné pour tenter une escalade de privilèges, ce qui pourrait probablement rompre l'accord juridique que vous avez avec elle (vous avez un accord juridique, n'est-ce pas?).

Anders · Answer

Pour moi, on dirait que vous êtes sur le point de vous tirer une balle dans le pied. Laisser des personnes en qui vous ne faites pas confiance télécharger et exécuter PHP sur votre serveur est extrêmement dangereux. Voici certaines choses qu'un attaquant pourrait essayer:

Exécutez des commandes par lots prenant en charge votre serveur Web. Il peut ensuite être utilisé comme terrain intermédiaire pour attaquer d'autres serveurs à partir de votre réseau.
Lire des fichiers contenant des secrets, par ex. mots de passe, clés de chiffrement, clés TLS, etc.
Faites des attaques XSS (en utilisant JavaScript) pour voler des cookies de session ou d'autres informations d'identification à vos utilisateurs. Cela suppose que les fichiers téléchargés s'exécutent sur le même domaine ou un sous-domaine que d'autres applications.

La liste continue encore et encore et encore. Il existe des moyens de bloquer ces attaques ( hmrojas.p a quelques suggestions), mais ce n'est pas une chose simple à faire. Les fonctions de mise sur liste noire sont un début, mais la mise sur liste noire n'est jamais qu'une défense partielle. Même pour le meilleur des experts, contenant quelqu'un qui peut exécuter PHP est un défi.

En fin de compte, si vous ne faites pas confiance à la personne qui a écrit le code, vous devrez auditer soigneusement et manuellement le code pour vous assurer qu'il est bénin. Cela prend du temps et des efforts, et ce n'est pas compatible avec le téléchargement direct de fichiers.

Parfois, le seul coup gagnant est de ne pas jouer. Je dirais que c'est l'un de ces cas.

Machavity · Answer

Bien qu'il existe des sites qui vous permettent d'exécuter PHP à la demande (c'est-à-dire v4l ), ils limitent considérablement ce que vous pouvez faire et passez en revue certains des principaux cerceaux pour le faire en toute sécurité

J'utilise une configuration où les scripts sont exécutés sur une petite machine virtuelle. Pour des raisons de sécurité, cette machine n'a pas de réseau et seulement un système de fichiers minimal. Les scripts sont exécutés par un démon (écrit en Golang) et les résultats (avec des statistiques) sont rapportés à une base de données PostgreSQL. Tous les résultats sont stockés et utilisés pour fournir des moyennes pour l'aperçu des performances.

Je ne permettrais pas aux utilisateurs de télécharger des scripts PHP dans un environnement en direct. Nous avons eu un stagiaire qui écrivait un script de téléchargement d'images. Sauf qu'il a oublié de valider quoi que ce soit sur le fichier qu'il acceptait. Quelqu'un a téléchargé un script PHP malware de Turquie et a tenté de le reprendre (il aurait pu s'en tirer aussi s'il n'y avait pas eu d'autres efforts de sécurité sur le serveur).

allo · Answer

PHP a beaucoup de fonctions pour désactiver les fonctionnalités et restreindre certaines actions afin qu'il puisse être utilisé dans des scénarios d'hébergement partagé. Il est donc beaucoup plus sûr de permettre aux gens de télécharger des scripts PHP que les scripts Perl, lorsque votre serveur Web et votre instance PHP sont correctement configurés.

Je veux donc aborder autre chose que la sécurité d'urlopen et similaire: Vous autorisez les gens à exécuter des sites interactifs.

Les conséquences sont dangereuses indépendamment de la quantité de réseau ou de disque IO qu'elles peuvent créer, car elles peuvent par exemple configurer un site de phishing, ce qui peut mal refléter votre domaine et votre réputation IP.

Donc, vous ne vous retrouvez pas sur une liste noire à cause des spams car ils sont bloqués en interdisant à php d'envoyer du courrier, mais peut-être parce que vous exécutez un script qui hame les connexions Facebook de l'utilisateur.

Miles Prower · Answer

Vous mentionnez un serveur Apache, mais pas s'il a ou non PHP installé.

Chaque logiciel peut être utilisé/installé sans l'autre.

Les deux logiciels sont disponibles pour plusieurs systèmes d'exploitation .. vous n'avez pas mentionné ce qui est en jeu ici.

Dans le cas où PHP est installé sur le serveur:

Le risque est que, si le compte utilisateur PHP finit par fonctionner sous, a des droits administratifs sur la machine, il peut faire n'importe quoi dans la bibliothèque PHP.

Si ce compte n'a pas de droits administratifs, cela restreint ce qu'il peut faire.

Certains systèmes d'exploitation ont des exploits détectables/connus permettant aux comptes non administratifs d'obtenir des droits administratifs. Ceux-ci sont connus sous le nom d'exploits d'escalade de privilèges. Si un est utilisé, alors encore une fois .. ils peuvent tout faire dans la bibliothèque PHP.

Dans le cas où PHP n'est pas installé sur le serveur:

Il y a peu ou pas de risque du tout. Un fichier PHP est juste un fichier texte d'instructions que PHP interprète et agit. Il n'est pas plus nuisible qu'un fichier texte avec une recette de ragoût).

John Keates · Answer

Il n'y a aucun moyen de "sécuriser" cela. N'importe quelle quantité de permettre à quelqu'un/n'importe qui d'exécuter du code à volonté sur un système peut conduire à une prise de contrôle complète du système, soit intrinsèquement en raison de l'exécution de toutes les instructions en raison de défauts du système qui tente d'empêcher l'utilisation de certaines fonctions.

Même un langage de script dans une prison/un chroot/un conteneur en tant qu'utilisateur dédié peut finalement exploiter des vulnérabilités (existantes/nouvelles) qui permettent un accès complet à la racine et plus encore (c'est-à-dire un accès au firmware). C'est ce que les hébergeurs mutualisés doivent gérer toute la journée. La plupart de la prévention et de la correction provient de deux choses:

Légal; énumérer à l'avance ce qu'ils peuvent et ne peuvent pas faire dans un contrat
Processus; ont des licenciements et des plans de récupération en place traitent des violations/pertes