Il me semble que vous êtes sur le point de vous tirer une balle dans le pied. Laisser des personnes en qui vous n'avez 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 batch prenant le contrôle de votre serveur Web. Il peut ensuite être utilisé comme terrain de transit pour attaquer d'autres serveurs depuis votre réseau.
• Lire des fichiers contenant des secrets, par exemple 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 de vos utilisateurs. Cela suppose que les fichiers téléchargés fonctionnent sur le même domaine ou un sous-domaine que d'autres applications.

La liste s'allonge encore et encore. Il existe des moyens pour essayer de bloquer ces attaques ( hmrojas.p a quelques suggestions), mais ce n’est pas simple. Les fonctions de liste noire sont un début, mais la liste noire n'est jamais qu'une défense partielle. Même pour les meilleurs experts, contenir 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 vérifier soigneusement et manuellement le code pour s'assurer qu'il est bénin. Cela prend du temps et des efforts et 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.

Bien qu'il existe des sites qui vous permettent d'exécuter du code PHP à la demande (c'est-à-dire 3v4l), ils limitent sévèrement ce que vous pouvez faire et sauter à travers quelques obstacles majeurs pour le faire en toute sécurité

J'utilise une configuration où les scripts sont exécutés dans 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 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 n'autoriserais pas les utilisateurs à télécharger des scripts PHP dans un environnement en direct. Une fois, nous avons eu un stagiaire qui écrivait un script de téléchargement d'image. Sauf qu'il a oublié de valider quoi que ce soit sur le dossier qu'il acceptait. Quelqu'un a téléchargé un script de malware PHP depuis la Turquie et a tenté de le prendre en charge (il se serait également débrouillé avec lui sans d'autres efforts de sécurité sur le serveur).

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 des 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 à gérer des sites interactifs.

Les conséquences sont dangereuses indépendamment de la quantité d'E / S réseau ou disque qu'ils peuvent générer, car ils peuvent par exemple configurer un site de phishing reflètent mal 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çonne les connexions Facebook de l'utilisateur.

Vous mentionnez un serveur Apache, mais pas si PHP est installé ou non.

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, devrait le compte utilisateur sous PHP finit par fonctionner sous, ils ont des droits d'administration sur la machine, ils peuvent tout faire dans la bibliothèque PHP.

Si ce compte n'a pas de droits administratifs, cela limite ce qu'ils peuvent faire.

Certains systèmes d'exploitation ont des exploits détectables / connus permettant aux comptes non administratifs d '«obtenir» des droits administratifs. Ce sont des exploits d’escalade de privilèges. Si on en utilise, alors encore ... ils peuvent faire n'importe quoi 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 à tout. Un fichier PHP est juste un fichier texte d'instructions que PHP interprète et agit sur. Ce n'est pas plus dangereux qu'un fichier texte avec une recette de ragoût.

Il n'y a aucun moyen de «sécuriser» cela. Toute 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 en raison de l'exécution de toutes les instructions, soit en raison de défauts dans le système qui tente d'empêcher certaines fonctions d'être utilisées.

Même un langage de script dans une prison / chroot / conteneur en tant qu'utilisateur dédié peut en fin de compte exploiter des vulnérabilités (existantes / nouvelles) qui permettent un accès root complet et plus (c'est-à-dire un accès au firmware). C'est ce à quoi les hébergeurs mutualisés doivent faire face toute la journée. La plupart de la prévention et de la réparation vient de deux choses:

1. Légal; lister ce qu'ils peuvent et ne peuvent pas faire dans un contrat à l'avance

2. Processus; ont mis en place des redondances et des plans de récupération; traitent les violations / pertes

Oui, vous allez vouloir faire du bac à sable. Le moyen le plus simple de le faire est probablement de l'exécuter dans une VM ou un conteneur docker . Bien sûr, vous devrez alors auditer la sécurité à ce sujet.