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.

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";

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

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.

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();	

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

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].

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
	

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

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.

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'] <= 2147483647)
	

Subida y ejecución de scripts maliciosos.

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.

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";
	

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

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.

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;
	

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

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.

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:
<div>
<a href="https://twitter.com/share" class="twitter-share-button" data-count="horizontal" 
data-via="misitio" data-lang="es">Tweet</a>
<script type="text/javascript" src="//platform.twitter.com/widgets.js"></script>
</div>

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

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