Sugerencias de Seguridad para Sitios Web

13/06/2013

 

Objetivo

Sugerencias breves y claras para mejorar la seguridad en aplicaciones web[1].

Filtrado de entradas

Al considerar la seguridad de una aplicación, no se debe confiar en las entradas proporcionadas por los usuarios. Se pueden realizar validaciones tanto del lado del cliente utilizando JavaScript como del lado del servidor por medio de rutinas del lenguaje de programación).

Es muy importante siempre llevar a cabo la validación de los datos del lado del servidor ya que las validaciones del lado del cliente pueden ser sobrepasadas o incluso desactivarse.

Implementación

Para filtrar los datos proporcionados por el usuario del lado del servidor, se recomienda el empleo de listas blancas, las cuales pueden generarse a partir del empleo de expresiones regulares.

Ejemplo. Para guardar la edad de un usuario, se tiene la siguiente expresión en la que se asigna directamente el valor obtenido de un formulario a una variable:

$edad=$_POST['edad'];

Si el dato no se valida correctamente, pueden ingresarse cadenas de código malicioso para obtener información de la aplicación o de sus usuarios. A continuación se presenta una alternativa para su validación:

$edad_recibe = $_POST['edad'];
$regexp_edad = '^[0-9]{1,2}$';
$edad_valida = preg_match($regexp_edad,$edad_recibe);
if($edad_valida)
	$edad = $edad_recibe;
else
	$error = "se debe ingresar una edad entre 0 y 99";

 

Riesgos de implementación inadecuada

En caso de no validarse correctamente las entradas, se corre el riesgo de SQL Injection[2], XSS y/o CSRF.

Manejo de sesiones

La implementación de sesiones permite dar seguimiento al usuario, permite mantener valores de variables a través del sitio (sin tener que emplear campos ocultos en formularios), así como restringir el acceso a determinados elementos.

Es muy importante dar seguimiento a la sesión, así como iniciarla y terminarla de forma correcta, para evitar su posible secuestro.

Implementación

Establecer el uso de sesiones en el lugar en el que el usuario comienza la interacción "restringida" con la aplicación. Darle seguimiento verificando que la sesión siga activa en cada elemento visitado para su visualización, en caso contrario, redirigir al usuario a iniciar la sesión. Cuando el usuario terminó de visitar el sitio, la sesión debe cerrarse.

Ejemplo.

// Inicio de sesión al comienzo del archivo:
session_start();
// Después de iniciar sesión, se pueden asignar valores y variables:
$_SESSION['existe_sesion'] = 'si ';
// Verificación básica en las páginas restringidas:
if(!isset($_SESSION['existe_sesion']))
	header("Location: /index.php");
// Cierre de sesión:
session_destroy();	

Riesgos de implementación inadecuada

Acceso a recursos restringidos, robo de identidad de otro usuario, mal uso de los recursos de la aplicación.

Registro/manejo de datos de usuario

Al manejar datos privados o importantes de los usuarios se debe contar con protección adicional como el cifrado del canal de comunicación para el intercambio entre cliente y servidor.

Es muy importante mantener seguros los datos proporcionados por los usuarios, tanto al inicio de sesión (login, password) como al registrarse en formularios (nombre, apellidos, dirección, correo electrónico, teléfono, etc.)[3].

Implementación

Establecer el uso del protocolo HTTPS[4] mediante la instalación de un certificado en el servidor de aplicaciones web. Configurar el servidor para su empleo ya sea en el sitio principal o por cada virtual host.

Ejemplo.

# En la configuración del servidor web activar la opción de uso de SSL:
SSLEngine	On
SSLProtocol	all -SSLv2
# Indicar la ubicación del certificado:
SSLCertificateFile	/etc/ssl/certificados/server.crt
SSLCertificateKeyFile	/etc/ssl/certificados/llaves/server.key
	

Riesgos de implementación inadecuada

Intercepción del tráfico de red puede mostrar información sensible en tránsito (man in the middle).

Subir archivos

Contar con la opción de colocar archivos en alguna carpeta dentro del servidor puede accidentalmente provocar que se suba algún archivo malicioso que puede afectar a la aplicación o al servidor mismo.

Es muy importante restringir el tipo y tamaño de archivos que pueden subirse al servidor, así como restringir la ejecución de scripts en la ubicación en la que los archivos se van a colocar.

Implementación

Es necesario llevar a cabo distintas verificaciones con la finalidad de que los archivos que se suban al servidor cumplan con los requisitos establecidos previamente.

Ejemplo:

// Verificación del tipo de archivo (MIME):
if(preg_match(‘image/’,$_FILES['archivo']['type']))
// Comprobar la extensión del archivo:
if(preg_match(‘^\.(jpg|png|bmp|jpeg)$’,$_FILES['archivo']['name']))
// Comprobar el tamaño del archivo:
if($_FILES['archivo']['size'] 

Riesgos de implementación inadecuada

Subida y ejecución de scripts maliciosos.

Configuración de errores

Cuando se implementa un sitio mediante un gestor de contenidos, o bien al tener un desarrollo a la medida se pueden configurar los mensajes de error que se muestran a los usuarios para evitar que vean información del sitio.

Es muy importante considerar la forma en la que la aplicación puede llegar a fallar sin mostrar información a los usuarios, a esto se le conoce como fallo seguro.

Implementación

De acuerdo al gestor de contenidos, existen opciones de configuración sobre los mensajes de error que se mostrarán a los usuarios (recurso no encontrado, no existen coincidencias de la búsqueda, etc.). En el caso del desarrollo propio, se pueden considerar mensajes genéricos de error en caso de ser necesario.

Ejemplo. Primero se configura la directiva en el servidor de aplicaciones web para mostrar la página de error:

# Dentro de la configuración del servidor web se incluye esta directiva 
# para mostrar una página personalizada si la página solicitada no existe:
ErrorDocument	404 /error.php

Y en el archivo error.php se incluye el mensaje a mostrar:

// Mensaje de error:
echo "El recurso no está disponible";
	

Riesgos de implementación inadecuada

Exposición accidental de información de instalación y configuración del sitio (versiones, software empleado, rutas del sistema, entre otros).

Almacenamiento de información (Bases de datos)

La información es el elemento más importante que se maneja por las aplicaciones web, por lo que se debe proteger.

Es muy importante tomar las medidas necesarias para disminuir el acceso de personas no deseadas a la información manejada por la aplicación.

Implementación

El servicio de bases de datos debe configurarse de forma segura haciendo hardening a la configuración, evitar usuarios, contraseñas y configuraciones por defecto.

Ejemplo .

--Al instalar un manejador de bases de datos, crear un usuario que sea 
--el dueño de la base de datos y sólo pueda tener acceso a ella:
postgres=# create user aaguilar encoding password ‘secreto1’;
postgres=# create database pruebas1 owner aaguilar;
	

Riesgos de implementación inadecuada

Extracción o modificación de información de la base de datos (del servicio y del contenido).

Contenido de terceros

En varios casos es necesario que la aplicación emplee funcionalidad o incluya contenido de terceros (módulo de validación, calendarios, autenticación con oauth, conexión con twitter o facebook entre otros), en este caso es necesario investigar sobre las vulnerabilidades existentes para dicho contenido.

Es muy importante emplear, sólo en caso necesario la mínima funcionalidad correspondiente y no instalar contenido o funcionalidad que no se vaya a emplear.

Implementación

En el caso de instalar bibliotecas, módulos o funcionalidad extra por parte de terceros, es conveniente instalar la última versión estable y que cuente con las actualizaciones de seguridad correspondientes.

Ejemplo .

//Uso de twitter en el sitio principal para compartir una nota:

Riesgos de implementación inadecuada

Dependerá del tipo de vulnerabilidad del contenido, pero puede incluir XSS, CSRF, SQL Injection, robo de sesión, escalada de privilegios, entre otros.

[1]Algunos ejemplos en PHP y Apache.

Referencias

1. Aspectos básicos de seguridad en aplicaciones web:

http://www.seguridad.unam.mx/documento/?id=17

2. Validación de entradas:

https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet

3. Autenticación de usuarios:

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

4. Prevención de SQL Injection:

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

5. Protección de la capa de transporte:

https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

6. Revisión general de seguridad a sitios web:

https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet

7. FAQ de seguridad:

http://www.seguridad.unam.mx/documento/?id=14

Liberación original: Jueves, 13 Junio 2013
Última revisión: Viernes, 25 Abril 2014

La Coordinación de Seguridad de la Información/UNAM-CERT agradece el apoyo en la elaboración y revisión de este documento a:

Angie Aguilar
Andrés Hernández

Para mayor información acerca de este documento contactar a:

UNAM-CERT: Equipo de Respuesta a Incidentes UNAM 
Coordinación de Seguridad de la Información 
Dirección General de Cómputo y Tecnologías de Información y Comunicación 
Universidad Nacional Autónoma de México 
E-Mail: incidentes@cert.unam.mx 
http://www.cert.org.mx
http://www.seguridad.unam.mx
ftp://ftp.seguridad.unam.mx
Tel: 56 22 81 69