Oui on peut sans doute être plus safe et interdir à www-data l'écriture dans des répertoires sensibles, on se casse le système interne de mise à jour mais c'est pas grave car on peut faire les mises à jour sur un local isolé puis les pousser sur le prod' niveau système sans utiliser les fonctions du backoffice.
Ce qui laisse, généralement, le répertoire du cache dans lequel on a besoin d'écrire du PHP.
Par contre l'édition de pages ça se fait en générale dans la base et c'est du HTML, ça ne passe pas par la corruption ou l'upload d'un fichier PHP. Et là ça peut se faire en exploitant une faille dans l'ACL du CMS.
J'ai vu des failles, dans des templates de CMS, qui permettaient de voir le contenu de n'importe quel fichier du système, y compris en dehors de l'arbo du site ciblé...y compris dans /etc par exemple, et ça sans déposer de PHP.
Si il y a, comme dans certains CMS (Joomla, Magento...Wordpress je sais pas), un password de user de la database en clair dans un fichier, le récupérer suffit à aller modifier tout ce qu'on veut dans la base.
En tous cas ils se sont fait troué parce que leur truc n'était pas patché à priori.
Donc là il y a eu faute c'est clair.
Mais, des failles de sécu inconnues et pour lesquelles il n'y a pas de patch à un moment donné (0day) ça existe aussi.
Mieux vaut en tous cas sortir l'artillerie lourde pour couvrir au maximum tous les classiques modes d'attaque au niveau du site et du système : Nginx + Naxsi WAF (ou une extension dédiée au CMS) pour empêcher l'injection, et en mode parano ajouter à ça le monitoring de l'arbo du site.
Ceinture + bretelles + parachute et gilet de sauvetage...le seul truc impossible à éliminer c'est la connerie humaine et en tapant ces lignes, j'ai conscience d'en faire aussi des conneries, d'être parfois feignant, etc...
[^] # Re: Précisions
Posté par Brunus (Mastodon) . En réponse au journal Attention si vous avez téléchargé l'ISO Linux Mint 17.3 sur leur site depuis le 20-02 !. Évalué à 2.
Oui on peut sans doute être plus safe et interdir à www-data l'écriture dans des répertoires sensibles, on se casse le système interne de mise à jour mais c'est pas grave car on peut faire les mises à jour sur un local isolé puis les pousser sur le prod' niveau système sans utiliser les fonctions du backoffice.
Ce qui laisse, généralement, le répertoire du cache dans lequel on a besoin d'écrire du PHP.
Par contre l'édition de pages ça se fait en générale dans la base et c'est du HTML, ça ne passe pas par la corruption ou l'upload d'un fichier PHP. Et là ça peut se faire en exploitant une faille dans l'ACL du CMS.
J'ai vu des failles, dans des templates de CMS, qui permettaient de voir le contenu de n'importe quel fichier du système, y compris en dehors de l'arbo du site ciblé...y compris dans /etc par exemple, et ça sans déposer de PHP.
Si il y a, comme dans certains CMS (Joomla, Magento...Wordpress je sais pas), un password de user de la database en clair dans un fichier, le récupérer suffit à aller modifier tout ce qu'on veut dans la base.
En tous cas ils se sont fait troué parce que leur truc n'était pas patché à priori.
Donc là il y a eu faute c'est clair.
Mais, des failles de sécu inconnues et pour lesquelles il n'y a pas de patch à un moment donné (0day) ça existe aussi.
Mieux vaut en tous cas sortir l'artillerie lourde pour couvrir au maximum tous les classiques modes d'attaque au niveau du site et du système : Nginx + Naxsi WAF (ou une extension dédiée au CMS) pour empêcher l'injection, et en mode parano ajouter à ça le monitoring de l'arbo du site.
Ceinture + bretelles + parachute et gilet de sauvetage...le seul truc impossible à éliminer c'est la connerie humaine et en tapant ces lignes, j'ai conscience d'en faire aussi des conneries, d'être parfois feignant, etc...