Questo snippet di htaccess fornisce una sicurezza sufficiente?

Question

Questo snippet di htaccess fornisce una sicurezza sufficiente?

#1 da (8 voti)

2

Ho scaricato una parte di .htaccess per impedire di utilizzare base64_encode o <script> o _REQUEST nell'URL. È abbastanza sicuro da aiutarmi per una parziale sicurezza, o è solo uno spreco di tempo e risorse?

RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]  
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]  
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]  
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})  
RewriteRule .* index.php [F]

access-control apache

posta ALH 29.12.2011 - 14:20

fonte

1 risposta

Leggi altre domande sui tag access-control apache

intrusione di router SOHO Quali sono le migliori pratiche per la sicurezza WiFi, alla luce delle vulnerabilità scoperte di recente?

score 8 · Answer 1

È sicurezza parziale come hai detto, ma questo approccio alla lista nera non ti porterà da nessuna parte. Per esempio, questi snippet presumibilmente ti proteggono dai vari vettori di attacco:

base64_encode cerca (molto probabilmente) PHP Esecuzione di codice in remoto carico utile
La regola script prova a proteggere da XSS
gli altri sono strani e probabilmente correlati a vulnerabilità RCE o vecchie di PHP in cui è possibile sovrascrivere le variabili globali.

offuscamento

Tutte le regole che date sono molto semplici da aggirare, anche con offuscamento di base. Ad esempio, il payload XSS non richiede affatto <script> . Ad esempio, l'autore dell'attacco potrebbe eseguire Javascript inviando <img src=1 onerror=js_code_here> e molti, molti altri modi.

Le tecniche di offuscamento sono molto avanzate ora e sono spesso utilizzate per aggirare i filtri delle applicazioni. Se sei interessato alle tecniche di offuscamento, ti consiglio di leggere " Obfuscation dell'applicazione Web " - è un libro eccellente che descrive più modi di trattare i filtri che hai descritto.

Che cosa dovrei fare allora?

Se vuoi proteggere da input dannosi alla tua applicazione, l'unico modo è di fare sia positivo (cioè non basato su una lista nera) validazione dell'input e output di escape - dovresti già sapere come farlo dalla domanda precedente .

Firewall di applicazioni Web

Se non hai il controllo sul codice dell'applicazione (ad es. è un codice legacy distribuito su un server che devi mantenere) o desideri seguire la rotta di "difesa in profondità", pensa di implementare Web Application Firewall es. basato su mod_security . Questi firewall sono ancora basati su una blacklist, quindi non offriranno una protezione al 100%, ma queste liste nere sono molto più complete di quelle che citi. Ad esempio, guarda i problemi di mod_security affrontati & corretto quando hanno annunciato un concorso per bypassare la loro protezione dell'iniezione SQL

Detto questo, è sempre meglio correggere il codice delle applicazioni vulnerabili piuttosto che cercare di nascondere la vulnerabilità dietro una regola del firewall.