Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #21301 > unrolled thread

scrittura file su wp-content/uploads

Back to article view | Back to it.comp.www.php

Contents

  scrittura file su wp-content/uploads Roberto Tagliaferri <tagliaferri@bofhland.org> - 2016-12-19 09:22 +0100
    Re: scrittura file su wp-content/uploads "ciccio" <21669invalid@mynewsgate.net> - 2016-12-20 09:43 +0000
      Re: scrittura file su wp-content/uploads Roberto Tagliaferri <tagliaferri@bofhland.org> - 2016-12-20 10:48 +0100
        Re: scrittura file su wp-content/uploads Alessandro Pellizzari <shuriken@amiran.it> - 2016-12-20 11:05 +0000
          Re: scrittura file su wp-content/uploads Roberto Tagliaferri <tagliaferri@bofhland.org> - 2016-12-20 15:29 +0100
            Re: scrittura file su wp-content/uploads "ciccio" <21669invalid@mynewsgate.net> - 2016-12-21 10:29 +0000
              Re: scrittura file su wp-content/uploads Roberto Tagliaferri <tagliaferri@bofhland.org> - 2016-12-21 18:47 +0100
                Re: scrittura file su wp-content/uploads g4b0 <email_sul_mio_sito@che_leggi_in.firma> - 2016-12-22 09:13 +0100
                  Re: scrittura file su wp-content/uploads Enrico Maria Chellini <bitit@bitit.it> - 2016-12-31 10:05 +0100
                    Re: scrittura file su wp-content/uploads Alessandro Pellizzari <shuriken@amiran.it> - 2016-12-31 16:35 +0000
                      Re: scrittura file su wp-content/uploads Enrico Maria Chellini <bitit@bitit.it> - 2017-01-02 09:15 +0100
                        Re: scrittura file su wp-content/uploads "ciccio" <21669invalid@mynewsgate.net> - 2017-01-02 09:56 +0000
                        Re: scrittura file su wp-content/uploads Alessandro Pellizzari <shuriken@amiran.it> - 2017-01-02 10:00 +0000
                          Re: scrittura file su wp-content/uploads Enrico Maria Chellini <bitit@bitit.it> - 2017-01-02 14:05 +0100
        Re: scrittura file su wp-content/uploads Enrico Maria Chellini <bitit@bitit.it> - 2016-12-31 10:25 +0100

#21301 — scrittura file su wp-content/uploads

Hola, ho un cliente con wordpress tutto aggiornato (4.7), 2 amministratori  
con user non admin ma ogni tanto (spesso) vengono scritti dei file .php che 
poi vengono utilizzati per inviare phish o spam.
Non utilizzo wp quindi a parte un po' di manutenzione spicciola 
(aggiornamenti, backup ed installazione di qualche plugin di controllo, 
ithemes secutiry) non riesco ad arginare la cosa: come scrivono dentro la 
uploads?
I commenti sono disattivati, la registrazione pure.
Ho letto che è un attacco su scala molto vasta ( https://goo.gl/yiLHIl )
cosa potrei provare?


-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)tosnet.it
www.robyt.eu

[toc] | [next] | [standalone]

#21308

Roberto Tagliaferri <tagliaferri@bofhland.org> ha scritto:

> Hola, ho un cliente con wordpress tutto aggiornato (4.7), 2 amministratori  
> con user non admin ma ogni tanto (spesso) vengono scritti dei file .php che 
> poi vengono utilizzati per inviare phish o spam.
> Non utilizzo wp quindi a parte un po' di manutenzione spicciola 
> (aggiornamenti, backup ed installazione di qualche plugin di controllo, 
> ithemes secutiry) non riesco ad arginare la cosa: come scrivono dentro la 
> uploads?
> I commenti sono disattivati, la registrazione pure.
> Ho letto che è un attacco su scala molto vasta ( https://goo.gl/yiLHIl )
> cosa potrei provare?

il cliente ha i dati di accesso FTP? Quest'ultimo e gli
altri che hanno accesso a wordpress hanno un antivirus decente
e aggiornato, con scansione del loro pc fatta e 0 schifezze trovate?

[toc] | [prev] | [next] | [standalone]

#21310

ciccio wrote:

> Roberto Tagliaferri <tagliaferri@bofhland.org> ha scritto:
> 
>> Hola, ho un cliente con wordpress tutto aggiornato (4.7), 2
>> amministratori con user non admin ma ogni tanto (spesso) vengono scritti
>> dei file .php che poi vengono utilizzati per inviare phish o spam.
>> Non utilizzo wp quindi a parte un po' di manutenzione spicciola
>> (aggiornamenti, backup ed installazione di qualche plugin di controllo,
>> ithemes secutiry) non riesco ad arginare la cosa: come scrivono dentro la
>> uploads?
>> I commenti sono disattivati, la registrazione pure.
>> Ho letto che è un attacco su scala molto vasta ( https://goo.gl/yiLHIl )
>> cosa potrei provare?
> 
> il cliente ha i dati di accesso FTP? Quest'ultimo e gli
> altri che hanno accesso a wordpress hanno un antivirus decente
> e aggiornato, con scansione del loro pc fatta e 0 schifezze trovate?
Le schifezze sono tutte uploadate tramite http, niente ftp.
Non ho analizzato troppo la questione ma sono migliaia di accessi verso 
xmlrpc.php 
Ora ho tolto il permesso di scrittura alla uploads ed è tornato tutto a 
posto.

-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)tosnet.it
www.robyt.eu

[toc] | [prev] | [next] | [standalone]

#21311

On 20/12/2016 09:48, Roberto Tagliaferri wrote:

> Le schifezze sono tutte uploadate tramite http, niente ftp.
> Non ho analizzato troppo la questione ma sono migliaia di accessi verso
> xmlrpc.php

Quel file serve solo per fare amministrazione remota (tipo con client 
standalone invece che web), se ricordo bene.

Qualche anno fa qualcuno consigliava addirittura di cancellarlo, ma non 
so se nel frattempo la struttura di WP è cambiata tanto da renderlo 
necessario.

Visto che hai tolto i permessi di scrittura in upload, probabilmente 
puoi anche provare a rinominare xmlrpc.php e vedere se si rompe 
qualcosa, e nel caso ridare i permessi di scrittura ad upload 
(altrimenti non potranno più caricare immagini dal backend).

Bye.

[toc] | [prev] | [next] | [standalone]

#21313

Alessandro Pellizzari wrote:
> Quel file serve solo per fare amministrazione remota (tipo con client
> standalone invece che web), se ricordo bene.
> 
> Qualche anno fa qualcuno consigliava addirittura di cancellarlo, ma non
> so se nel frattempo la struttura di WP è cambiata tanto da renderlo
> necessario.
> 
> Visto che hai tolto i permessi di scrittura in upload, probabilmente
> puoi anche provare a rinominare xmlrpc.php e vedere se si rompe
> qualcosa, e nel caso ridare i permessi di scrittura ad upload
> (altrimenti non potranno più caricare immagini dal backend).
> 
grazie, faccio 2 prove. Però che par di palle wordpress. Capisco sia comodo 
ma mi sembra un po' colabrodo

> Bye.

-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)tosnet.it
www.robyt.eu

[toc] | [prev] | [next] | [standalone]

#21316

Roberto Tagliaferri <tagliaferri@bofhland.org> ha scritto:

> Alessandro Pellizzari wrote:
> > Quel file serve solo per fare amministrazione remota (tipo con client
> > standalone invece che web), se ricordo bene.
> > 
> > Qualche anno fa qualcuno consigliava addirittura di cancellarlo, ma non
> > so se nel frattempo la struttura di WP è cambiata tanto da renderlo
> > necessario.
> > 
> > Visto che hai tolto i permessi di scrittura in upload, probabilmente
> > puoi anche provare a rinominare xmlrpc.php e vedere se si rompe
> > qualcosa, e nel caso ridare i permessi di scrittura ad upload
> > (altrimenti non potranno più caricare immagini dal backend).
> > 
> grazie, faccio 2 prove. Però che par di palle wordpress. Capisco sia comodo 
> ma mi sembra un po' colabrodo

è il rovescio della medaglia: vero che wordpress è facile e comodo,
ma è anche target di attacchi e problemi vari. Per cui bisogna
stargli sempre dietro e spendere tempo in continui aggiornamenti
e controlli vari. Il problema è che i webmastella sbattono
wordpress dovunque vendendolo ad ignari clienti, e poi "dimenticano"
di seguirlo, con conseguenze spesso disastrose...

[toc] | [prev] | [next] | [standalone]

#21317

ciccio wrote:

> Roberto Tagliaferri <tagliaferri@bofhland.org> ha scritto:

> è il rovescio della medaglia: vero che wordpress è facile e comodo,
> ma è anche target di attacchi e problemi vari. Per cui bisogna
> stargli sempre dietro e spendere tempo in continui aggiornamenti
> e controlli vari. Il problema è che i webmastella sbattono
> wordpress dovunque vendendolo ad ignari clienti, e poi "dimenticano"
> di seguirlo, con conseguenze spesso disastrose...
straquoto. Io faccio tutto a manella e da una parte ci vuole più tempo (e 
costo), dall'altra ho sicuramente meno problemi

-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)tosnet.it
www.robyt.eu

[toc] | [prev] | [next] | [standalone]

#21318

On 21/12/2016 18:47, Roberto Tagliaferri wrote:
> straquoto. Io faccio tutto a manella e da una parte ci vuole più tempo (e 
> costo), dall'altra ho sicuramente meno problemi

Non sono daccordo al 100%. Tra Wordpress e fare tutto a mano esiste una
saggia via di mezzo, anzi ne esistono a tonnellate (Laravel, per dirne
una molto di moda ai giorni nostri).

-- 
g4b0, linux user n. 369000
http://brosulo.net

[toc] | [prev] | [next] | [standalone]

#21339

g4b0 wrote:

> 
> On 21/12/2016 18:47, Roberto Tagliaferri wrote:
>> straquoto. Io faccio tutto a manella e da una parte ci vuole più tempo (e
>> costo), dall'altra ho sicuramente meno problemi
> 
> Non sono daccordo al 100%. Tra Wordpress e fare tutto a mano esiste una
> saggia via di mezzo, anzi ne esistono a tonnellate (Laravel, per dirne
> una molto di moda ai giorni nostri).
> 
Bisogna stare attenti a non confondere i CMS con i framework.

adesso io non ho mai lavorato su framework, ma credo che il prodotto 
finale, 
debba essere residente in un server dove c'è il framework stesso per girare.
O sbaglio?

in questo caso devi avere un clouds, o un vps o un server, altrimenti dove 
lo fai girare  il sito , su un hosting da 50 euro? dove wordpress ci sta 
senza problemi.

sbaglio?

[toc] | [prev] | [next] | [standalone]

#21343

Il Sat, 31 Dec 2016 10:05:45 +0100, Enrico Maria Chellini ha scritto:

> adesso io non ho mai lavorato su framework, ma credo che il prodotto
> finale,
> debba essere residente in un server dove c'è il framework stesso per
> girare.
> O sbaglio?

No. Oggi praticamente tutti i framework si installano tramite composer, 
quindi finiscono dentro la cartella vendor/ nel tuo progetto. Basta fare 
l'upload di quella e hai il framework.

Certo che, per motivi di sicurezza, è sempre meglio avere la possibilità 
di far puntare il virtual-host in una cartella (di solito public/) del 
progetto, e non alla root del progetto stesso, e questo non tutti gli 
hosting lo permettono.

Bye.

[toc] | [prev] | [next] | [standalone]

#21344

Alessandro Pellizzari wrote:

> Il Sat, 31 Dec 2016 10:05:45 +0100, Enrico Maria Chellini ha scritto:
> 
>> adesso io non ho mai lavorato su framework, ma credo che il prodotto
>> finale,
>> debba essere residente in un server dove c'è il framework stesso per
>> girare.
>> O sbaglio?
> 
> No. Oggi praticamente tutti i framework si installano tramite composer,
> quindi finiscono dentro la cartella vendor/ nel tuo progetto. Basta fare
> l'upload di quella e hai il framework.

scusa ma in ogni caso saranno dentro installati  come applicazione appunto 
dentro la cartella vendor; in somma siamo sicuri che le risorse necessarie 
per  un framework corrispondano a quelle di  un hosting a basso costo?


> Certo che, per motivi di sicurezza, è sempre meglio avere la possibilità
> di far puntare il virtual-host in una cartella (di solito public/) del
> progetto, e non alla root del progetto stesso, e questo non tutti gli
> hosting lo permettono.

problema di sicurezza da non poco.


quindi io la vedo così:

se progetto a basso costo: no framework ma al limite cms

se progetto a costi da medio a infinito, dipende da:
# il volume del codice che devi scrivere
# livello sicurezza e aggiornamenti

se devo usare un framework è perchè ho da scrivere un grosso volume di 
codice, con parti che evito di scrivere e prendo da montare.
perchè per far prima mi voglio ""occupare solo dell'output"" 

vorrei però che per motivi di sicurezza il framework fosse continuamente 
aggiornato con varie patch meglio se allineate a aggiornamenti di sistema. 
li vorrei un sistemista che mi cura e mi armonizza tutta la sicurezza.

mio modesto parere

enrico

[toc] | [prev] | [next] | [standalone]

#21345

Enrico Maria Chellini <bitit@bitit.it> ha scritto:

> Alessandro Pellizzari wrote:
> 
> > Il Sat, 31 Dec 2016 10:05:45 +0100, Enrico Maria Chellini ha scritto:
> > 
> >> adesso io non ho mai lavorato su framework, ma credo che il prodotto
> >> finale,
> >> debba essere residente in un server dove c'Ú il framework stesso per
> >> girare.
> >> O sbaglio?
> > 
> > No. Oggi praticamente tutti i framework si installano tramite composer,
> > quindi finiscono dentro la cartella vendor/ nel tuo progetto. Basta fare
> > l'upload di quella e hai il framework.
> 
> scusa ma in ogni caso saranno dentro installati  come applicazione appunto 
> dentro la cartella vendor; in somma siamo sicuri che le risorse necessarie 
> per  un framework corrispondano a quelle di  un hosting a basso costo?
> 
> 
> > Certo che, per motivi di sicurezza, Ú sempre meglio avere la possibilità
> > di far puntare il virtual-host in una cartella (di solito public/) del
> > progetto, e non alla root del progetto stesso, e questo non tutti gli
> > hosting lo permettono.
> 
> problema di sicurezza da non poco.
> 
> 
> quindi io la vedo così:
> 
> se progetto a basso costo: no framework ma al limite cms
> 
> se progetto a costi da medio a infinito, dipende da:
> # il volume del codice che devi scrivere
> # livello sicurezza e aggiornamenti
> 
> se devo usare un framework Ú perchÚ ho da scrivere un grosso volume di 
> codice, con parti che evito di scrivere e prendo da montare.
> perchÚ per far prima mi voglio ""occupare solo dell'output"" 
> 
> vorrei però che per motivi di sicurezza il framework fosse continuamente 
> aggiornato con varie patch meglio se allineate a aggiornamenti di sistema. 
> li vorrei un sistemista che mi cura e mi armonizza tutta la sicurezza.

Allora se ti serve un sistemista, assumi un sistemista.
Semplice, lineare e logico.

;-D

> mio modesto parere

Altrettanto.

[toc] | [prev] | [next] | [standalone]

#21346

Il Mon, 02 Jan 2017 09:15:44 +0100, Enrico Maria Chellini ha scritto:

> Alessandro Pellizzari wrote:

>> No. Oggi praticamente tutti i framework si installano tramite composer,
>> quindi finiscono dentro la cartella vendor/ nel tuo progetto. Basta
>> fare l'upload di quella e hai il framework.
> 
> scusa ma in ogni caso saranno dentro installati  come applicazione
> appunto dentro la cartella vendor; in somma siamo sicuri che le risorse
> necessarie per  un framework corrispondano a quelle di  un hosting a
> basso costo?

Un framework di suo consuma ben poche risorse. Qualche centesimo di 
secondo in più ad ogni richiesta.

Alcuni framework occupano parecchio spazio disco (anche 20-30 MB), ma è 
comunque enormemente inferiore rispetto a quanto richiesto, per esempio, 
da un'installazione di Node.js + Express (200-300 MB)

Naturalmente poi dipende da come lo usi.

Ho visto progetti "tirare dentro" 1 GB di file tramite composer, perché 
ci avevano infilato anche le fixture per il database per la prima 
installazione del software, ma non è il caso normale.

Per mia esperienza, per esempio, Wordpress non si installa(va) 
sull'hosting base di register.it, perché superava il numero di query al 
minuto sul DB.

>> Certo che, per motivi di sicurezza, è sempre meglio avere la
>> possibilità di far puntare il virtual-host in una cartella (di solito
>> public/) del progetto, e non alla root del progetto stesso, e questo
>> non tutti gli hosting lo permettono.
> 
> problema di sicurezza da non poco.

Sarebbe una buona pratica di sicurezza per qualsiasi sito, in PHP come in 
qualsiasi altro linguaggio, con o senza framework, che permette, per 
esempio, di tenere il file di config con le password fuori dal 
virtualhost, in modo che sia comunque impossibile da raggiungere anche in 
caso di problemi, per esempio con la configurazione di PHP sul webserver.

Sempre prendendo Wordpress: le password di accesso al DB sono in un file 
nella root. Se per qualsiasi motivo (aggiornamento andato male, per 
esempio) PHP viene disabilitato, e tu accedi a www.miosito.it/
wp_config.php, puoi vedere le credenziali in chiaro.

Se punti il virtualhost dentro una cartella e lasci le credenziali nella 
root, non hai modo di accederci dal webserver.

> quindi io la vedo così:
> 
> se progetto a basso costo: no framework ma al limite cms
> ...
> se devo usare un framework è perchè ho da scrivere un grosso volume di
> codice, con parti che evito di scrivere e prendo da montare.
> perchè per far prima mi voglio ""occupare solo dell'output""

Con un CMS dipendi totalmente da quello che il CMS ti permette di fare. 
Più il CMS è automatizzato, meno cose puoi fare, anche con i plugin. 
Oppure puoi farle ma a costo di una complessità enorme.
 
> vorrei però che per motivi di sicurezza il framework fosse continuamente
> aggiornato con varie patch meglio se allineate a aggiornamenti di
> sistema.

Il framework te lo aggiorni tu nel tuo progetto tramite "composer 
update", lo testi in locale e, quando funziona, fai l'upload di tutto il 
sito (framework compreso).

E, siccome hai fatto tu tutto l'accesso ai dati, sicuramente avrai anche 
dei test e dei sistemi per l'upgradel del DB.

Aggiornare un CMS (o anche solo un plugin di un CMS) è una cosa diversa, 
e sei completamente nelle mani dio chi ha scritto il codice. Se ha 
modificato il DB senza prevedere uno script di aggiornamento dello 
schema, o se magari hai aspettato troppo ad aggiornare e gli script non 
supportano l'upgrade dalla tua versione, sei fregato.

La procedura corretta sarebbe fare un clone di tutto il server su un 
secondo server (o virtual machine), fare l'upgrade del CMS (o plugin) e, 
se tutto funziona, fare un backup del server (di nuovo) e poi aggiornare.

Un minimo di una giornata di lavoro per ogni upgrade.

> li vorrei un sistemista che mi cura e mi armonizza tutta la sicurezza.

Per esperienza personale, un sistemista nel 90% dei casi non sa niente 
della sicurezza delle applicazioni user-facing, soprattutto dei CMS.

Lui si occupa della sicurezza del S.O. e dei server (Apache, Nginx, al 
massimo PHP, ecc.), ma se gli chiedi di tenerti aggiornato Wordpress (o, 
peggio, Drupal :P) ti ride in faccia.

O almeno io lo farei (o ti chiederei TANTI soldi) se fossi ancora 
SysAdmin.

La figura del DevOps è nata anche per quel motivo: fondere sistemisti 
(Op) e sviluppatori (Dev) in modo che l'applicazione sia adattata ai 
server e viceversa.

Ma questo raramente funziona coi CMS, perché è difficile adattarli 
all'infrstruttura su cui girano, essendo molto orizzontali di loro.


Alla fine è una questione di cosa stai facendo, di quanto vuoi spenderci, 
di quanto tempo hai, di quali competenze hai e di quali risorse hai.

È impossibile generalizzare.

Bye.

[toc] | [prev] | [next] | [standalone]

#21347

> Alla fine è una questione di cosa stai facendo, di quanto vuoi spenderci,
> di quanto tempo hai, di quali competenze hai e di quali risorse hai.
> 
> È impossibile generalizzare.


mi sa che ero rimasto un po' indietro a phpzend , mi ha dato de buoni motivi 
per ridare un occhiata ai framework.

grazie
enrico 

[toc] | [prev] | [next] | [standalone]

#21340

>> 
>> il cliente ha i dati di accesso FTP? Quest'ultimo e gli
>> altri che hanno accesso a wordpress hanno un antivirus decente
>> e aggiornato, con scansione del loro pc fatta e 0 schifezze trovate?
> Le schifezze sono tutte uploadate tramite http, niente ftp.
> Non ho analizzato troppo la questione ma sono migliaia di accessi verso
> xmlrpc.php
> Ora ho tolto il permesso di scrittura alla uploads ed è tornato tutto a
> posto.
> 

Ho affrontato questo problema già su linux.sys

allora quello che faccio su i mie script, che non credo riuscirai a fare su 
wordpress è  cambiare i permessi alla cartella prima di fare l'upgrade del 
file e ricambiarli  una volta caricato il file .
il proprietario delle cartelle è apache.  
#in upload utente lettura e scrittura, gruppo lettura e scrittura
#finito l'upload utente lettura e scrittura, gruppo lettura

pero essendo apache il proprietario tramite un ignection possono comuque 
ricambiarti i permessi e ricaricarti i file, sempre tramite ignection .

wordpress genera le cartelle pertanto il proprietario delle cartelle è 
apache. 

se le carichi in ftp invece il proprietario è user ftp.

a quel punto, puoi fare fare a php un'azione in ftp, che cambia i permessi 
delle cartelle prima e dopo l'upload.
#in upload utente lettura e scrittura, gruppo lettura e scrittura
#finito l'upload utente lettura e scrittura, gruppo lettura

attenzione: devi caricare in un file ben protetto login e password ftp per 
farle utilizare a php per fare l'operazione. 

da apache, non essendo proprietario, non puoi ricambiare i permesis alle 
cartelle, quindi cartelle insolo lettura, tranne che non conosci password e 
login di ftp

ma con wordpress, non credo riesci a farlo

Comunque , pare anche sia un bag di una verisone di php, devo dire che una 
volta aggiornato le ultime verioni di php, non mi è mai ricapitato.

Se qualcuno conosce una best pratic , posti pure.

enrico 

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web