¿Este fragmento de código htaccess proporciona suficiente seguridad?

Question

¿Este fragmento de código htaccess proporciona suficiente seguridad?

#1 de Krzysztof Kotowicz (8 votos)

2

He descargado una parte de .htaccess para evitar el uso de base64_encode o <script> o _REQUEST dentro de la URL. ¿Es esto lo suficientemente seguro para ayudarme en la seguridad parcial, o es solo una pérdida de tiempo y recursos?

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]

apache access-control

pregunta ALH 29.12.2011 - 14:20

fuente

1 respuesta

Lea otras preguntas en las etiquetas apache access-control

¿Cuáles son algunas de las mejores prácticas para la seguridad de WiFi, a la luz de las vulnerabilidades descubiertas recientemente? intrusión SOHO enrutador

score 8 · Answer 1

Es seguridad parcial como mencionaste, pero este enfoque de lista negra no te llevará a ninguna parte. Por un lado, estos fragmentos supuestamente lo protegen de varios vectores de ataque:

base64_encode busca (lo más probable) PHP Ejecución remota de código carga útil
La regla script intenta proteger de XSS
los otros son raros y posiblemente relacionados con RCE o antiguas vulnerabilidades de PHP, donde podría sobrescribir variables globales.

Obfuscation

Todas las reglas que das son muy sencillas de omitir, incluso con ofuscación . Por ejemplo, la carga útil XSS no requiere <script> en absoluto. Por ejemplo, un atacante podría ejecutar Javascript enviando <img src=1 onerror=js_code_here> y muchas, muchas otras formas.

Las técnicas de ofuscación son muy avanzadas ahora y se usan a menudo para omitir los filtros de aplicación. Si está interesado en las técnicas de ofuscación, le recomiendo que lea " Ofuscación de aplicaciones web ": es un excelente libro que describe múltiples formas de lidiar con los filtros que describiste.

¿Qué debo hacer entonces?

Si desea protegerse de las entradas malintencionadas para su aplicación, la única forma es hacer ambas cosas positivas (es decir, no basadas en una lista negra) validación de entrada y salida de escape - ya debe saber cómo hacerlo en su pregunta anterior .

Cortafuegos de aplicaciones web

Si no tiene control sobre el código de la aplicación (por ejemplo, es un código heredado implementado en un servidor que necesita mantener) o desea tomar la ruta 'defensa en profundidad' piense en implementar Firewall de aplicaciones web por ejemplo basado en mod_security . Estos firewalls aún se basan en listas negras, por lo que no ofrecen un 100% de protección, pero estas listas negras son mucho más completas que la que usted cita. Por ejemplo, mire los problemas que enfrentó mod_security & Se solucionó cuando anunciaron un concurso de para evitar su protección de inyección SQL

Habiendo dicho eso, siempre es mejor corregir el código de la aplicación vulnerable que tratar de ocultar la vulnerabilidad detrás de una regla de firewall.