Le seguenti regole .htaccess possono impedire questo attacco?

Dovresti correggere il codice che causa il problema, piuttosto che buttarlo via e sperare che blocchi le cose malevole. Il tuo .htaccess blocca l'accesso a / proc, che è buono, ma non è l'unica cosa che vuoi proteggere. La lista nera come questa non ti porterà lontano, poiché ci sono dozzine di altre directory che vuoi proteggere e quali dipendono dal sistema operativo e dalla configurazione del server.

Parte dell'attacco a cui sei stato vittima coinvolge il path traversal, cioè l'irruzione della root web inviando un percorso relativo in un parametro stringa di query che in qualche modo viene lavorato in un nome file. Per correggere questa parte, controlla l'intera base di codice per le stringhe che vengono utilizzate come nomi di file (questo include include e require istruzioni) e disinfettano quelle. I casi peggiori sono quelli in cui il nome del file viene utilizzato per eseguire un file come codice PHP (intenzionalmente o meno), ma un file_get_contents innocente può essere sufficiente per creare un rischio per la sicurezza (ad esempio quando un utente malintenzionato può ingannarlo per servire un file contenente password del database).

Successivamente, controlla tutte le parti della tua base di codice che usano le stringhe come codice ( eval e amici). È meglio eliminarli completamente - non sono quasi mai necessari e il prezzo che si paga per la convenienza percepita non vale la pena.

Poi c'è XSS; vuoi assicurarti che tutto ciò che invii al client sia correttamente codificato come HTML. Qualsiasi stringa estratta dal database dovrebbe essere considerata come testo e inviarla senza convertirla prima in HTML è evidentemente errata e pericolosa. Controlla tutto il codice che produce output (che di solito è molto) e assicurati che tutte le stringhe dinamiche siano correttamente codificate ( htmlspecialchars() fa questo per te). È importante avere una chiara comprensione di quali stringhe sono il testo e quali sono HTML - mentre l'utilizzo di uno come l'altro funziona tecnicamente, è, ancora, sbagliato e pericoloso.

SQL Injection è un altro frutto a basso impatto per gli attaccanti. Il modo in cui stai cercando di proteggerti è popolare, ma molto inefficiente. Fallisce su più account: ci sono un sacco di trucchi che puoi usare per iniettare SQL senza usare le stringhe nella blacklist, e più blacklist, maggiore è la possibilità di falsi positivi. Ho visto persone bloccare completamente le virgolette singole come parte della prevenzione dell'iniezione SQL, con il risultato che era impossibile trovare clienti di nome O'Brien (di cui ce ne fossero diversi). Per risolvere correttamente SQL Injection, assicurarsi che tutte le query siano parametrizzate. Sfortunatamente, l'API mysql_XXXX () vecchia scuola non supporta questi, quindi le persone concorrono semplicemente felicemente le query, che, di nuovo, sono sbagliate e pericolose. Sto parlando di cose come queste: mysql_query("SELECT * FROM foo WHERE bar = '$baz'"); . Poiché PHP offre sia l'interfaccia mysqli che l'API PDO, dovresti davvero usarli e fornire tutti i valori dinamici come parametri alla tua query - la libreria MySQL sottostante gestirà quindi tutte le operazioni di escape e di protezione per te.

Anche molto importante: le impostazioni di PHP. Disattiva register_globals (l'impostazione più pericolosa che abbia mai visto), magic_quotes (non fa altro che suggerire un falso senso di sicurezza e una scusa per scrivere codice sciatto), controlla i consigli di php.net.

E: permessi dei file. Assicurati che il tuo server web abbia accesso in sola lettura agli script, accesso in scrittura solo a directory specifiche dove è assolutamente necessario e nessun accesso ai file di cui non ha bisogno.

Inoltre, inserisci un .htaccess con Deny From All in ogni directory da cui non vuoi servire. Nota che ciò non impedirà al server web di accedere a quei file, ma farà sì che apache ignori le richieste che si risolvono direttamente su qualsiasi cosa in una di queste directory - puoi ancora include da lì, o leggere i dati dai file al loro interno, semplicemente non possono essere richiesti dall'esterno.

E infine, una cosa più generale da fare: rivedere tutti i punti in cui i dati non attendibili entrano nel tuo sistema ($ _POST, $ _GET, $ _COOKIE, parti di $ _SERVER, e tutto ciò che proviene dal database non è affidabile in questo contesto) e segui il suo percorso. Vedi se in qualsiasi momento l'abuso può essere possibile.

Se hai il budget, dovresti anche prendere in considerazione un audit professionale: un hacker esperto sarà in grado di individuare rapidamente eventuali falle di sicurezza rimanenti e dirti come risolvere i tuoi problemi specifici.