Es una barra inclinada ("/") equivalente a una barra diagonal codificada ("% 2F") en la parte de ruta de una URL HTTP

Question

Tengo un sitio que trata "/" y "% 2F" en la parte de ruta (no la cadena de consulta) de una URL de manera diferente. ¿Es esto algo malo de hacer según RFC o el mundo real?

Lo pregunto porque sigo encontrando pequeñas sorpresas con el framework web que estoy usando (Ruby on Rails) y las capas debajo de eso (Passenger, Apache, por ejemplo, tuve que habilitar "ALLOW_ENCODED_SLASHES" para Apache) . Ahora me inclino por deshacerme por completo de las barras codificadas, pero me pregunto si debería estar presentando informes de errores donde veo un comportamiento extraño que involucra las barras codificadas.

cuanto a por qué tengo las barras codificadas en primer lugar, básicamente, tienen rutas como esta:

:controller/:foo/:bar 

donde: foo es algo así como un camino que puede contener barras. Pensé que lo más sencillo sería escanear el URL foo para que el mecanismo de enrutamiento no tenga en cuenta las barras oblicuas. Ahora estoy teniendo dudas, y está bastante claro que los frameworks realmente no lo soportan, pero de acuerdo con el RFC ¿está mal hacerlo de esta manera?

Aquí hay alguna información que he reunido:

RFC 1738 (URL):

Por lo general, una URL tiene la misma interpretación cuando un octeto está representado por un personaje y cuando se codifica. Sin embargo, esto no es cierto para los caracteres reservados: la codificación de un carácter reservado para un esquema particular puede cambiar la semántica de una URL.

RFC 2396 (URI):

Estos caracteres se llama "reservados", ya que su uso dentro del componente URI se limita a su propósito reservado. Si los datos de un componente URI entrarían en conflicto con el propósito reservado, entonces los datos en conflicto se deben escapar antes de formar el URI.

(qué escapar aquí media algo más que codifica el carácter reservado?)

RFC 2616 (HTTP/1.1):

caracteres distintos a los de la "reservado" y "inseguro "conjuntos (ver RFC 2396 [42]) son equivalentes a su codificación"% "HEX HEX".

Existe también this bug report de rieles, donde parecen esperar que la barra codificada a comportarse de manera diferente:

derecho, me gustaría esperar resultados diferentes porque están apuntando a diferentes recursos.

Está buscando el archivo literal 'foo/bar' en el directorio raíz. La versión no escapada está buscando la barra de archivos dentro del directorio foo.

Está claro desde las RFC que la cruda versus codificada es el equivalente para caracteres sin reserva, pero ¿cuál es la historia para los caracteres reservados?

Answer 1

A partir de los datos que recopiló, tendería a decir que el codificado "/" en un uri debe verse como "/" nuevamente en el nivel de aplicación/cgi.

Es decir, que si está utilizando apache con mod_rewrite, por ejemplo, no coincidirá con el patrón que prevé barras diagonales contra el URI con barras diagonales codificadas. Sin embargo, una vez que se llama al módulo/cgi/... apropiado para manejar la solicitud, le toca hacer la decodificación y, por ejemplo, recuperar un parámetro que incluya barras como el primer componente del URI.

Si su aplicación está utilizando esta información para recuperar un archivo (cuyo nombre de archivo contiene una barra inclinada), eso probablemente sea algo malo.

En resumen, me parece perfectamente normal ver una diferencia de comportamiento en "/" o "% 2F", ya que su interpretación se realizará a diferentes niveles.

Answer 2

También tengo un sitio que tiene varias URL con caracteres urlencoded. Estoy descubriendo que muchas API web (incluidas las herramientas de webmaster de Google y varios módulos de Drupal) se cruzan con los caracteres urlencoded. Muchas API decodifican automáticamente urls en algún punto de su proceso y luego usan el resultado como una URL o HTML. Cuando encuentro uno de estos problemas, generalmente codigo doblemente los resultados (que convierte% 2f en% 252f) para esa API. Sin embargo, esto romperá otras API que no esperan doble codificación, por lo que esta no es una solución universal.

Personalmente me estoy deshaciendo de tantos caracteres especiales en mis URL como sea posible.

Además, estoy usando números de identificación en mis URLs que no dependen de urldecoding:

example.com/blog/my-amazing-blog%2fstory/yesterday

se convierte en:

example.com/blog/12354/my-amazing-blog%2fstory/yesterday

en este caso, mi código solo usa 12354 para buscar el artículo, y el resto de la URL es ignorada por mi sistema (pero es todavía se usa para SEO). Además, este número debe aparecer ANTES de la URL no utilizada co mponentes. de esa manera, la url seguirá funcionando, incluso si el% 2f se decodifica incorrectamente.

Además, asegúrese de usar etiquetas canónicas para garantizar que los errores de las URL no se traduzcan en contenido duplicado.

Answer 3

Si usa Tomcat, agregue '-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH = true' en las propiedades de VM.

https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security

Answer 4

La historia de %2F vs / fue que, de acuerdo con la inicial W3C recommendations, barras «debe implicar una estructura jerárquica»:

Ejemplo 2

Los URIs

http://www.w3.org/albert/bertram/marie-claude

y

http://www.w3.org/albert/bertram%2Fmarie-claude

no son idénticos, como en el segundo caso la barra codificada hace no tiene importancia jerárquica.

Answer 5

¿Qué hacer si :foo en su forma natural contiene barras diagonales? No lo desea ¿No es que la distinción que la recomendación intenta preservar? It specifically notes,

La similitud con UNIX y otras convenciones de nombre de archivo del sistema operativo de disco debe tomarse como pura coincidencia, y no debe ser tomado para indicar que URIs deben interpretarse como nombres de archivo.

Si uno fue la construcción de una interfaz en línea a un programa de copia de seguridad, y desea expresar el camino como parte de la ruta URL, lo que tendría sentido para codificar las barras en la ruta del archivo, ya que es no realmente parte de la jerarquía del recurso, y más importante aún, la ruta . /backups/2016-07-28content//home/dan/ pierde la raíz del sistema de archivos en la doble barra. Escapar de las barras es la forma adecuada de distinguir, a medida que lo leo.