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.

Ilustración 1: Salida por defecto.

Ilustración 2: Inyección SQL básica.

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

Ilustración 3: Cross-Site Scripting.

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.

Comments

  1. http://Gamaliel says

    Lo que no entiendo es por qué dices lo de problema de rendimiento en la conexión.

  2. http://Gamaliel says

    Lo dices por no ser mysqli? Por usar fetch_array en lugar de fetch_assoc? Por no referencias la conexión al seleccionar la base de datos?

  3. http://Marcos says

    Hola,

    en temas de optimización no estoy al día pero voy a intentar aclararte las dudas.

    Por un lado, efectivamente tal y como comentas, usar la extensión de mysqli reduce el tiempo de acceso a los datos, entre otras mejoras con respecto a mysql.

    Por otro lado, hasta lo que tengo entendido, estás en lo cierto con lo de usar fetch_array en lugar de fetch_assoc. El hecho de usar fetch_array utiliza más memoria que fetch_assoc, siempre y cuando no se le especifique a fetch_array, como parámetro, la opción MYSQL_ASSOC o MYSQL_ENUM. Corregidme si me equivoco.

    En el post no se ha detallado el problema de la optimización por no ser la temática principal del mismo.

    Un saludo y gracias por el comentario.

  4. http://Gamaliel%20Espinoza says

    Creo que tienes razón, el tema no es la optimización, nada más lo mencioné por un solo párrafo.

    Lo del ASSOC si se puede dando el parámetro, pero lo encuentro más fácil con la función mysql_fetch_assoc.

  5. Pues este problema está demasiado extendido hoy en día, se ven vulnerabilidades XSS y SQLi día tras día y parece que a nadie le importa resolver el problema de raíz, más allá de poner parches.

  6. hola como hacemos para parchar una variable vulnerable a sqli o una blind sqli ? osea para validar la consulta y no haya inyeccion de codigo ? es posible poner un antes y depues

Trackbacks

  1. […] 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…  […]