Vai al contenuto

Sicurezza delle proprie Board

Recommended Posts


Controllo molto il sito della Invision, specialmente per il marketplace, ma ogni tanto, con i problemi che si presentano, anche per ricevere supporto.

Ho visto nella loro sezione news, questo topic, che riporta:

There has been much confusion over the recent exploit reported to us and subsequently patched. I would like to personally apologize for any confusion and inconvenience caused. We have conducted a review and made appropriate changes to our policies to ensure a smoother release and notification schedule for any future incidents.

With that said, it is very important to note that while an IP.Board vulnerability did exist, its impact would have been minimal, if not non-existent on servers that have their PHP installations properly secured. I would like to touch on a couple of basics to minimize the effects of future vulnerabilities not only in IP.Board, but any other PHP application you may be using on your website.


It's very important that you (if you manage your own web hosting server) or your web host enable open_basedir. In a shared hosting environment without open_basedir, an attacker has the ability to exploit a vulnerability, perhaps on another customer's account, then use that vulnerability to scan for other customers on the server. From there, they could gain access to config files containing database details, write malicious files to world-writeable directories and a host of other ill-willed activities. Enabling open_basedir "locks" all internal PHP functions such as readfile() to the specified path, which is generally a temporary directory and your home directory.


While open_basedir is a very positive step in securing your PHP scripts, there are unfortunately instances in which it can be bypassed and this is how the recent IP.Board vulnerability gained ground so quickly. For example, the exec(), system() and passthru() functions allow a command to be issued directly to the operating system to view key system files, navigate through other users' web root directories, install 'remote shell' scripts into other users' directories, etc. without any regard to other restrictions such as open_basedir. For this reason, disable_functions should be set to disable system level functions. For example, this is a recommended disable_functions:

disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system

You or your host may need to tweak to suit, but at a minimum, execution commands should be disabled.

Following the above, you will not necessarily create a fool-proof environment, but you will have additional reassurances that you or your host have taken appropriate measures to better secure your PHP applications.

For those that run a cPanel/WHM server you may enable open_basedir by visiting WHM and clicking the "PHP open_basedir Tweak" link under "Security Center" then clicking enable.

You may modify the disable_functions line by visiting WHM and clicking "PHP Configuration Editor" under "Service Configuration" then clicking "advanced" and searching for "disable_functions"

If you are unsure or do not have the necessary permissions to carry out these tasks, please do contact your host. You are free to link them to this blog entry as well.

I hope this helps better explain the recent security concern and what you can do to help protect yourself and your users in the future. As always, please feel free to contact us with any questions or concerns you might have. Thank you for your cooperation and understanding.

View the full article

Con ovviamente relativo articolo:

Qualcuno più esperto, può dirci come dobbiamo comportarci e se dobbiamo effettuare delle modifiche sostanziali?

Io ad esempio, ho ancora problemi di spammer...

Condividi questo messaggio

Link di questo messaggio
Condividi su altri siti

Diciamo che queste misure preventive, sono misure che gli hoster prendono già, quindi open_basedir attivo e alcune funzioni disabilitate. Noi abbiamo aggiunto qualche funzione al disable_function ma per il resto avevamo già tutto settato come da guida, purtroppo il problema principale è stato che l'exploit è stato corretto troppo tardi (da parte di IPB). Quello che consiglio è, molto banalmente, tenere sempre aggiornata la board per evitare probabili bug nelle versioni precedenti. Per quanto riguarda lato server quello che c'è da fare dipende... Se avete uno shared hosting passate subito questa guida al vostro hoster oppure se avete un php.ini personalizzabile eseguite voi stessi queste modifiche e assicuratevi che il vostro hoster abbia l'open_basedir abilitato. Se avete un dedicato o una vps seguite comunque questa guida e se non siete sicuri affidatevi a un sistemista che vi metta in sicurezza il vostro server. Per quanto riguarda la board nessuna modifica sostanziale visto che alla fine sembra che con questa security patch il bug è scomparso. In qualsiasi caso vi consiglio di farli un controllo a campione delle index e capire se avete qualche codice malevolo.

Fate anche una scansione completa del sito con

Condividi questo messaggio

Link di questo messaggio
Condividi su altri siti