Craking Drupal

Craking Drupal es un libro que leí hace poco tiempo, pero que me enseñó muchas cosas y que hoy quiero compartir en este blog. El autor del libro, Greg James Knaddison , hace una reflexión bastante amplia de lo que es la seguridad en Drupal, de cómo se manifiestan los principales problemas y de las buenas prácticas para evitarlos. Aunque es imposible en un post resumir un libro tan amplio, trataré de hacer un resumen lo más concreto posible.

El primer punto es olvidarnos de la estúpida idea que existe en muchas personas que plantean “….no uso un CMS porque estos tienen problemas de seguridad….” Para mi esta es la expresión de un neófito que no tiene nada que decir. Los problemas de seguridad existen, se use un CMS o no, incluso es más probable que una persona cometa errores que repercutan en la seguridad de una aplicación Web si hace todo el trabajo desde cero que si usa una herramienta respaldada por una comunidad e incluso por importantes empresas del sector de las TIC.

Drupal por defecto provee un API que cubre los problemas más típicos de seguridad en la Web y los desarrolladores deben hacer uso de esta para que sus desarrollos sean lo más seguros posible. Cosa que no siempre se hace y que otras veces hacemos, pero que nuestra propia indisciplina como programador lleva a que se haga de forma inadecuada.

La seguridad parte de conocer lo que no se conoce, para poder enfrentar el problema e incluso saber donde podemos ser atacados.

La seguridad es un aspecto que involucra a todos los entes del sistema, En el caso de una Web con Drupal, el CMS no es el único problema que nos puede afectar la seguridad, también está la base de datos, la configuración de los servidores, las personas que intervienen en el proceso, las prolíticas y procedimientos de la entidad, en fin muchas cosas.

Drupal es un sistema bastante seguro, pero por supuesto que tiene sus debilidades. En el sitio Web de Drupal se recogen los problemas más comunes en el tema seguridad que han afectado a sistemas basados en Drupal. Los más comunes son el XSS, la escala de privilegios y el CSRF, luego hay otros, pero estos son el top 3. La mayoría de las veces los problemas se han presentado por mala codificación, por el uso de módulos contribuidos sin previo análisis de los mismos o por mala configuración del entorno de desarrollo.

Drupal es un sistema compuesto por un core que es muy seguro, pero para ampliar las funciones del CMS se usan muchas veces módulos contribuidos, antes de usar un módulo contribuido se debe hacer un previo análisis del mismo, se debe analizar cuanto se usa ese módulo y quienes lo usan, además hacer un análisis previo del código fuente y ver si cumplen con aspectos básicos como el uso correcto del hook_perm, hook_menu y hook_form, además la forma en que se usa la función t(), el chequeo de permisos y la forma en que se construyen la consultas SQL.

Ejemplos típicos de código inseguro vulnerable a xss:

drupal_set_message(t(“You just created the post: “. $node->title)); // vulnerable a XSS

Forma correcta de escribirla

drupal_set_message(t( “You just created the post: @title”, array(‘@title’ => $node->title)));

Ejemplo para prevenir la escala de privilegios

if (user_access(‘Algún permiso’))
{
// Este código se ejecuta solo si el usuario tiene el permiso ‘Algún prmiso’ asignado.
}

Los problemas de CSRF se ven principalmente por no usar el hook_form()

Ejemplo de mal uso de las funciones de acceso a datos

$term = db_result(db_query(“SELECT tid FROM {term_data} WHERE LOWER(’“. trim($term) .“’) LIKE LOWER(name)“));

Forma correcta de escribirla

db_query(“SELECT mail FROM {users} WHERE uid = %d“, $uid);

db_query_range(“SELECT mail FROM {users} WHERE name LIKE '%%%s%%’“, $string, 0, 10);

Bueno, pudiese estar escribiendo otras 200 páginas, pero al final la intensión es solo dejar la idea.