Share on Google+Share on FacebookTweet about this on Twitter

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

Header Spoofing

En un principio, cuando puse en mente esta serie de artículos, tenía pensado hablar tan solo de Referred Spoofing, pero por extender un poco más esto y que se comprenda mejor, vamos a expandirlo a todo el Header.

En realidad no estoy seguro si el término Header Spoofing existe o no. Ya sabemos que es el Spoofing y ha quedado más o menos claro. Pero que es ¿Header? Header (o Cabecera) pueden ser muchas cosas (Perdonarme y permitirme muchas veces los términos anglosajones, soy un férrimo defensor de nuestra lengua castellana y comprendo que para la mayoría de toda esta jerga existen términos castellanos para ellos. No obstante la costumbre de trabajar con ellos siempre en ingles te crea el hábito).

Una cabecera en una carta sirve para especificar por ejemplo la fecha. En informática un header suele ser lo mismo, una serie de datos que preceden a otros. Nosotros nos vamos a centrar en el header de una web, pero como digo el ámbito es muy grande. Más adelante, en eMail Spoofing por ejemplo veremos el header de un correo.

Cuando accedes desde el navegador a cualquier web, se ponen en marcha una serie de procesos que son completamente transparente para el usuario. Primero peticiones DNS y después el request (o petición) de la web al servidor. Este recuest explicado en simple sería algo así como enviar por ejemplo a google un mensaje que diga: “Quiero acceder a tu buscador”, y google con un response (contestación) contestaría algo así como: “Este es mi buscador…..” y la web se visualizaría. En cada petición que se envía hacia un servidor web, así como en cada respuesta de estos a nuestro PC, existe una cabecera con una serie de datos muy interesantes. Estos datos son preconfigurados por nuestro navegador (en caso de los request) en función de las opciones propias del navegador o de la web que estamos en ese momento visitando. Por su parte, los headers de los response de los servidores están igualmente preconfigurado por los servidores de ellos en función de su configuración o de nuestros propios request.

El secretismo en todo esto está en que a efectos prácticos para el usuario, estos headers no los verá jamás, en cambio, sin darse cuenta, la visualización de una web puede ser completamente diferente, así como otro millar de cosas tan solo por esa cabecera. Luego… que sucedería si modificamos nosotros a voluntad esa cabecera? Si modificamos los request, podemos producir un comportamiento interesante por parte del servidor objetivo. Del miso modo si modificamos el header de un response, estaremos modificando el comportamiento de nuestro propio navegador ante un request. ¿Que utilidad tiene esto?:

  • Acceso a webs sin autorización
  • Acceso a webs alternativas
  • Búsqueda de exploits en Webs
  • Cheats para juegos online
  • Etc…

 

¿Que aspecto tienen? Eso ya lo sabemos… en estas páginas por ejemplo se han publicado headers. Pero vamos a ser más concretos. Vamos a ver cual sería el header de una petición desde mi navegador Firefox a www.google.es:

GET / HTTP/1.1
Host: www.google.es
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100203 Minefield/3.7a1pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.google.es/ig?hl=es
Cookie: PREF=ID=XXXXXX
Cache-Control: max-age=0

Cada una de las etiquetas mostradas (Host, User-Agent, Accept…) tiene su propia utilidad y es igualmente importante. Y todas ellas son establecidas por el navegador que estemos usando. Si realizamos exactamente la misma petición, pero desde Internet Explorer esto es lo que tendríamos:

GET / HTTP/1.1
Accept: */*
Accept-Language: es-ES
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0)
Accept-Encoding: gzip, deflate
Host: www.google.es
Connection: Keep-Alive
Cookie: PREF=ID=XXXXXX

Todas estas etiquetas de la cabecera de request, serán procesadas y/o ignoradas por el servidor destino, y este responderá con uno u otros datos de una u otra forma en correspondencia a estas cabeceras. Hay que decir que aunque estas cabeceras sean especificadas por el navegador, no quiere decir que sean inmutables. Las propias webs que se reciben, formularios que se rellenan… dan instrucciones también al navegador de como deben de solicitar dichos request. Es decir, es un círculo vicioso. El navegador es el primero en establecer una cabecera, y el servidor responde con una web. En dicha web, dependiendo de donde pulsemos o las acciones que llevemos a cabo, nuestro request incluirá información de estado de esta web y el servidor destino responderá del modo acordado a esa petición.

Por otro lado, también tenemos las cabeceras que son enviadas por parte del servidor a nuestro navegador. Su importancia suele ser menor, dado que lo que logran es modificar el comportamiento de nuestro navegador, algo que suele importar menos. No obstante también puede tener su utilidad como veremos más adelante. Vamos a ver los response de las peticiones anteriores:

HTTP/1.1 304 Not Modified
Content-Type: text/html
Date: Fri, 05 Feb 2010 15:40:46 GMT
Set-Cookie: IGTP=LI=1:LM=XXXXXXXXXX; expires=Sun, 05-Feb-2012 15:40:46 GMT; path=/ig; domain=www.google.es
Expires: Fri, 05 Feb 2010 15:40:46 GMT
Cache-Control: private, must-revalidate, max-age=0
Last-Modified: Fri, 05 Feb 2010 15:40:46 GMT
ETag: XXXXXXXXXXXXXXXXX
Server: igfe
X-XSS-Protection: 0

Algunas de las cabeceras son ellas mismas descriptivas y no hay que entrar mucho en detalle para comprender que significan o que función realizan, pero no por ello no dejan de ser importantes. Vamos a ver algunas de ellas:

 

-Etiquetas de Metodos y Etiqueta Host

Es la primera etiqueta que aparece, y es la única que podríamos decir que no es una etiqueta. No especifica ninguna cualidad del navegador, sino más bien como se han de obtener los datos, la URI de acceso y la versión del protocolo al que se está accediendo. Mi intención no es dar un repaso completo de cada una de las etiquetas de los headers, para eso tan solo tenemos que acudir a las especificaciones del protocolo. Por tanto vamos a centrarnos tan solo en lo que pueda ser más significativo, los métodos GET y POST. Aunque no sea una definición correcta, podemos decir que GET lo usará el navegador para obtener datos desde un servidor y POST cuando nuestra petición incluye datos que puedan ser significativos para el servidor, por ejemplo los formularios rellenos, credenciales de acceso…

En los dos ejemplos anteriores, la URI es “/”, es decir, se está obteniendo (GET) la ubicación raiz “/” del host especificado en la etiqueta “host”, en este caso “www.google.es”. No obstante la URI podría haber sido algo así como “/es” por ejemplo, para especificar el contenido dentro de “www.google” a recibir. Con esto hemos dicho también el significado de la etiqueta “Host”. Especifica el servidor al cual se desea realizar el acceso. La respuesta de la etiqueta Host por parte de response, podría venir dada pro la etiqueta Server, que especifica el servidor usado. En este caso “igfe” un servidor (software) propio de Google.

En el caso de los response, no aparecerá POST ni GET (entre otros), sino la respuesta a estos. Para ello, se especifica del mismo modo la versión HTTP que usará el servidor y un código que especificará información sobre el site que se ha solicitado. En el ejemplo anterior se contesta con un código 304 -> Not Modified. Es decir, en este caso implicaría que el contenido ha sido encontrado pero no ha sido modificado desde la ultima petición de este, posiblemente porque se ha realizado un refresh de la misma web. Como digo, podemos acudir a las especificaciones HTTP para conocer esto en detalle.

 

-Etiqueta User-Agent

Posiblemente una de las primeras etiquetas Spoofeadas en la historia. El User-Agent es un string, un identificador del navegador que estamos usando. Es una etiqueta fundamental, es la única forma que tiene el servidor de conocer el navegador que estamos usando. Esto es evidente tiene una importancia mayúsculas. ¿Por qué? Es obvio, cada navegador es diferente y usa tecnologías diferentes. Gracias a los User-Agent puedes especificar por ejemplo que tipo de contenido quieres para unos o para otros, puedes simplemente filtrar todas las peticiones de clientes específicos. Es decir, sin que lo sepamos, muchos contenidos que vemos en cada momento está dependiendo exclusivamente de dicho User-Agent. En los dos ejemplos, evidentemente cada User-Agent es completamente diferente.

Normalmente el User-Agent no solo brinda información de la versión del navegador o de su layout, sino incluso del OS que se está usando. En el primer caso, tenemos desde la versión de Firefox, la compilación, la versión del kernel NT (6.1 = Windows 7), incluso el lenguaje de Firefox. En el caso de IE los datos son similares, pero evidentemente referentes a IE.

 

-Etiquetas Accept y Accept Language

La primera especifica los tipos de archivos que aceptará, y si hay más de un tipo especificado, la preferencia de un tipo de contenido respecto a otro. La segunda el lenguaje aceptado, e igualmente que con Accept, si se especifica más de uno cada uno tiene una preferencia diferente. Normalmente esta última etiqueta la podemos nosotros modificar seleccionando otro idioma en las opciones de configuración del navegador. Ojo!! no tiene nada que ver el idioma del navegador, sino el lenguaje solicitado por el navegador. Si el servidor dispone de diferenciación de idiomas nos dirigirá al nusetro, sino, nos devolverá el idioma por defecto que tenga configurado el servidor.

La contestación por parte del servidor en su response de Accept, vendrá dada por la etiqueta Content-Type que especifica precisamente el tipo de contenido que será transferido.

-Etiquetas Accept-Encoding y Accept-Charset

La primera es importante, especifica el tipo de compresión soportada por nuestro navegador. Nuestro navegador envía al servidor una serie de parámetros (las etiquetas) y según estos el servidor podrá seleccionar que web mostrar. Si el servidor está usando compresión y nuestro cliente la soporta, el servidor enviará la información comprimida, ahorrando ancho de banda.

La segunda etiqueta simplemente especifica el conjunto de caracteres que se usará

 

-Etiqueta Cookie

Antes de comenzar… ¿que es una Cookie además de una galleta? Es un pequeño archivo de texto que almacena normalmente unos cuantos datos que son reutilizados después por las webs. Es la única forma que tiene una web de guardar datos en el PC del usuario. Estas Cookies son las que se encargan por ejemplo (normalmente) de mantener una sesión abierta en aquellos sitios que requieren una autentificación, o guardar un pequeño registro sobre algo. Pero por dichos motivos son también un objetivo muy importante. Si una Cookie se usa para que podamos acceder por gmail (por ejemplo), si esa cookie se traspasase a otro usuario, es posible que ese otro usuario pudiese acceder a la misma cuenta de correos que el otro, sin necesidad de conocer las credenciales (usuario y contraseña). Es decir, una cookie puede ser una llave a cualquier sitio que sea necesario autentificarse. Por esta razón, dichas cookies suelen tener una caducidad, así tenemos cookies de sesion (que son eliminadas cuando salimos del navegador) o cookies que son permanentes (o se borran). Por desgracia estas Cookies son usadas demasiado asiduamente para espiarnos o guardar un seguimiento nuestro. Dado que la cookie es accedida también por el servidor, se puede usar para contabilizar las veces que se accede a tal página, realizar seguimientos de las personas… en fin… todo tiene siempre un lado negativo.

Por lo tanto, es otra etiqueta de gran importancia. El navegador especificará la cookie de dicho lugar. Si en dicho momento aun no tiene ninguna cookie almacenada, creará una con el objeto de que pueda ser usada por el servidor si así la requiere. La importancia de poder modificarlas es por tanto muy grande. Las cookies, mientras que suelen estar almacenadas en nuestro PC en archivos, estas no se transmiten como archivos, sino en la cabecera, dentro de la etiqueta Cookie. Es decir, esta etiqueta lo que especifica es el contenido de dicho archivo. Modificar esta etiqueta por tanto implica modificar los datos que contiene la cookie. Evidentemente por motivos de seguridad, estos datos suelen ser ilegibles a simple vista, usando Hashes o algun otro sistema para que la información de estas cookies no sea visible de forma simple (o sea imposible).

 

-Etiqueta Referer

Esta etiqueta es fundamental en muchos aspectos. Lo que realiza esta etiqueta es especificar la web desde la que estamos accediendo a la nueva página. Su uso es claro. El servidor puede actuar de una forma u otra dependiendo de cual era el origen. Un ejemplo muy sencillo a esto es cuando accedemos desde Google images a cualquier imagen y el servidos nos devuelve un error diciendo que la imagen no puede mostrarse porque no se permite su “enlazamiento” desde otro lado. ¿Como sabe el servidor que estamos accediendo desde google? gracias a esta etiqueta.

En cambio, posiblemente el uso más extendido de Spoofing de esta etiqueta sea el del acceso sin autorización a sitios de pago, generalmente páginas pornográficas. Estos sites, suelen permitir con la misma inscripción a un site concreto navegar por otros sites que no son de su propiedad. ¿Pero como sabe ese otro site si el usuario puede o no puede acceder? O ese otro site tiene acceso a la misma base de datos para poder reconocer usuario/contraseña, o simplemente permite el acceso siempre y cuando la etiqueta referer provenga de un site pactado. Es decir, modificando a voluntad una etiqueta referer, es posible acceder a muchos sitios pornográficos de pagos, dado que dichos servidores cotejarán dicha etiqueta por si proviene el usuario de un site con acceso dicho contenido.

 

-Etiqueta Cache-Control

Esta etiqueta la encontramos de forma predominante los response por parte del servidor. En teoría es una orden de como el navegador debe de manejar el caché para dicha página. El caché de un navegador guarda en disco ciertos contenidos de una web para poder acceder a ella más adelante de forma más rápida y eficiente. Pero es evidente que todo el contenido no siembre es bueno cachearlo. Si se cachea y usa el contenido de la caché en vez del deservidor siempre se corre el riesgo de que los datos que estemos visualizando no sean correctos. Un buen manejo del caché podría ser por ejemplo marcar el contenido estático como puedan ser imágenes, scripts… con una duración mayor al que pueda tener por ejemplo un html dinámico con contenido de texto que está casi continuamente cambiando.

Si controlamos el valor de este campo, podríamos obligar a nuestro navegador que cachease el contenido o que no lo hiciese, ambos casos pueden ser útiles en momentos concretos.

 

Aquí tan solo vamos a dar unas pautas de como modificar estas etiquetas. En teoría se puede modificar cualquier cabecera, lo que no quiere decir que pueda ser útil. Por ejemplo, la utilidad de modificar la etiqueta “Accept Language” sería un poco absurdo, dado que puede ser modificada a voluntad en el mismo navegador. Por cuestiones evidentes no puedo poner un ejemplo de Referer Spoofing de una web adulta, pero puedo poner otros ejemplos que pueden extrapolarse a cualquier uso real. Recordar que Spoofing es engañar, modificar… y eso es lo que pretendemos. Vamos a ver ejemplos de Referer Spoofing, Cookie Spoofing y User-Agent Spoofing. Las herramientas que podamos usar para estas prácticas pueden ser más o menos las mismas siempre. Ya que lo que vamos a realizar es modificar estos headers, necesitaremos algo que nos permita interceptar estos datos, y básicamente vamos a encontrar dos formas: La primera con alguna herramienta del mismo navegador web (Bienvenido sea Firefox). La segunda por medio de un Proxy que nos permita modificación “al vuelo”. Para ello vamos a usar algunas extensioens de firefox y como Proxy por ejemplo Paros.

 

User-Agent Spoofing:

Vamos a ver un ejemplo simple de como afecta en el navegador este User-Agent. Lo bueno para muchos es que para aquellas prácticas que están relativamente expandidas existen utilidades para realiza dicha tarea de forma simple. Por ejemplo tenemos herramientas en Firefox que nos permiten especificar directamente que User-Agent queremos usar.Vamos a hacerlo de las dos maneras. Para ello vamos a ver que ocurre cuando llamamos a “www.google.es” con el User-Agent por defecto de mi navegador y que ocurre si invocamos la misma página con el User-Agent del iPhone 3.1.3:

Mi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100205 Minefield/3.7a1pre

iPhone 3.0 User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16

 

Trabajando solo con Firefox (Firebug+User-Agent Switcher):

Ventana de Firebug -> Net -> HTML -> Headers

Configuración User-Agent Switcher

En las dos primeras imágenes podemos comprobar perfectamente como sería una petición básica a www.google.com y como se configuraría un User-Agent dentro de User-Agent Switcher. Firebug es sin duda una herramienta potentísima que puede hacer las delicias de muchos, es una de esas herramientas que cuanto más usas, más aprecias, capaz de hacernos la vida mucho más fácil a los programadores/diseñadores webs.

Google para iPhone y nuevo User-Agent

Al establecer el nuevo User-Agent, el servidor www.google.es considera que la petición se está realizando desde un iPhone, y lo resuelve enviando la web específica para dicho dispositivo. Es tan solo un ejemplo de la importancia de este simple identificativo.

Pero al igual que hemos realizado esto con herramientas de andar por casa (a fin de cuenta una extensión en firefox no deja de ser una extensión), la mejor forma de realizar esto (puesto que no solo nos va a servir para este caso concreto) es la utilización de un servidor proxy que nos intercepte todas las peticiones realizadas:

Paros Proxy, examinando una cabecera
Paros Proxy, modificando una cabecera

Paros Proxy es un software gratuito, sin la complejidad de tener que instalar un servidor proxy completo. Como se muestra en la primera imagen tan solo captura las peticiones que se van realizando, y al finalizar la carga es tan simple como examinar las cabeceras. Una vez localizado el objetivo, es tan facil como poner un “cepo” (trap) a los request, de este modo antes de que sea enviado nuestro request, podremos modificarlo a voluntad.

Aunque no se muestra el resultado final, el efecto es exactamente el mismo que el mostrado anteriormente, salvo que queda de manifiesto el potencial de una herramienta así, dado que con ella podremos modificar no solo el User-Agent, sino lo que deseemos, tanto de los request como de los responses.

 

Referer Spoofing

Ya hemos explicado lo que es, y en User-Agent Spoofing se han dado pautas de como podría realizarse cualquier Header Spoofing. Mi objetivo original era explicar un poco por encima tan solo el Referer Spoofing, y al final será el menos especificado.

En realidad la imaginación es el límite.Cuanto más es usada una etiqueta, más beneficioso podría ser poder controlarla. En este caso hemos dicho que Referer Spoofing se suele controlar para conocer la web de procedencia que nos ha originado en dicho lugar. Mi idea originar era poner una web adulta de ejemplo, pero por cuestiones de edad y de privacidad he decidido no hacerlo. Podría mostrar tan solo imágenes de las propias cabeceras… pero entonces no lograría el objetivo de ver un antes o un después, como hemos realizado con el User-Agent.

Otros ejemplos notables del control de esta etiqueta es para filtrar contenido. Esto es muy usado en blogs y otros sites que no desean que su contenido pueda ser enlazado desde el exterior, mostrando una imagen “falsa” (o mejor expresado, diferente de la esperada) en caso de que sea enlazada con una referencia href. A fin de cuenta, cuando se enlazan imágenes u otros tipo de contenido de forma directa, el ancho de banda corre a cargo de la web original. Por parte de los servidores esto se evita con filtrados en el servidor web, y para evitarlo basta con modificar la etiqueta referer.

 

Cookie Spoofing

Esta etiqueta siempre será objetivo de incesantes ataques. Tal es así que prácticamente todas las cookies actualmente tienen algún tipo de encriptación o modificación para que no se pueda apreciar de forma clara que es lo que realiza.

No obstante, muchas veces este “cifrado” puede ser reversible o se puede inferir por el contenido. Otras veces no importa siquiera el contenido de dicha Cookie, y modificándolo a gusto se pueden obtener resultados igualmente satisfactorios.

Un ejemplo aplicado de esto fue usado por ejemplo en mi Artículo sobre Hammerfest, el cual por cierto tengo que rehacer. ¿Por qué fue necesario Cookie Spoofing para dicho artículo? Hammerfest es un juego Online que tan solo permite 3 cuentas máximas asociadas a un mismo PC. Si intentas crear una cuenta para jugar por encima de dicho número, el servidor te lo impedirá. Para poder hacer esto, el servidor tiene algunas opciones. Una podría ser verificando la IP, pero dado que la mayoría de las IPs son dinámicas, no serviría de mucho. La otra opción es por Cookies. El navegador cada vez que intenta acceder envía su cookie al site. El site coteja el ID de dicha cookie (por así decirlo) en su base de datos. Si ya tiene asociada a ella 3 usuarios no permite más. Aunque se elimine la cookie del navegador no ocurre nada, puesto que nada más conectarse el navegador especificará la cookie que usará (aunque esté vacía), la cual tiene el mismo ID, la cual será cotejada. ¿pero que sucede si cambiamos el ID de la cookie? El servidor pensaría que estamos desde otra máquina, almacenaría la nueva ID y nos daría acceso a otras 3 cuentas más para ser creadas.

En el ejemplo puesto, no es necesario siquiera conocer que tipo de ID está usando el servidor, con modificarlo por un valor arbitrario tendremos suficiente.

La importancia del Spoof de cookies tiene mayor importancia cuando conocemos la cookie de sesión de otro usuario, dado que si usamos sus datos para modificar la nuestra, podremos tener acceso a su sesión. Se puede pensar que es complicado conocer la cookie de otro usuario… pero no es complicado en realidad. Formas de obtener estos datos podrían ser mediante Snifers o XSS. En su momento veremos esto, pero por ahora vamos a verificar que puedo iniciar sesión en Internet Explorer en mi cuenta de Gmail sin pasar por el nombre de usuario y contraseña. Esto se puede hacer en dos fases. La primera “espiando la Cookie de Firefox y dirección una vez la cuenta está abierta, y en la segunda parte simplemente usar dicha cookie en IE. Recordar que la cookie en el PC no deja de ser un archivo, pero se especifica directamente en forma de datos en la misma etiqueta Cookie:

Cookie de Sesión y URL gMail

Evidentemente por motivos de seguridad he emborronado los datos propios. Aquí lo importante tan solo es la URL completa y la Cookie. Imaginar ahora que accedemos a IE, pegamos la URL que tenemos en gMail e interceptamos la Cookie enviada por IE y la modificamos por la que obtenemos en Firefox

Inserción Cookie en IE

Aunque pueda verse un error de certificado, esto no es importante. Dado que Gmail usa HTTPS, cualquier modificación en medio (como la realizada al cambiar la cookie) invalida el certificado. Pero si lo aceptamos, vemos como de forma mágica podemos acceder a gMail sin pasar por el nombre de usuario o contraseñas, ya que estos están embutidos de algún modo en la propia Cookie. Es cierto que quizás no seamos capaces de comprender el Hash usado por Google para proteger dicha información, pero no importa, simplemente copiando y pegando tenemos un resultado impecable.

Pensar no solo en las cookies de sesión. Pensar en que pasaría con aquellas cookies que usamos de forma persistentes. Es decir, podemos activar muchas veces las casillas de “Recordarme en cada Visita”, lo cual lo que realiza es que la Cookie usada no se invalida por cada sesión, sino que tiene a lo mejor una validez de una semana.

Sobre la modificación de Cookies que podamos inferir su contenido para especificar otro, será una cuestión que se abordará mejor cuando hablemos de Hashes.

 

Podríamos añadir muchos otros Spoofing dentro de las Cabeceras. Por ejemplo en todos los ejemplos mostrados se presupone que la utilidad es a la hora de los request, pero también puede ser útil modificar los response para producir en aplicaciones Flash por ejemplo un comportamiento completamente diferente. Por ejemplo imaginar que en un response se configuran los datos de una aplicación Flash para tener más vidas (en un juego). Modificando el response podríamos obtener más vidas.

Otra utilidad que se tiene es para modificar los datos enviados por el método POST al servidor. Con POST normalmente se especifican una serie de valores que son especificados en un formulario previamente. Pero muchas veces los valores que podemos introducir en el formulario son muy limitados en correspondencia a los que podríamos introducir directamente realizando Spoof a la cabecera. O por ejemplo pensar en formularios que dependiendo si los rellena un usuario u otro tiene más o menos campos, puesto que es posible que el sistema de procesarlos el servidor sea la misma forma. En dicho caso podríamos añadir “campos” extras con información arbitraria para obtener permisos administrativos por ejemplo u otros menesteres.