La reescritura de URLs se refiere al proceso de modificar una URL para hacerla más fácil y accesible a los usuarios de Internet. Normalmente, esta modificación se produce para que la URL sea más corta y coherente. De este modo, los usuarios lo recordarán y no tendrán problemas para leerlo o escribirlo si lo necesitan.

Hoy en día, los internautas saben que existen enormes riesgos en Internet. Y cuando nos encontramos con una URL de cola larga formada por números y letras, tendemos a sospechar de ella.

Por eso es importante asegurar la confianza de los visitantes cuando se encuentren por primera vez con su URL, haciéndola corta y significativa.

Si todavía no entiende el concepto de reescritura de URL, le invito a que lea detenidamente este artículo.

Capítulo 1: ¿Qué es la reescritura de URLs?

En este capítulo, intentaremos aclarar los temas esenciales para que tenga una idea clara de lo que significa la reescritura de URL.

1.1. Definición de reescritura de URL

Casi todos los servidores, ya sean Apache, Nginx, Microsoft IIS u otros, tienen la capacidad de modificar las URL antes de que sean visibles para los buscadores.

Esta modificación suele producirse cuando un documento solicitado se encuentra en otro lugar y el visitante debe ser redirigido a la nueva ubicación.

Además de estas reescrituras externas en las que un visitante solicita una URL y el servidor comprueba si hay ciertas redirecciones que se aplican a la URL solicitada, también hay reescrituras internas.

Los servidores pueden reconocer rápidamente el documento o recurso que debe estar disponible en una URL, independientemente de dónde esté almacenado en la estructura interna de carpetas.

Si tomamos el caso de WordPress, por ejemplo, cada entrada del blog se almacena en una base de datos y se le asigna un identificador. Las páginas individuales se pueden solicitar siempre a través de este identificador.

1.2) ¿Cómo funciona la reescritura de URLs?

La función de reescritura de URLs simplemente coloca una capa sobre la dirección original y la transforma en algo que sea fácil de encontrar y tenga sentido.

Desde la perspectiva del usuario, después de la reescritura, la URL del sitio web sigue siendo la misma en el navegador, pero más consistente

Pero entre bastidores, el navegador reescribe la URL en este complicado lío y envía una solicitud a los servidores.

Las reescrituras de URL también son extremadamente útiles cuando se cambia la estructura del servidor y se mueven los recursos de una carpeta a otra

En esta situación, un administrador del sistema se limitará a escribir la parte a la que apunta la URL amigable

Básicamente, como el recurso se ha movido, tendrá una ubicación diferente. Por lo tanto, se requiere una reescritura para apuntar la URL reescrita a la nueva ubicación del recurso

Esto no debe confundirse con las funciones de redirección que se producen cuando un recurso ha sido sustituido por otro diferente.

1.3. ¿Cuál es la importancia de reescribir una URL?

Es muy importante que las URL tengan sentido y den una idea de la página a la que se refieren, a la vez que sean fáciles de entender para los motores de búsqueda.

La reescritura de URL no muestra al usuario el funcionamiento interno y las estadísticas que hay detrás de la dirección de un sitio web, evitando que vea las cadenas de consulta, lo que no es beneficioso para el sitio.

Este proceso no sólo es útil para quienes lo ven o lo leen, sino que también contribuye al aspecto de la seguridad del sitio al impedir en gran medida la piratería o el acceso de usuarios malintencionados

Intenta crear una URL rica en palabras clave, lo que significa incluir la palabra clave en el texto de la URL, lo que ayudará eficazmente al proceso de SEO

Esto garantiza que el sitio en desarrollo ya está optimizado en cierta medida antes de su lanzamiento.

Las URLs creadas también tienden a ocultar los enlaces, que la mayoría de las veces parecen no tener fin.

Además, se puede seguir utilizando la misma URL, aunque haya un cambio en el enlace original.

El proceso de reescritura de URLs puede realizarse en cualquier tipo de sitio o sistema de gestión de contenidos web, tanto si se trata de un sitio desarrollado por asp.net como de los creados con tecnología PHP

El proceso de reescritura de URLs se realiza en función de los idiomas y las necesidades de los sitios web

Esto parece ser posible con la tecnología ASP.NET de manera eficiente, ya que es similar a Internet Information Server (IIS). De hecho, ASP.NET es un motor de scripting del lado del servidor (IIS) que produce páginas web interactivas.

La reescritura de URL también es posible con PHP con el módulo mod rewrite para el servidor Apache, entre otros.

Además, también parecen ser fáciles de usar a través de la interfaz. También es útil si un usuario quiere eliminar una sección de la URL para navegar al siguiente nivel, lo cual es muy beneficioso para ellos.

Supongamos que un usuario aterriza en la página example.com/seo/recritture-url y quiere volver a la página de inicio. Pueden simplemente mantener example.com y eliminar las otras partes.

1.4. ¿Por qué la reescritura de URLs es buena para el SEO?

El uso de la reescritura de URLs tiene varias ventajas. En primer lugar, la reescritura de URLs ayuda a la accesibilidad y a mejorar la experiencia del usuario

En pocas palabras, cuando un usuario mira una URL en los resultados de un motor de búsqueda, no tiene que intentar averiguar de qué trata esa página o artículo.

Además, las URL desordenadas no animan a la gente a hacer clic en ellas, lo que puede llevar a un menor índice de clics. Esto es generalmente malo para el SEO y el rendimiento del sitio.

Por otro lado, las URLs amigables ayudan a optimizar el contenido para el SEO

Una URL que incluya el título del artículo y la palabra clave principal le ayudará en la indexación de Google y en la percepción que los bots tienen de su artículo o página web

Como resultado, las URLs optimizadas para el SEO mediante la reescritura de URLs conducen a una mejor visibilidad, más credibilidad con sus usuarios y naturalmente un mayor volumen de tráfico.

Aparte de eso, el uso de la reescritura de URLs también ayuda a mantener la coherencia en su ruta de URLs y en la estructura del nombre de la página

Por último, las reescrituras también contribuyen al rendimiento mediante el almacenamiento en caché del modo de usuario y la resolución de problemas, ya que se encargan del seguimiento de las solicitudes fallidas.

1.5. Reescritura de URLs vs. redireccionamiento

A diferencia de las reescrituras de URL, una redirección es una acción del lado del cliente, no del lado del servidor.

Básicamente, se produce una reescritura cuando la dirección del recurso cambia, o necesitamos una capa más sencilla y fácil de usar

Esto ocurre entre bastidores y el usuario no es consciente de ello. En comparación, una redirección se produce cuando el recurso ya no existe.

Los redireccionamientos también pueden producirse cuando predecimos cómo intentará un usuario acceder a un recurso y configuramos las funciones de redireccionamiento para asegurarnos de que accede al recurso correctamente.

Por ejemplo, la resolución de WWW es una acción de redireccionamiento por la que, independientemente de cómo busque el usuario la página de inicio de Twaino, utilice o no WWW. antes del nombre de dominio, siempre aterrizará en Twaino.com.

Capítulo 2: ¿Por qué es importante reescribir la URL?

Este capítulo se centra en las razones por las que los webmasters deberían hacer una reescritura.

2.1. Las aplicaciones deben ser seguras

Es importante que los webmasters protejan sus sitios web de todo tipo de ataques. De hecho, un individuo no debería poder dañar su sitio web cambiando una URL que apunte a sus aplicaciones

Para garantizar la seguridad de su sitio, compruebe todas las variables GET de sus visitantes.

Por ejemplo, supongamos que tenemos un sencillo script que muestra todos los productos de una categoría. Suele ser así:

• myapp.php?target=showproducts&categoryid=123

Pero cuando un ScriptKiddie(tm) teclea en su barra de navegación myapp.php?target=showproducts&categoryid=youarebeinghacked, muchos sitios mostrarán mensajes de error quejándose de haber utilizado una consulta SQL incorrecta, un ID de recurso MySQL no válido, etc. Esto simplemente muestra que estos sitios no son tan buenos como podrían ser

Esto simplemente demuestra que estos sitios no son seguros en absoluto o son muy seguros.

2.2. Las aplicaciones deben ser fáciles de encontrar en los motores de búsqueda

No es de conocimiento general, pero muchos motores de búsqueda no indexarán su sitio a fondo si contiene enlaces a páginas dinámicas como la mencionada anteriormente

Simplemente toman la parte «nombre» de la URL. Es decir, todo lo que está antes del signo de interrogación, que contiene los parámetros necesarios para que la mayoría de los scripts funcionen, y luego intenta recuperar el contenido de la página

Para que quede claro, he aquí algunos enlaces de nuestra página ficticia:

• myapp.php?target=showproducts&categoryid=123 ;
• myapp.php?target=showproducts&categoryid=124 ;
• myapp.php?target=showproducts&categoryid=125.

Lamentablemente, es muy probable que algunos motores de búsqueda intenten descargar la página myapp.php.

En la mayoría de los casos, llamar a una secuencia de comandos como ésta provocará un error o no mostrará el contenido apropiado al que apuntaba el enlace

Pruebe esta búsqueda en google.com:

»tiene un error en su sintaxis sql» .php -forum

Se dará cuenta de que hay grandes errores y amenazas de seguridad en los scripts listados

2.3. Las aplicaciones deben ser fáciles de usar

Si su sitio web utiliza una aplicación como

quehttp://www.downloadsite.com?category=34769845698752354, entonces a la mayoría de sus visitantes les resultará difícil volver a su categoría favorita cada vez que abandonen la página principal de su sitio

Es incluso más fácil para el usuario encontrar la URL en la lista desplegable de los navegadores cuando escribe en el campo «Ubicación», aunque por supuesto esto sólo funciona si el usuario la ha visitado antes.

Capítulo 3: ¿Cuáles son las reglas para la reescritura de URLs?

Es obvio que la reescritura de URLs es una oportunidad para que los sitios hagan que sus URLs sean fáciles de usar. Sin embargo, esta práctica debe seguir ciertas reglas para ser eficaz y producir los efectos deseados.

En este capítulo, hablaremos de las reglas que deben seguirse para reescribir correctamente las URL de un sitio.

3.1) Cómo reescribir una URL con IIS

Para reescribir una URL con IIS, primero debe instalar el software que puede descargarse de la plataforma de Microsoft.

Una vez instalado, verá un nuevo icono de «Reescritura de Url» en la consola de gestión de IIS.

Paso 1: La consola de gestión de IIS con la reescritura de URLs añadida

Puede gestionar la reescritura de URLs a nivel de servidor o para sitios individuales, según le convenga

Con el módulo de reescritura de URL, verá las «plantillas» utilizadas. Las plantillas están en uno de los tres modos

• Coincidencia exacta
• Comodines; y
• Y las expresiones regulares de ECMAScript, que son expresiones regulares compatibles con Perl.

Hay dos tipos de reglas: de entrada y de salida

Las reglas de entrada examinan las URL de las solicitudes y las modifican. Mientras que las reglas de salida inspeccionan el tráfico enviado, buscan las URLs que contiene y las reescriben si es necesario;

Esto es aún más interesante cuando el contenido puede utilizar una URL absoluta que no es la que debe recibir el usuario;

Una de las ventajas de la reescritura de URLs es que admite una serie de reglas incorporadas que facilitan la vida cuando se quiere hacer una reescritura común

La lista completa de reglas incorporadas es :

• Regla con mapa de reescritura: permite definir un conjunto de rutas y sus sustituciones como una simple lista;
• Bloqueo de la consulta: Prohibir el acceso a un camino;
• URL fácil de usar: cree rápidamente reglas para asignar segmentos de ruta a cadenas de consulta;
• Proxy inverso: Permite que el servidor actual haga proxy inverso a otro;
• Hacer cumplir las URLs en minúsculas: Obliga al cliente a utilizar siempre las URLs en minúsculas a través de una redirección HTTP 301 «Permanente»;
• Nombre de dominio canónico: Utiliza una redirección HTTP 301 «permanente» para garantizar que los clientes utilicen siempre el nombre de dominio especificado;
• Añadir o eliminar el símbolo de la barra diagonal final: Esto siempre añadirá o eliminará la barra diagonal final en una ruta de URL que utilice una redirección de estado HTTP 301 ‘Permanente’.

Paso 2: La creación de una regla le permite elegir una regla incorporada para empezar

Las reglas incorporadas son estupendas porque, aunque vienen con un asistente personalizado, si es necesario, generan reglas estándar que luego puede ajustar o modificar según sea necesario.

La regla de la URL fácil de usar es bastante popular para aquellos que no tienen un sistema que lo haga automáticamente

Se empieza por introducir un ejemplo de la URL «fea» que el sitio necesita realmente

Paso 3: Crear una regla de URL amigable

Otra de las reglas incorporadas que la mayoría utiliza es la regla del proxy inverso

De nuevo, el sistema le guía a través de una competente configuración por defecto en lo que podría ser una tarea muy compleja

Contiene opciones incorporadas y editables como:

• Si las respuestas HTTPS deben ser siempre proxies a HTTP estándar o no;
• Si desea o no utilizar una regla de salida para ocultar el nombre del servidor interno

La gente suele utilizarlo para poder configurar un servidor central con hosts web virtuales en la misma dirección IP para gestionar las solicitudes entrantes que deben enviarse a diferentes servidores internos.

Figura D: Creación de un proxy inverso

La última regla que discutiremos es la de los mapas de reescritura

Estos le permiten crear una lista de URLs y traducirlas en URLs sustitutivas

Por sí solo, un mapa de reescritura es innecesario, debe utilizarse como parte de una regla más amplia en lugar de o junto con patrones de sustitución

Son especialmente útiles cuando se diseña o reorganiza un sitio que utiliza URLs no predecibles

Combinando una redirección mediante el estado HTTP 301 »Permanente» con un mapa de reescritura, puede personalizar sus traducciones en situaciones en las que las reglas no funcionan bien.

Una vez que haya establecido la regla básica, puede modificarla según sea necesario. El editor de reglas desglosa muy bien las cosas

Se comienza con un nombre de regla y la plantilla de URL que debe coincidir

A partir de ahí, puede añadir varias condiciones, como:

• Una búsqueda de una cadena concreta en un parámetro de la URL
• Una variable de entorno del servidor
• Y así sucesivamente

Puede indicarle que coincida con todas las condiciones o con alguna de ellas. Si no se cumplen las condiciones, la regla no realizará la reescritura

También puede realizar sustituciones en las variables del servidor, lo que es ideal para imponer ciertos comportamientos

Las variables del servidor abarcan una lista muy amplia de elementos con los que trabajar, incluidos los mapas de reescritura que ha creado

A continuación, se define lo que la regla debe hacer realmente, que es realizar una reescritura o redirección que enviará realmente un código de estado HTTP de redirección al cliente para que consulte la nueva URL

A continuación, defina la plantilla para la reescritura propiamente dicha. Por último, tiene algunas opciones:

• Añadir la cadena de solicitud;
• Guarde la solicitud;
• No ejecute más reglas después de que haya terminado.

3.2 ¿Cómo reescribir una URL con Apache?

A continuación le indicamos algunos pasos sobre cómo puede definir reglas de reescritura de URL con Apache:

Paso 1: Instalar el servidor web Apache

Antes de empezar, asegúrese de que tiene el paquete del servidor web Apache instalado en su sistema. Si no está instalado, puede instalarlo con el siguiente comando: »apt-get install apache2 -y»

Una vez instalado el paquete, inicie el servicio Apache con la siguiente orden: »systemctl start apache2».

A continuación, abra su navegador web y escriba la URL http://your-server-ip para comprobar el servidor web Apache

Paso 2: Habilitar mod_rewrite

Por defecto, el módulo mod_rewrite se instala con el paquete de Apache, pero está desactivado. Por lo tanto, tendrá que habilitarlo primero.

Puede habilitarlo con el siguiente comando: »a2enmod rewrite».

A continuación, reinicie el servicio Apache para aplicar los cambios y compruebe el módulo mod_rewrite de Apache con el siguiente comando: apache2ctl -M | grep rewrite_module.

Debería obtener la siguiente salida: rewrite_module (shared)

Paso 3: Habilitar los archivos .htaccess

Puede establecer reglas de reescritura directamente en el archivo de configuración principal de Apache. Sin embargo, se recomienda escribir reglas en el archivo .htaccess dentro de cada sitio web.

Por defecto, Apache no permite utilizar el archivo .htaccess. Tendrá que habilitar el archivo .htaccess en su archivo de configuración del host virtual por defecto.

Para ello, edite el archivo de configuración del host virtual por defecto de Apache: nano /etc/apache2/sites-available/000-default.conf.

Añada las siguientes líneas antes de la línea

Opciones Índice FollowSymLinks MultiViews

Permitir todo lo que se anule

Exigir que se conceda a todos

Asegúrese de guardar y cerrar el archivo, luego reinicie el servicio de Apache para aplicar los cambios: systemctl restarts apache2.

Paso 4: Configurar las reescrituras de URL

Para entender cómo funciona la reescritura de URLs, crearemos una página home.html en el directorio raíz del documento Apache

A continuación, configuraremos una reescritura de URL básica que accederá a la página http://your-server-ip/home y la convertirá en la ruta real de la página http://your-server-ip/home.html.

Empecemos por crear una página home.html:

nano /var/www/html/home.html

Añada el siguiente contenido:

Inicio

Página de inicio

Aquí está mi página de inicio

Guarde y cierre el archivo cuando haya terminado.

A continuación, cree un archivo .htaccess en el directorio raíz del documento por defecto del sitio web para probar mod_rewrite.

nano /var/www/html/.htaccess

Primero, añada la siguiente línea para habilitar el motor de reescritura: RewriteEngine enabled.

A continuación, añada la siguiente regla de reescritura que redirige a los visitantes a home.html si solicitan la página http://your-server-ip/home: RewriteRule ^home$ home.html [NC].

Guarde y cierre el archivo cuando haya terminado.

A continuación se ofrece una breve explicación de la sintaxis de las reglas de reescritura:

• ^: Esto coincidirá con cualquier texto después de la dirección IP del servidor;
• $: Indica el final de la URL.
• home: Coincide con la cadena real home;
• home.html: Define el archivo real al que accede el visitante;
• [NC]: Esto hace que la regla no distinga entre mayúsculas y minúsculas.

Ahora puede visitar la página de inicio en http://your-server-ip/home en su navegador web. Apache redirigirá a la página home.html.

3.3. Cómo hacer una reescritura con nginx

En nginx, la directiva de reescritura puede especificarse en uno de los tres contextos: servidor, ubicación, si.

3.3.1. Ejemplo de reescritura en Nginx utilizando $1, $2, .

He aquí un ejemplo de una directiva de reescritura de Nginx: rewrite ^(/data/.*)/geek/(\w+)\N…*$ $1/linux/$2.html last.

Por ejemplo :

Url/data/distro/geek/test.php se reescribirá como url/data/distro/linux/test.html.

En este ejemplo, cuando llame a la URL original con test.php desde el navegador, se reescribirá según la regla de reescritura anterior y servirá la página test.html de /data/distro/linux/

En la regla de reescritura anterior :

• $1 y $2 capturan las cadenas apropiadas de la URL original que no cambia;
• $1 en la cadena de reemplazo coincidirá con cualquier cosa dentro del primer paréntesis ( ) en el reg-ex. En nuestro ejemplo, $1 es /data/ ;
• Del mismo modo, $2 coincide con todo lo que está dentro del segundo paréntesis ( ) en el reg-ex. Así, 2$ es (\w+), que es cualquier palabra que viene después de /geek/ en la URL original;
• En nuestro ejemplo, 2$ es una última prueba. Esta bandera se asegurará de dejar de buscar la directiva de reescritura en la ubicación o bloque actual y utilizar la URL modificada y buscar una nueva ubicación para cualquier otra directiva de reescritura que coincida;
• *$: Indica la extensión en la URL original. Tenga en cuenta que aquí la extensión de la URL original será sustituida por .html en la URL reescrita. Así que aunque llame a .php en la URL original, sólo servirá el archivo .html en la URL reescrita.

Aunque las reglas de reescritura de Nginx son similares a las de Apache, todavía hay muchas diferencias en la forma de escribir una regla de reescritura en Nginx.

3.3.2. Creación de un archivo de control con Nginx Rewrite

Utilizando la reescritura, puede enrutar muchas URLs de origen entrantes a una plantilla de controlador maestro que servirá esas peticiones.

El siguiente ejemplo de reescritura lo explica:

• rewrite ^/linux/(.*)$ /linux.php?distro=$1 last ;

En este ejemplo, cuando llame a la URL thegeekstuff.com/linux/centos, se reescribirá utilizando la regla anterior y servirá la página con esta URL reescrita

• thegeekstuff.com/linux.php?distro=centos

Como puede ver arriba, cualquier URL que coincida con el patrón aquí /linux/ en la URL será servida por linux.php, pero la última parte de la URL entrante original se utilizará como valor para el argumento de distribución en el controlador linux.php.

Así, la regla de reescritura anterior transformará la URL entrante de la siguiente manera:

• linux/centos se convierte en linux.php?distro=centos ;
• linux/debian se convierte en linux.php?distro=debian ;
• linux/redhat se convierte en linux.php?distro=redhat ;
• etc.

Como en el ejemplo anterior, utilizamos $1 en la cadena de sustitución para capturar todo lo que hay dentro del primer paréntesis ( ) en el reg-ex. En este caso, se trata de la última parte de la URL entrante original.

También utilizamos la última bandera aquí para decirle a nginx que deje de buscar otras directivas de reescritura en el bloque actual y se mueva a la siguiente ubicación correspondiente para seguir buscando.

3.3.3. Reescribir el indicador de ruptura en el contexto de la ubicación

En este ejemplo, hemos colocado la condición de reescritura en la directiva de ubicación.

En este ejemplo, la directiva de ubicación es /data/, que también coincide con el $1 de la cadena de sustitución que se indica a continuación.

datos de localización/ {

rewrite ^(/data/.*)/geek/(\w+)*$1/linux/$2.html break ;

devolver 403 ;

}

Esto es lo que habría sucedido si hubiera utilizado la bandera «última» de arriba:

• Por lo tanto, si tiene »última» como bandera, después de la reescritura inicial de la URL, Nginx normalmente buscará la siguiente directiva de reescritura para la nueva URL;
• En este caso, Nginx seguirá redirigiendo a los mismos datos de ubicación y continuará procesando la misma regla de reescritura hasta 10 veces, y finalmente devolverá el código de error 500.

3.3.4. Añadir un signo de interrogación a la cadena de sustitución Nginx Rewrite

Si una cadena de sustitución incluye las nuevas palabras clave de consulta, las palabras clave de consulta anteriores se añaden después de ellas

Si no desea hacerlo, coloque un signo de interrogación al final de la cadena de sustitución para evitar añadirlos.

En el siguiente ejemplo, en la parte de la cadena de sustitución, no hay ningún signo de interrogación al final. Es decir, no hay signo de interrogación después de 1 dólar:

rewrite ^/linux/(.*)$ /linux.php?distro=$1 last ;

En el ejemplo anterior, cuando la cadena de sustitución incluye los argumentos de la solicitud entrante, los argumentos de la solicitud anterior se añadieron después de ellos.

Si no quiere que esta adición se produzca, puede tener un resultado alternativo.

En el siguiente ejemplo, en la parte de la cadena de sustitución de la reescritura de Nginx, puede añadir (?) al final, es decir, hay un signo de interrogación después de $1

rewrite ^/linux/(.*)$ /linux.php?distro=$1? last;

En el ejemplo anterior, la cadena de sustitución incluye los argumentos de la solicitud entrante, y después no se añaden los argumentos de la solicitud anterior.

3.3.5 »Si» El contexto y la directiva de reescritura

Los siguientes ejemplos ilustran que podemos utilizar la reescritura dentro de la directiva if.

Puede realizar una reescritura condicional basada en una comparación de condiciones if utilizando variables como $scheme, $http_host, $http_user_agent, etc., como se muestra a continuación:

if ($scheme = «http») {

reescribir ^ https://www.thegeekstuff.com$uri permanente ;

}

if ($http_host = thegeekstuff.com) {

reescribir (.*) https://www.thegeekstuff.com$1 ;

}

if ($http_user_agent = MSIE) {

reescribir ^(.*)$ /pdf/$1 pausa ;

}

Tenga en cuenta también que hay mejores formas de conseguir el resultado final de los ejemplos anteriores

Los ejemplos anteriores sólo se dan para mostrar que podemos añadir una directiva de reescritura dentro de la declaración »if» en el archivo de configuración de nginx.

Tenga en cuenta que también puede activar o desactivar el valor de los dos parámetros siguientes en su archivo de configuración de nginx:

nombre_servidor_en_redirección on

port_in_redirect desactivado

3.3.6. Captura de los aciertos de reescritura de Nginx en el archivo de registro de errores

Por defecto, cada vez que Nginx realiza una reescritura con éxito, no la registra en el archivo error.log.

Al principio, cuando se escriben reglas de reescritura complejas, hay que asegurarse de que Nginx realiza la reescritura como es debido.

Para ello, debe habilitar el registro de reescritura, que escribirá una entrada de registro cada vez que nginx realice una reescritura con éxito utilizando una de las directivas de reescritura del archivo de configuración.

Para ello,

• Utilice la directiva rewrite_log y póngala en on;
• Añada las dos líneas siguientes a su nginx default.conf:

notice error_log /var/log/nginx/error.log ;

rewrite_log a ;

La primera línea indica la ubicación del archivo error_log donde deben escribirse los mensajes de reescritura

Tenga en cuenta que un mensaje de reescritura es de tipo aviso. Por lo tanto, debe añadir »nota» al final de esta línea como se muestra arriba.

3.4. ¿Cuál es el verdadero problema de las reglas de reescritura de URL?

Los desarrolladores de aplicaciones web utilizan reglas de reescritura de URL para ocultar los parámetros en la estructura de la ruta de la URL

Esto facilita que los motores de búsqueda indexen todas las páginas de un sitio web, mientras que los navegadores web reciben la URL en un formato que entienden y que es fácil de recordar para los usuarios.

Es importante asegurarse de que estas peticiones son aceptadas por la aplicación web y de que todos los parámetros de la URL se analizan correctamente

A continuación se resumen los problemas que pueden surgir cuando el software de exploración automatizada de vulnerabilidades web intenta explorar sitios web que utilizan tecnología y reglas de reescritura de URL:

3.4.1. Los parámetros en las URLs no se escanean

Un problema común con el que se encuentran los escáneres de vulnerabilidad web cuando escanean aplicaciones web que utilizan tecnología de reescritura de URL es que los escáneres no pueden identificar los parámetros en las URL

Los escáneres asumen que las URLs son directorios y no nombres o valores de parámetros, y los dejan sin escanear.

3.4.2. Exploraciones de vulnerabilidad prolongadas

Este problema puede conducir a exploraciones prolongadas y a resultados de exploración incorrectos

Por ejemplo, si el escáner de vulnerabilidades web analiza una base de datos de herramientas que contiene 100.000 herramientas, como el escáner no es capaz de identificar que hay un parámetro y un valor en la URL, pensaría que son páginas diferentes. Así que tratará de rastrear y escanearlos todos.

Si los problemas de memoria y otras excepciones no son manejados adecuadamente por su escáner, esto también podría causar que su software comience a fallar y lo deje sin resultados.

3.4.3. Establecer reglas de reescritura de URLs es un proceso difícil

Como la tecnología de reescritura de URLs se ha hecho muy popular en las aplicaciones web, muchos escáneres comerciales de vulnerabilidad web permiten a los usuarios configurar el escáner. Esto les permite identificar los parámetros en las URL y escanearlas.

Pero aunque los escáneres de vulnerabilidad web pueden configurarse para escanear sitios web utilizando reglas de reescritura de URL, los usuarios pueden encontrarse con varios otros problemas como

• Configurar el soporte para las reglas de reescritura de URL es muy difícil;
• El usuario debe saber cómo escribir expresiones regulares;
• El usuario debe tener acceso a los archivos de configuración del servidor web.

Por lo tanto, si usted no es el desarrollador de la propia aplicación web o si no tiene un conocimiento profundo de la misma, es imposible configurar las reglas de reescritura de URL en el escáner

Y, aunque sepa cómo hacerlo, configurar las reglas de reescritura es una tarea muy difícil y que requiere mucho tiempo.

3.4.4. Las aplicaciones web no se analizan adecuadamente en busca de vulnerabilidades

Suponiendo que consiga configurar reglas de reescritura de URL en su escáner de vulnerabilidad web, hay otros problemas.

Hay una serie de limitaciones en la forma en que los escáneres exploran la aplicación web. Como medida de seguridad, las aplicaciones web no aceptan peticiones HTTP que ya estén «traducidas»

Por defecto, las aplicaciones web .NET no aceptan peticiones HTTP

El problema se vuelve aún más importante cuando se analizan las aplicaciones web MVC, ya que estas aplicaciones utilizan un enfoque diferente para la reescritura de URL.

Una vez que haya configurado las reglas de reescritura de URL en su escáner, éste envía un tipo de solicitud HTTP llamada solicitud traducida

Aunque el escáner de seguridad de la aplicación web informa de que el escaneo fue exitoso, la mayoría de las solicitudes HTTP son rechazadas y los parámetros de la URL no son escaneados, lo que le da una falsa sensación de seguridad.

Conclusión

Observamos que la reescritura de la URL es a veces esencial para garantizar que su dirección no dé una mala sensación a los internautas.

Es un proceso que ofrece muchos beneficios desde la perspectiva del SEO y de la credibilidad del sitio web.

En este contenido, hemos aclarado el concepto de reescritura de URLs y lo hemos acompañado de las mejores formas de reescribir sus URLs.

Le invitamos a compartir con nosotros sus opiniones y otros recursos sobre el concepto de reescritura de URL.