Mettendolo nella cartella administrator a me non va
e metterlo nella cartella installation non serve a nulla perchè alla fine dell'installazione quella cartella va cancellata.
Vabbè..

@Sinistar said:

Mettendolo nella cartella administrator a me non va
e metterlo nella cartella installation non serve a nulla perchè alla fine dell'installazione quella cartella va cancellata.
Vabbè..
basta metterlo sono in administrator

Scusate, di direttive del genere non sono molto pratico, ma per quello che so io un file messo nella cartella administrator ha effetto solo in quella cartella e nelle cartelle sottostanti, non in quelle superiori. Quindi, secondo me, l'unico effetto che avete e che entrando nel pannello di amministrazione il register globals è a posto, ma per il resto del sito no.
Forse mi sbaglio però

Quoto bsaett, dovrebbere esse proprio cosi...non vedete l'avviso, ma il php.ini non penso che dia rilevanza ad un'istruzione esterna, rispetto alla sua direttiva principale.

Era quello che volevo dire io...

Per quanto riguarda il PHP.ini deve essere il provider a concedere l'accesso. Dovete chiedere all'assistenza. Inoltre ogni modifica al PHP.ini necessita di riavvio del server, cosa che non può fare l'utente.

In genere è possibile sovrascrivere le direttive tramite .htaccess che non necessita di riavvio del server, visto che è letto ad ogni richiesta al server.
Provate a chiedere all'assitenza i corretti parametri per l'htaccess.

@bsaett said:

Per quanto riguarda il PHP.ini deve essere il provider a concedere l'accesso. Dovete chiedere all'assistenza. Inoltre ogni modifica al PHP.ini necessita di riavvio del server, cosa che non può fare l'utente.

In genere è possibile sovrascrivere le direttive tramite .htaccess che non necessita di riavvio del server, visto che è letto ad ogni richiesta al server.
Provate a chiedere all'assitenza i corretti parametri per l'htaccess.
ok..chiederò ad aruba. Scusa, cosa dovrei chiedere esattamente? Informazioni su come impostare il file htacess per joomla?
thanks

Potresti chiedere direttamente come impostare il REGISTER GLOBALS ad OFF.

Gentile cliente,

Le comunico che non è possibile apportare modifiche al paramentro da Lei indicato in quanto non sono consentite impostazioni personalizzate in ambiente condiviso.

In caso La invito a consultare la nostra guida in merito ai server virtuali presso:
http://serverdedicati.aruba.it/virtualserver.aspx

Il problema sembra risolto, quella direttiva non si può cambiare.
Joomla rimarrà insicuro purtroppo.

@bsaett said:

Il problema sembra risolto, quella direttiva non si può cambiare.
Joomla rimarrà insicuro purtroppo.
ciao,
allora come si fa a renderlo più sicuro possibile?

salve,
la scarsa sicurezza non è cosa da poco. Ancora il sito ha pochi articoli. Mi conviene cambiare CMS? almeno che non ci sia un modo per rendere joomla abbastanza sicuro

Non ti conviene cambiare CMS, Joomla è uno dei più sicuri, ma per mantenerlo sicuro devi risolvere i warning del pannello di controllo, il register globals e l'RG emulation, che devono essere settati a OFF.

@bsaett said:

Non ti conviene cambiare CMS, Joomla è uno dei più sicuri, ma per mantenerlo sicuro devi risolvere i warning del pannello di controllo, il register globals e l'RG emulation, che devono essere settati a OFF.
RG emulation l'ho sistemato
register globals rimane un punto interrogativo

provo questo

io avevo il file htaccess, poi il gentilissimo GloboGsm mi ha mandato un file .htaccess e l'ho messo via ftp. Ho comunque lasciato il preesistente htacess pensando che desse fastidio

adesso dovrei inserire
php_flag register_globals off
alla fine del file .htaccess mandatomi da GloboGsm
possibile soluzione?

Mi pareva di aver capito che il tuo provider ti aveva detto che il register globals non può essere modificato !

Comunque .htaccess deve essere così:

php_value register_globals 0

@version $Id: htaccess.txt 1570 2005-12-29 05:53:33Z eddieajau $

@package Joomla

@copyright Copyright (C) 2005 Open Source Matters. All rights reserved.

@license http://www.gnu.org/copyleft/gpl.html GNU/GPL

Joomla! is Free Software

mod_rewrite in use

RewriteEngine On

NOTE!

When using multiple Joomla sites or other web applications in sub-folders,

you must explicitly turn the RewriteEngine off or use the settings

recommended for the application

Uncomment following line if your webserver's URL

is not directly related to physical file paths.

Update YourJoomlaDirectory (just / for root)

RewriteBase /

Rules

RewriteCond %{REQUEST_FILENAME} !.(jpg|jpeg|gif|png|css|js|pl|txt)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php
########## Begin - Rewrite rules to block out some common exploits

If you experience problems on your site block out the operations listed below

This attempts to block the most common type of exploit attempts to Joomla!

Block out any script trying to set a mosConfig value through the URL

RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D)

Block out any script trying to base64_encode crap to send via URL

RewriteCond %{QUERY_STRING} base64_encode.(.)

Block out any script that includes a <script> tag in URL

RewriteCond %{QUERY_STRING} (<|%3C).script.(>|%3E) [NC,OR]

Block out any script trying to set a PHP GLOBALS variable via URL

RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2})

Block out any script trying to modify a _REQUEST variable via URL

RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})

Send all blocked request to homepage with 403 Forbidden error!

RewriteRule ^(.*)$ index.php [F,L]

########## End - Rewrite rules to block out some common exploits

La prima riga sovrascrive la direttiva register globals. Questo è però possibile solo se il provider lo consente.
La riga può differire da provider a provider. Ad esempio:

php_value register_globals off

php_value register_globals = off

php_value register_globals = 0

L'alternativa che indichi tu col link non la avevo mai vista, comunque puoi anche provare quella. Ma ripeto, è l'assistenza del tuo provider che ti deve indicare la corretta sintassi della direttiva e se sia possibile attivarla o meno.

Allora crea un file htaccess.txt con i comandi sopra indicati, lo carichi via FTP e poi lo rinomini in .htaccess.
All'inizio prova solo la prima riga perchè anche le successive potrebbero differire.

@bsaett said:

Mi pareva di aver capito che il tuo provider ti aveva detto che il register globals non può essere modificato !

è così ma voglio vedere se trovo una soluzione ma se dici che se il provider dice che non si può e non c'è via d'uscita allora ci rinuncio
il fatto è che non mi piace avere un sito poco sicuro

Infatti, non è il massimo. Ogni tanto sento di siti hackerati. Joomla è difficile da attaccare, con quella direttiva a ON diventa più facile.

Però mi pare strano. Tu hai Aruba linux o sbaglio ? Credevo che lì fosse abilitata quella modifica. O forse ci sono piani di hosting diversi ?

@bsaett said:

Infatti, non è il massimo. Ogni tanto sento di siti hackerati. Joomla è difficile da attaccare, con quella direttiva a ON diventa più facile.

Però mi pare strano. Tu hai Aruba linux o sbaglio ? Credevo che lì fosse abilitata quella modifica. O forse ci sono piani di hosting diversi ?
si, aruba linux..mannaggia a sta cosa
nel forum di joomla.org ho letto qualche post di qualcuno che ha subito attacchi

Bè anche Joomla.org è stato hackerato, ma non per colpa del core di Joomla, ma proprio per l' htaccess non attivo.

Annuncio su Joomla.org
http://forum.joomla.org/index.php/topic,203290.0.html

Riassumendo:

• Non si tratta di una vulnerabilità del core di Joomla, ma di un componente MAI distribuito, anche se la vulnerabilità è presente in altri componenti.
• Un sistema per coprire quella vulnerabilità è di porre a off il register_globals emulation.

Ricordiamoci che l'impostazione a off lo rende più sicuro ma non Sicuro.
Nel senso che una volta settato a off non lo rende inattaccabile. E' meglio porre il resister_globals a off ma questo non vuol dire che non dobbiamo preoccuparci.
Anche a me Aruba ha risposto allo stesso modo.:(