☰

Htacess Helicon APE falso positivo 403 Fallo

tag-icon • tag-icon iis .htaccess mod-rewrite
Htacess Helicon APE falso positivo 403 Fallo

En lugar de usar web.configpara mis reglas de reescritura, he estado usandoHelicón APEpara emular la característica de Apache .htaccess.

Tengo un .htaccessarchivo universal grande que se aplica en todo el servidor como parte de una función para restringir el acceso al paso de comandos como unión, eliminación, etc.

Sin embargo, me encuentro con un problema en el que una línea del código crea un falso positivo y bloquea el acceso a una URL que de otro modo sería adecuada.

La URL que falla es:http://example.com/union-contracts

Usando el siguiente comando en web.config, todas las URL que faltan se envían a index.php.

   <httpErrors errorMode="Custom" existingResponse="Replace">
        <remove statusCode="404" subStatusCode="-1" />
        <error statusCode="404" path="/index.php" responseMode="ExecuteURL" />
    </httpErrors>

regla htaccess que devuelve 403

RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC]
RewriteRule . - [F,L]

En definitiva, me gustaría seguir bloqueando unión por ejemplo, solo necesito modificar la línea de falsos positivos. Tenga en cuenta que tampoco busco -contractsestar codificado en mi .htaccessregla.

Pude duplicar el problema en htaccess en XAMPP después de recordar cómo se genera la URL en primer lugar.

En el lado del visitante del sitio web, cuando se accede a una URL, el servidor genera un error 404. Filtro la URL solo hasta la última parte y comparo la base de datos con esa cadena para ver si coincide con una URL guardada. Si es así, no paso ese 404 al navegador, solo se pasa si la URL puede. No se puede encontrar.

Cuando IIS genera un error 404, la URL se convierte en:

index.php?404;http://example.com:80/union-contracts

Pero no se pasa al navegador en ese formato.

Respuesta1

He expresado mi preocupación en los comentarios de que debe estar sucediendo "algo más", pero de todos modos...

Es difícil escribir una excepción para una regla que no debería (léase: "no puede") activarse en primer lugar; es una completa conjetura. Después de todo, ¿por qué elexcepciónser honrado?

Esa regla ya debería evitar la solicitud dada por un par de "grandes" razones:

  1. La solicitud no incluye una cadena de consulta.
  2. La expresión regular en la condición (PatrónCond) no coincide con ninguna parte de la URL (incluso si estaba en la cadena de consulta).

Teniendo en cuenta el punto 2 anterior, la expresión regular ya contiene una excepción suficiente para no coincidir con la solicitud dada, entonces, ¿cómo podemos implementar "otra" excepción?

Podrías modificar elPatrónCondpara evitar casos en los que un guión ( -) sigue a la palabra "unión", utilizando unanticipación negativa. Por ejemplo:

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union(?!-)|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)

Entonces, lo anterior coincide Xunion, pero no Xunion-, con Xuna de las secuencias de caracteres de la primeraalternanciagrupo (es decir (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00)).

O, cuando un guión sigue a cualquiera de estas palabras clave:

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)(?!-)

(ACTUALIZAR:Las dos sugerencias siguientes probablemente no funcionen, ya que parece que las directivas sólo se procesandespuésIIS ya ha reescrito la URL. En ese momento la ruta URL es simplemente /index.php, no /union-contracts.)

O modifique RewriteRulepara que no coincida con el comienzo de la ruta URL /union-(aunque esto potencialmente proporciona una puerta trasera para el intento XSS que la regla está tratando de bloquear). Por ejemplo:

RewriteRule !^/?union- - [F]

(Al menos en Apache, la Lbandera no es necesaria cuando Fse usa, está implícita).

Alternativamente, puede crear otra regla en elarriba, antes de sus reglas existentes, eso crea una excepción cuando se solicita una URL que comienza /union-y no tiene una cadena de consulta (aunque eso parecería una contradicción, si hay que creer en la otra regla). Por ejemplo:

RewriteCond %{QUERY_STRING} ^$
RewriteRule ^/?union- - [L]

Sin embargo, esto potencialmente "romperá" la solicitud si tiene otras reglas más adelante en el archivo que necesitan reescribir la URL de alguna manera, ya que esto no ocurrirá.

Supongo que Helicon-APE/mod_rewrite funciona en untipo directoriocontexto (por ejemplo, .htaccesssintaxis de estilo en lugar deservidoroanfitrión virtualcontexto)? Aunque eso no debería afectar a las directivas anteriores, tal como sucede.

ACTUALIZAR:Cuando IIS genera un error 404, la URL se convierte en:

index.php?404;http://example.com:80/union-contracts

¡Ah, sí! esa URLvoluntadquedar atrapado por la condición original. Entonces, parece que las directivas mod_rewrite están procesadas.después¡El IIS "reescribe" en web.config! Esto hace que estas directivas de "seguridad" sean algo superfluas o incluso incorrectas, ya que sonsupuestoque se ejecutará en la solicitud inicial del cliente. Y....

Filtro la URL solo hasta la última parte y comparo la base de datos con esa cadena para ver si coincide con una URL guardada.

Dado que está analizando activamente la URL y filtrando solo la parte que necesita, estas comprobaciones de "seguridad" parecerían redundantes de todos modos, al menos para estas solicitudes "404". (De hecho, dependiendo de los archivos reales (es decir, solicitudes no 404) que podrían solicitarse directamente, ¿podría una cadena de consulta maliciosa de esta naturaleza representar de manera realista una amenaza a la seguridad para cualquier URL?)

Las dos sugerencias anteriores para modificar la expresión regular en elcondiciónpara excluir casos en los que un guión sigue a la palabra clave "union", ocualquierpalabra clave, todavía se aplicaría aquí y parecería resolver el problema inmediato.

También puede cancelar todas las comprobaciones cuando index.php?404;se encuentre una URL del formulario (es decir, después de que IIS la haya reescrito). (¿Supongo que todas sus directivas mod_rewrite son controles de "seguridad" similares?)

Por ejemplo, agregue lo siguiente alarribadel .htaccessguión,anteslas directivas existentes:

RewriteCond %{QUERY_STRING} ^404;
RewriteRule ^/?index\.php - [L]

/index.php?404;......Esto debería evitar cualquier procesamiento posterior cuando se encuentre una URL del formulario . (Ya que de todos modos está analizando la URL en su secuencia de comandos).

información relacionada