Nous choisissons chaque fichier PHP qui peut être exécuté dans le nginx, un par un. Dans le cas présent, ça veut dire que si on dépose un nouveau fichier PHP, celui-ci ne sera pas exécuté (sauf exception détaillée après)
location ~* /test.php$ {
try_files $uri $uri/ =404;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
root /var/www/html/;
}
Les problèmes de cette méthode sont simples, dans un premier temps ce n’est pas réaliste de devoir pour chaque fichier PHP noter son path exact, ça va rapidement être trop lourd.
Le second point est que ça ne sécurise même pas notre site. En effet, il suffit que l’attaquant nome son fichier test.php pour que ce nouveau fichier overwrite l’ancien. À partir du site ne serait, en effet, plus accessible, mais la faille oui.
La seconde solution travaille de concert avec la première et pallie ses failles. Il faut dans cette solution de modifier le fichier test.php en particulier le fichier de destination. Dans notre cas, la destination des fichiers upload était $uploaddir = '/var/www/html/ ce qui est la meme destination que notre fichier test.php que ça soit par soucis de sécurité ou même d’esthétique d’architecture, nous ne voulons pas qu’un fichier upload soit au même endroit qu’on fichier php d’origine. Pour régler ce problème, nous allons changer la destination en $uploaddir = '/var/www/html/fichier_drop/';
# pwd = /var/www/html
sudo mkdir fichier_drop
sudo chown www-data:www-data fichier_drop/
ce faisant les nouveaux fichiers chargé seront mis dans le dossier fichier_drop
De plus, et pour avoir une architecture propre, nous créons un dossier php_legit dans lequel, nous mettons test.php. Bien évidemment, nous modifions la configuration nginx pour qu’il ne lise que les fichiers PHP de php_legit/
Nous obtenons ainsi :
location ~* \.php$ {
try_files $uri $uri/ =404;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
root /var/www/html/php_legit;
}
Pour le niveau 3 nous avons essayé de chrooter tous les documents nginx, php, etc. Globalement tout ce qui contient notre site. Cependant, après de nombreuses tentatives, nous n’avons pas réussi à créer l’utilisateur www-data dans notre chroot. Nous avons fini par arrêter de nous acharner, car ce type de solution n’est pas non plus parfait. Par facilité l’utilisation de docker-nginx pourrait etre intéressante puisque cela fait globalement pareil à notre chroot. Toutefois, une fois de plus le risque est l’augmentation de la surface d’attaque, d’autant plus que docker est une porte d’entrée très répandue dans le milieu.