En sí mismo, el simple hecho de tener %32%35 descodificado a 25 en una URL no es un error ni un signo de vulnerabilidad. De hecho, es lo que RFC 3986, sección 2.3 dice que debería suceder ( énfasis mío):
2.3. Caracteres no reservados
Los caracteres que están permitidos en un URI pero que no tienen un propósito reservado se llaman no reservados. Estos incluyen letras mayúsculas y minúsculas, dígitos decimales, guiones, puntos, guiones bajos y tilde.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Los URI que difieren en la sustitución de un carácter no reservado por su octeto US-ASCII codificado en porcentaje correspondiente son equivalentes: identifican el mismo recurso. Sin embargo, las implementaciones de comparación de URI no siempre realizan la normalización antes de la comparación (consulte la Sección 6). Por coherencia, los octetos codificados en porcentaje en los rangos de ALFA (% 41-% 5A y% 61-% 7A), DÍGITO (% 30-% 39), guión (% 2D), período (% 2E), guión bajo (% 5F), o tilde (% 7E) no debe ser creado por los productores de URI y, cuando se encuentra en un URI, debe decodificarse a sus correspondientes caracteres no reservados por los normalizadores de URI.
De hecho, es muy posible que no sea tu aplicación la que decodifique esos caracteres, sino tu servidor web, que intenta normalizar las URL que recibe antes de pasarlas a tu aplicación.
Para saber si su aplicación (o servidor web) está decodificando demasiado , debe probarlo con caracteres que en realidad no deberían decodificarse de acuerdo con el estándar , y que podría tener un efecto real en el análisis de la URL o el HTML en el que está incrustado. Algunos de estos caracteres incluyen:
-
Los caracteres delimitadores de URL generales ( gen-delims en RFC 3986, sección 2.2), especialmente los caracteres ? ( %3F ) y # ( %23 ): nunca deben aparecer sin escape en la parte de la ruta de una URL.
-
Caracteres que no están permitidos en las URL en absoluto, como nuevas líneas ( %0A ), espacios ( %20 ), " ( %22 ), < ( %3C ), > ( %3E ), \ ( %5C ), ^ ( %5E ), ' ( %60 ), { ( %7B ), | ( %7C ) y } ( %7D ).
-
metacaracteres HTML, como & ( %26 ), ' ( %27 ), " ( %22 ), < ( %3C ) y > (% co_de) %): Si se decodifican de forma inapropiada (y no se reemplazan por las entidades de caracteres HTML correspondientes), se podría dañar el marcado HTML y potencialmente crear una vulnerabilidad de inyección / XSS de HTML.
Tenga en cuenta que varios de estos ( %3E , " y < ) se encuentran en la lista de caracteres de URL prohibidos arriba y, por lo tanto, siempre deben estar codificados en porcentaje; los otros ( > y & ) pueden, y en algunos casos deben, aparecer en las URL sin el porcentaje de codificación, pero en tales casos deben estar codificados (especialmente ' ) como la entidad de caracteres HTML correspondiente (por ejemplo, & para & ).
-
Un signo literal & , codificado como % , nunca debe decodificarse a su forma literal dentro de una URL; si es así, puede invalidar la URL o, peor aún, formar una secuencia de escape de porcentaje válida pero inesperada con los caracteres que la siguen. Si bien es poco probable que esto permita un ataque XSS directo, ciertamente es un error y podría abrir otras vulnerabilidades al permitir que una entrada maliciosa pase la validación.
En particular, la prueba en la que observó que %25 fue reemplazado por la entidad HTML %22 sugiere que a) allí hay alguna decodificación inapropiada (o una recodificación insuficiente) en curso, aún b) la URL, aunque estrictamente hablando no es válida, se está correctamente escapada de HTML, que debería evitar que corrompa el formato HTML de manera que permita un ataque XSS.