Variables Foo y Bar

Es habitual encontrar como nombres de variables sobre todo en tutoriales y demás los famosos foo y bar, pero de verdad alguien se ha preguntado alguna vez ¿de donde viene ese nombre?

Pues la respuesta es cuando menos curiosa. Básicamente parece que el nombre de las variables foo y bar viene de un expresión de la Segunda Guerra Mundial y proviene de la expresión FUBAR (Fucked Up Beyond All Recognition / Repair / Reason / Redemption).

Lo bonito es la de veces que se emplean estos nombres incluso en publicaciones de cierto prestigio. En fin, una curiosidad más del mundo informático, donde las bromas pueden estar implícitas en cualquier expresión.

Además por si fuera poco, he encontrado un grandioso RFC 3092 que se encarga de definir ambos términos y tiene un listado de su uso en los distintos RFC que existen.

Esto me recuerda al también famoso RFC 1149, que define como enviar paquetes IP utilizando palomas como medio de transporte 🙂

Actualización:

Siguiendo con los RFC, acabo de encontrar la actualización del RFC de IP sobre palomas. Es el RFC 2549 e introduce el concepto de QoS (Quality of Service).

Nueva Categoría: Programación

Nueva categoría que incorporo al blog para tratar temas que esten relacionados con la programación ya sea sobre lenguajes de programación, herramientas, entornos de desarrollo o cuestiones relacionadas.

XSS: Cross Site Scripting – ¿Cómo se hace?

En un post anterior, introducía los ataques de XSS, en este post comentaré algunas de las formas más habituales de realizar los ataques.

¿Cómo se hace?
Básicamente como en casi todos los ataques, la cuestión radica en encontrar alguna vulnerabilidad en el servidor objetivo. El término vulnerabilidad, para el que este familiarizado con temas de seguridad, es una forma de denominar puntos del sistema que tienen un nivel de seguridad inferior a los de su entorno. Así por ejemplo, podríamos pensar que si un servidor es una prisión de máxima seguridad, una vulnerabilidad podría ser una ventana sin rejas y completamente abierta todo el día.

En cuanto a las formas más comunes de efectuar ataques XSS, encontramos:

• SQL Injection: Quizá uno de los términos más famosos, básicamente hace referencia a la inyección de código SQL. SQL es un lenguaje para la utilización de bases de datos. Permite añadir, modificar y eliminar información.
  
  Se puede utilizar esta técnica cuando se prevee que un campo dentro de una página interviene dentro de alguna consulta en la base de datos. A modo de ejemplo, si suponemos un escenario con una página de login, por ejemplo, gmail.com; es lógico pensar que cuando ponemos nuestro nombre de usuario («usuario») y contraseña («contraseña»), el servidor tendrá que preguntar a la base de datos:

  SELECT identificador
FROM usuarios
WHERE username = 'usuario'
AND password = 'contraseña’

  En este escenario si no se comprueba que el nombre de usuario y la contraseña no sean sentencias SQL se podría escribir como contraseña password’ OR ‘x’=’x’, con lo que la consulta a la base de datos sería:

  SELECT identificador
FROM usuarios
WHERE username = 'usuario'
AND password = 'password' OR 'x'='x'

  Con esto se consigue acceder al sistema únicamente conociendo el nombre de usuario, ya que la condición de si X es igual a X siempre se cumple.

• HTML Injection: Al igual que ocurre en el ataque anterior, se puede utilizar la inyección de código HTML cuando se prevee que el dato que se introduce en algún campo del un formulario o parámetro de la web será mostrado en la página resultado. A modo de ejemplo, la forma más básica de comprobar si un buscador es susceptible a XSS por inyección de HTML es introducir en la casilla del buscador:

  <strong>test</strong>

  Si el buscado muestra en la página de resultados algo así como:

  Resultados para <strong>test</strong>
  o
  Resultados para test

  no es probable que sea susceptible a este tipo de ataques, si por el contrario muestra
  Resultados para test
  es muy probable que el servidor sea susceptible a este tipo de ataques.

• Eliminación de restricciones: Verdaderamente, este punto esta quizá en límite de lo que mucha gente consideraría un ataque de XSS por sí solo, pero al menos es complementario para poder llevar a cabo los anteriores.
  
  Básicamente, el ataque consiste en eliminar restricciones impuestas por la programación de una página web, siempre y cuando estas restricciones se lleven a cabo en el cliente. Es decir, se llevan a cabo en nuestro navegador.

  Existen muchas páginas que la validación de ciertos parámetros se lleva a cabo mediante lenguajes tipo JavaScript con el fin de por ejemplo evitar que un campo de un formulario este en blanco, que la fecha sea válida o que una cantidad sea válida.

  Dentro de la formas de explotar esta vulnerabilidad se pueden encontrar dos tipos. Se puede modificar en «tiempo real» una página web, para por ejemplo sobreescribir una función de validación y siempre de un resultado positivo. O por otro lado, se puede capturar una petición válida al servidor, modificarla a nuestro gusto y volverla a enviar.

Tengo que decir, que los puntos anteriores no profundizan mucho en los distintos ataques, con el fin de poder explicar para alguien no muy familiarizado con el tema en qué consisten estos ataques. Espero en un futuro dedicar un post o serie de post más decentes a explicar con mucha mayor profundidad estos tipos de ataques. Pero como comienzo, creo que no estan mal 🙂

En el próximo capítulo, ¿Cómo evitarlo?

Ahhh y viñeta que espero ahora entienda más gente de xkcd:

Referencias:

1. XSS: Cross Site Scripting – Introducción
2. XSSed: Archivo con ejemplos de ataques reales a distintos servidores vulnerables a Cross Site Scripting