Hábitos de desarrollo [in]seguro

Introducción
Cuando realizamos una auditoría de seguridad de una aplicación Web, en la mayoría de los casos, detectamos muchos fallos que son de libro. Son fallos que se van a reportar y que quedan muy bien en el informe; Inyección SQL (SQLi) y/o Cross-Site Scripting (XSS). Muchos sabéis de lo que hablo.

Estos fallos se suelen cometer generalmente por desconocimiento, es decir, hay desarrolladores que no saben que existen estos problemas. Por otro lado, están los desarrolladores que pese a conocerlos, no aplican correctamente medidas de seguridad para prevenir estos ataques. ¿Motivos? Presupuesto, esfuerzo extra, etc. Generalmente limitado por el cliente.

De todos modos, creo que sería interesante enfocar también nuestra atención en la educación que han recibido. Ya sea en FP o en la Universidad, se debería hacer hincapié en el desarrollo seguro de aplicaciones. Por ejemplo, en mis días de universidad solo he escuchado decir al profesor lo importante que es optimizar recursos (y lo es, pero no es lo único).

Sin embargo, nunca he escuchado nada acerca de la seguridad en otra asignatura que no fuese Seguridad en Sistemas Informáticos. Pese a ser lógico para algunas personas, por ejemplo, ¿por qué no enseñar lo que es un desbordamiento de pila/búfer en la asignatura de programación y lo que esto implica? ¿Por qué no enseñar lo que es una inyección de código SQL?

¿Excesiva confianza?
Algunos problemas surgen cuando se confía en el framework que se está utilizando. Puede ser que en el momento de desarrollar la aplicación no exista ninguna vulnerabilidad conocida que afecte a este framework, pero nada impide que en un periodo de tiempo estas vulnerabilidades sean publicadas. Por lo tanto, si no se lleva un control de actualizaciones y se llevan a cabo las correspondientes modificaciones para que nuestra app no sea vulnerable, habremos fallado.

Por otro lado, y en la mayoría de los casos, ocurre que se desarrolla una aplicación sin pensar en los “casos de abuso”. Es decir, se confía demasiado en que el usuario va a introducir correctamente todos los datos, y se confía en que se producirá el comportamiento esperado. Sin ir más lejos, tenemos el claro ejemplo del síndrome de la comilla con el que se detectan muchas vulnerabilidades de inyección SQL.

Casos prácticos
Para no explayarme mucho, quiero dejar unos ejemplos prácticos para que los nuevos desarrolladores los tengan en cuenta para sus nuevas aplicaciones, sobre todo aplicaciones Web ya que voy a remarcar el problema de las Inyecciones SQL.

Dada una aplicación web que muestra información de comentarios escritos por otros usuarios, vamos a ver dos ejemplos en los que saltarán a simple vista dos errores, SQLi y XSS.

¿Y Si vamos un paso más allá y probamos un Cross-Site? Vamos a ello…

Ahora vamos a echarle un vistazo al código:

< ?
$idAutor = mysql_real_escape_string($_GET['idAutor']);
$con = mysql_connect('localhost','testUser','testPassword');
$db = mysql_select_db("test");
$query = "SELECT * FROM comentarios WHERE autor = " .$idAutor;
$resultado = mysql_query($query, $con);
echo "Id Autor: ".$idAutor;
$row = array();
while ($row = mysql_fetch_array($resultado)) {
  echo "
Comentario: 
".$row['cuerpo'];
}
?>

Como habéis podido observar, se hace uso de la función “mysql_real_escape_string()”. Este error es muy común ya que muchas personas creen que es suficiente para evitar una inyección SQL. Además, se puede ver dónde está la inyección de código HTML/Script cuando se hace el “echo” de idAutor.

Si además seguimos indagando en el código, vemos que tampoco se hace un uso correcto de la conexión a la base de datos, lo que además acarreará problemas de rendimiento.

Conclusiones

Tal como hemos remarcado, muchas personas no conocen los peligros a los que se enfrentan a la hora de publicar una aplicación, en este caso, Web. Es muy importante que a los nuevos desarrolladores se les informe acerca de estos problemas en cursos específicos de un lenguaje de programación concreto, en FP, en la Universidad… Al fin y al cabo, como otras tantas cosas, todo empieza por la educación. ¿No?

No se trata de forzar a que todo el mundo aprenda a evitar este tipo de ataques, sino más bien, que tengan unas nociones mínimas y que sepan a lo que están expuestos. Se trata de tener buenos hábitos, inculcados por los formadores.

Para terminar, decir que este desconocimiento por parte de los desarrolladores, hace que no se traslade al cliente la importancia de implementar mecanismos de seguridad adecuados o de implementarlos en los correspondientes proyectos a desarrollar.