php - htaccess - mod_rewrite.c apache2
¿Por qué es un riesgo de seguridad permitir barras diagonales codificadas en un URI? (2)
Creo que está bien usar barras inclinadas en cualquier lugar de una URL si se justifica el escape. Por ejemplo, el ejemplo citado en la siguiente pregunta (relevante) es muy razonable:
En cuanto a por qué estaría deshabilitado por defecto ... esta entrada de blog de 2003 sugiere que es "proteger los scripts CGI cojos de ellos mismos":
http://ken.coar.org/burrow/Apache_2f_encoding_decoding_and_security
Ciertas prácticas descuidadas probablemente llevan a algunas personas a encontrarse en una base de código con una cadena que no están seguras de si deben o no escapar. Así que lo logran "solo para estar seguros". Pero esto puede ocurrir después de un punto que asumió que no había caracteres de ruta ... y se pasa a un contexto ejecutable que creía que había realizado todas las comprobaciones necesarias.
Por lo tanto, si está utilizando los métodos recomendados de la mayoría de los marcos web modernos, dudo que esto sea un problema importante y puede usar AllowEncodedSlashes sin mayor preocupación.
Tengo una situación en la que quiero barras diagonales codificadas en un URI ( %2F ), pero mis reglas de .htaccess se ignoran cuando hago la solicitud y me envío a una página 404. Rápidamente encontré la directiva de Apache, AllowEncodedSlashes , que planeo activar, pero aún no entiendo por qué es un riesgo de seguridad en primer lugar. ¿No podría alguien transformar manualmente las barras codificadas en barras reales, si estuvieran tratando de ser infames? (Aunque no puedo ver qué daño podrían hacer ...)
La aplicación que estoy probando está escrita en PHP, y la regla mod_rewrite que interactúa con ella parece:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^test/(.*)$ /test.php?_escaped_fragment_=$1 [NE,QSA,L]
Solo quiero asegurarme de que entiendo los riesgos antes de continuar.
Para aclarar: Apache no permite barras codificadas en la ruta , pero sí en la cadena de consulta. La cadena de consulta es igualmente susceptible a las vulnerabilidades enumeradas por Christian a continuación ("Ejecución remota de código, acceso a archivos locales y recorrido de directorios").
Entonces, ¿por qué ASF llegó tan lejos como para crear una directiva especial solo para permitir este comportamiento? No estoy tratando de ser difícil, realmente no lo entiendo. Creo que no hace falta decir que cualquier entrada del usuario (incluida la URI) debe verificarse antes de utilizarla en cualquier base de datos o función del sistema de archivos.
Honestamente, no veo ningún problema de seguridad con esto, pero debo admitir que no he trabajado mucho en este campo. Dicho esto, la regla todavía no es correcta.
Debería estar redirigiendo a un archivo de controlador (script php) que analiza $_SERVER[''REQUEST_URI''] lugar de pasarlo a través de $_GET . Esto se debe principalmente a evitar los problemas que normalmente se presentan con el contenido no codificado.
Por otro lado, es posible que esté ejecutando un firewall de aplicación web con una regla que prohíba pasar barras mediante URI. Esto se debe a que este comportamiento a menudo se asocia con la ejecución remota de código , el acceso a archivos locales y el recorrido de directorios . Esto, sin embargo, es una medida de precaución, una en la que realmente no debería confiar en primer lugar.
Un ejemplo de explotar PoC:
include ''languages/''.$_GET[''lang'']; // hacker may pass ../ to move around.