La vulnerabilità di PHP può arrestare milioni di server - max_input_vars!

Interessante articolo (CVE-2011-4885 per coloro a cui piacciono i riferimenti), grazie per l'heads-up - leggerò su questo punto ma alcuni punti risaltano già.

• solo per chiarire - il problema è all'interno del livello logico - non del server web stesso.
• la tua domanda se è possibile utilizzare ini_set è basata sul fatto che il motore PHP sottostante sia stato aggiornato - quando hai già affermato che è improbabile che ciò accada per molti provider di hosting. OTOH qualsiasi provider di hosting che aggiorna il proprio PHP probabilmente distribuirà le relative modifiche ini o fornirà un meccanismo per farlo.
• mentre la maggior parte delle società di hosting eviterà attivamente di imporre un aggiornamento importante ai propri utenti, dovrebbe implementare patch del fornitore per le distribuzioni esistenti - e questa patch è già stata sostituita a tutte le versioni di produzione di 5.3 e 5.2 , Credo che Redhat abbia ora rilasciato patch per l'attuale RHEL
• ci sono almeno 4 diversi posti in cui le impostazioni di ini possono essere modificate in PHP - nel file php.ini, nella configurazione del webserver (quando PHP è implementato come modulo), nei file .htaccess (di nuovo se il modulo) e in il codice PHP stesso - ma non tutte le impostazioni possono essere modificate in tutte le posizioni: finora la nuova configurazione var non è nel manuale per dire dove può essere modificata.
• per sfruttare questa vulnerabilità, sarebbe necessario inviare una quantità significativa di variabili nella richiesta - Apache (e probabilmente la maggior parte degli altri server Web) consente un certo controllo sulla dimensione totale della richiesta, del corpo della richiesta e dei dati POST - anche il tempo di esecuzione - l'uso efficace e selettivo di queste opzioni di configurazione sia nella configurazione httpd che in specifici alberi di directory usando .htaccess potrebbe essere usato per mitigare qualsiasi potenziale attacco - tenendo presente qualsiasi necessità di supportare (es.) upload di file.
• la natura di un DOS basato su questa vulnerabilità è, in effetti, molto simile al problema con le richieste di intervallo su Apache (CVE-2011-3192) - sebbene una grave vulnerabilità, non ho visto molte prove di tale difetto ampiamente sfruttato.

I know that if someone attacks to the server the whole site will be down, but by setting the max_input_vars at least my site will be safe if somebody attack my site

Non capisco - sicuramente un attacco basato su questa vulnerabilità non produrrà perdite o modifiche di dati / codice (AFAICS).

I know that if someone attacks to the server the whole site will be down, but by setting the max_input_vars at least my site will be safe if somebody attack my site. Is this correct?

Direi che, a meno che max_input_vars sia inferiore al valore predefinito (1000), possa ancora accadere con più richieste, vorresti impostarlo al numero massimo di vars che il tuo software utilizza, ma che dolore per scoprire (o impossibile se hai campi dinamici).

IMO: cerotto su un cancro, hanno bisogno di cambiare l'algoritmo hash in modo casuale.