Transfert de fichiers avec Filezilla
Alonso_90
Messages postés
25
Date d'inscription
Statut
Membre
Dernière intervention
-
brupala Messages postés 112026 Date d'inscription Statut Membre Dernière intervention -
brupala Messages postés 112026 Date d'inscription Statut Membre Dernière intervention -
Bonsoir chers tous.
J'aimerais que quelqu'un ici puisse m'aider à résoudre un problème qui m'empêche d'avancer.
En effet, je veux me connecter au serveur apache de WampServer avec filezilla client pour pouvoir transférer des fichiers dans le serveur apache de WampServer tout en étant en local.
S'il y a quelqu'un pour m'aider ou pour me proposer une autre technique, je serais très ravi.
Merci.
J'aimerais que quelqu'un ici puisse m'aider à résoudre un problème qui m'empêche d'avancer.
En effet, je veux me connecter au serveur apache de WampServer avec filezilla client pour pouvoir transférer des fichiers dans le serveur apache de WampServer tout en étant en local.
S'il y a quelqu'un pour m'aider ou pour me proposer une autre technique, je serais très ravi.
Merci.
A voir également:
- Transfert de fichiers avec Filezilla
- Telecharger filezilla - Télécharger - Téléchargement & Transfert
- Filezilla server - Télécharger - Téléchargement & Transfert
- Explorateur de fichiers - Guide
- Renommer des fichiers en masse - Guide
- Fichiers epub - Guide
2 réponses
Bonjour,
En local il suffit de copier les fichiers avec l'explorateur de Windows.
Car un serveur Wamp (W=indows, A=pache,M=ysql, P=hp)n'inclut pas un serveur ftp.
Cdlt
En local il suffit de copier les fichiers avec l'explorateur de Windows.
Car un serveur Wamp (W=indows, A=pache,M=ysql, P=hp)n'inclut pas un serveur ftp.
Cdlt
Cette technique ne pourra pas m'aider car mon exercice consiste à créer et modifier les droits d'un fichier dans un serveur sous Linux avec un script PHP . Mais comme je ne dispose pas de serveur sous Linux, je voulais le faire en local avec un logiciel.
Cdlt.
Cdlt.
a partir du moment où on peut executer du shell depuis une page web : https://www.linuxtricks.fr/wiki/php-lancer-des-processus-shell-dans-une-page-php
Salut !
Pour modifier le chmod, il n'y a même pas besoin de l'accès shell, PHP inclus une fonction permettant cela :
https://www.php.net/manual/fr/function.chmod.php
En fait, ce n'est pas plus surprenant que ça, PHP peut interagir avec les fichiers, comme toute autre application, indépendamment de son langage. PHP permet même de créer des sockets TCP/UDP :)
Un site/script PHP est en fait une application comme une autre, elle peut tout faire dans la limite des privilèges de l'utilisateur qui l'exécute. Ainsi, le script PHP peut modifier le chmod d'un fichier uniquement si l'utilisateur qui exécute le script PHP a les permissions pour cela. La solution consiste donc à faire en sorte que le script PHP soit exécuté avec les privilèges de son propriétaire, et s'assurer que chaque utilisateur est "bloqué" dans son /home, sans pouvoir traverser l'arborescence pour entrer chez quelqu'un d'autre. C'est assez facile à faire avec les "pools" PHP.
Dans le cas où un shell_exec est placé volontairement par l'utilisateur, il sera limité à ses propres fichiers.
Les autres utilisateurs ne risquent rien.
Dans le cas d'un site PHP qui contient une vulnérabilité (comme exemple, prenons... WordPress), le hacker peut trouver un moyen afin de transférer un "backdoor" (script PHP rédigé par ses soins) qui lui permet alors d'exécuter des commandes via shell_exec, scanner les fichiers, etc.
L'intrusion se fait par le biais d'un script PHP légitime (mais vulnérable), ce dernier étant exécuté par un utilisateur donné, la portée de l'intrusion est donc restreinte à cet utilisateur. Le backdoor est ensuite exécuté sous ce même utilisateur, sa portée sera donc également restreinte.
Le danger de ces fonctions concerne donc uniquement l'utilisateur imprudent, il sera le seul à payer le prix de son imprudence. Si tu es sysadmin pour un hébergeur mutualisé, tu ne peux pas contrôler ce que tes clients mettent sur le serveur, le client est le seul responsable des actions découlant de ses propres fichiers PHP, volontaires ou à son insu. Mais ce client n'hésitera pas à te jeter la pierre, car son site fonctionnait bien hier soir, c'est forcément la faute à l'hébergeur si ça marche plus aujourd'hui alors qu'il n'a rien touché ! (parfois, ne rien faire, c'est la cause du problème...).
Les fonctions "dangereuses" (shell_exec...) sont souvent désactivées pour limiter la casse car elles ne sont pas désirées dans le cadre d'un usage "normal". Il est aussi possible de créer un utilisateur système sans shell.
Bref, tout ça pour te dire qu'il ne faut pas avoir peur ;)
Pour modifier le chmod, il n'y a même pas besoin de l'accès shell, PHP inclus une fonction permettant cela :
https://www.php.net/manual/fr/function.chmod.php
En fait, ce n'est pas plus surprenant que ça, PHP peut interagir avec les fichiers, comme toute autre application, indépendamment de son langage. PHP permet même de créer des sockets TCP/UDP :)
Un site/script PHP est en fait une application comme une autre, elle peut tout faire dans la limite des privilèges de l'utilisateur qui l'exécute. Ainsi, le script PHP peut modifier le chmod d'un fichier uniquement si l'utilisateur qui exécute le script PHP a les permissions pour cela. La solution consiste donc à faire en sorte que le script PHP soit exécuté avec les privilèges de son propriétaire, et s'assurer que chaque utilisateur est "bloqué" dans son /home, sans pouvoir traverser l'arborescence pour entrer chez quelqu'un d'autre. C'est assez facile à faire avec les "pools" PHP.
Dans le cas où un shell_exec est placé volontairement par l'utilisateur, il sera limité à ses propres fichiers.
Les autres utilisateurs ne risquent rien.
Dans le cas d'un site PHP qui contient une vulnérabilité (comme exemple, prenons... WordPress), le hacker peut trouver un moyen afin de transférer un "backdoor" (script PHP rédigé par ses soins) qui lui permet alors d'exécuter des commandes via shell_exec, scanner les fichiers, etc.
L'intrusion se fait par le biais d'un script PHP légitime (mais vulnérable), ce dernier étant exécuté par un utilisateur donné, la portée de l'intrusion est donc restreinte à cet utilisateur. Le backdoor est ensuite exécuté sous ce même utilisateur, sa portée sera donc également restreinte.
Le danger de ces fonctions concerne donc uniquement l'utilisateur imprudent, il sera le seul à payer le prix de son imprudence. Si tu es sysadmin pour un hébergeur mutualisé, tu ne peux pas contrôler ce que tes clients mettent sur le serveur, le client est le seul responsable des actions découlant de ses propres fichiers PHP, volontaires ou à son insu. Mais ce client n'hésitera pas à te jeter la pierre, car son site fonctionnait bien hier soir, c'est forcément la faute à l'hébergeur si ça marche plus aujourd'hui alors qu'il n'a rien touché ! (parfois, ne rien faire, c'est la cause du problème...).
Les fonctions "dangereuses" (shell_exec...) sont souvent désactivées pour limiter la casse car elles ne sont pas désirées dans le cadre d'un usage "normal". Il est aussi possible de créer un utilisateur système sans shell.
Bref, tout ça pour te dire qu'il ne faut pas avoir peur ;)
ou une clé USB en local :-)
En effet, c'est le W qui coince ;-)
sinon, en sftp, ça roule sur un serveur Linux.