Monografía sobre los principios de seguridad web.

La seguridad web pasiva son aquellas medidas para crear nuestra aplicación sin necesidad de intervención humana. Debe ser segura por defecto. Cualquier estado de error no debe proporcionar inseguridad. Deberemos tener cuanto menos puntos de entrada mejor, minimizando oportunidades de acceso o ataque.

La seguridad activa web son acciones manuales para aumentar la seguridad del sistema. Por ejemplo, una revisión buscando brechas de seguridad. Se podrán comprobar las vulnerabilidades y crear auditorias. La realización de copias de seguridad es vital para poder recuperar datos.

Intentaremos mantener siempre el principio de simpleza en el desarrollo web. Existen multitud de elementos a comprobar porque existen multitud de elementos de ataque.

El principio de Pareto o la regla del 80-20 aplicada a seguridad web, indica que no todos los ataques tienen el mismo tipo de distribución.
Con el 20% de la prevención se puede detener el 80% de los posibles ataques.

La seguridad web evoluciona en el tiempo. Todos los días surgen ataques y nuevas maneras de acceder de forma no autorizada. Tendremos que estar actualizados e informados constantemente. Deberemos restringir el número de accesos abiertos en el servidor para disminuir las probabilidades de que nuestra web o desarrollo sea atacado.

Atendiendo a los lugares de acceso, existen 3 puntos posibles de ataque.

• Desde el propio lugar de acceso. El cliente. Cada copia que se envía a un navegador web, es una posibilidad de entrada. Es la aplicación HTML que ha sido descargada del servidor al navegador. Esta aplicación representa muchas oportunidades de entrada. Por ejemplo los formularios y las URLs son sistemas muy empleados de ataque. Las cookies puede ser leídas. La propia lógica de aplicación puede ser atacada. Javascript es un lenguaje visto, puede ser ofuscado, pero es un lenguaje analizado.
• El servidor posee más control. Puede disponer de múltiples servicios y puertos abiertos. El servidor FTP, Telnet, Terminal Server, SSH, VNC, el servidor de base de datos, etc. Necesitaremos restringir el número mayor posibles de accesos a estos servicios.
• La red existente entre el cliente y el servidor. Esta red posee múltiples nodos intermediarios. Pueden existir sniffers o software de escucha. Es por ello que es preciso encriptar la información.

La seguridad web total no existe. Pero aunque sea un requisito muy lícito establecido por un cliente en una memoria de proyecto, la seguridad total sólo existe en teoría. Es un ideal. Imposible de cumplir en su totalidad. No obstante es un objetivo que “intentaremos cumplir”.

Similar al SEO, nadie puede garantizar al 100% el SERP de una página.

Existen una serie de consejos o prácticas para asegurar la aplicación.

Una de las más importantes es cerrar las puertas no necesarias. Intentar cerrar servicios o partes donde se puede acceder al interior. Cerrando puertos, cerrando servicios web, actualizando el sistema, módulos, plugins, el sistema operativo, la versión del servidor web, servidor SQL, etc. Es preciso intentar disponer de la mayor parte de servicios actualizados.

Esto suele ser un gran problema para algunos desarrolladores, porque precisarán la reprogramación de ciertas partes del programa. No todas las actualizaciones permiten que nuestro software siga funcionando correctamente.

La seguridad en el cliente, dependerá también de que sus contraseñas o accesos sean complejos, se cambien de forma periódica, etc.

Si como programadores ofuscamos el código del lado del servidor, y el más inseguro del lado cliente, estaremos yendo en contra de los programadores al no permitir la reutilización, entendimiento y refactorización. Por lo tanto muchas veces tendremos que elegir entre ambos criterios dependiendo de la seguridad de la aplicación. Este criterio dependerá de la aplicación y de la situación.

INPUTS y OUTPUTS de información web.

Las entradas son partes de un sistema en las que un usuario puede introducir información. Serán usaras mayormente para realizar ataques.

Por ejemplo, los formularios web, encuestas, registros, etc, son elementos de ataque de entrada.

Mediante los OUTPUTS el programa se comunica con los usuarios. Esto nos permitirá mostrar información, por ejemplo mediante inyecciones URL ó SQL.

Las entradas permiten adaptar el comportamiento de la aplicación web. Pero como he comentado, las entradas tienen sus peligros. El contenido de una entrada pasa desde el lado humano hacia el interior del programa. El contenido de un formulario puede ser tratado por el programa o por la base. Posibilitaran realizar inyecciones que alteren la base de datos o el programa.

Por lo que es necesario realizar validaciones en las entradas de los formularios, el HTML debe ser tratado y preprocesado. Podremos escapar cadenas para evitar insertar instrucciones de código.

Las salidas son partes donde el programa devuelve información en pantalla o consola del navegador. La información puede contener mensajes del sistema o mensajes de depuración. Un atacante puede aprovechar estos mensajes para sacar conclusiones y usarlos en nuestra contra.

Blacklist y Whitelist

Un Blacklist es una lista negra de elementos. Elementos prohibidos del sistema. Podremos acceder a esta lista para comprobar que no existe código fuente no permitido. Las cadenas de entrada se pasarán a través de esta matriz para comprobar su validez.

De forma contraria existe la lista de elementos permitidos. Estas listas por ejemplo nos posibilitan tener todas las palabras reservadas por ejemplo DDL o DML de SQL. En otros casos también pueden existir diccionarios.

En estas listas también pueden existir usuarios para acceder o denegar sus accesos. En definitiva son técnicas para aumentar o blindar la seguridad web.

Registro de eventos en nuestra aplicación.

Es un sistema de seguridad indirecto. Permite que la aplicación almacene datos de sus estado (puede ser una base de datos). Puede ser recuperada en caso de fallo, para averiguar las causas del mismo. Este tipo de eventos los tendremos que almacenar nosotros en la lógica de nuestra aplicación. Podemos almacenar la IP del usuario, la hora, fecha, navegador con el que ha conectado, el tiempo de ejecución, página accedida, etc.

Registro de eventos en el servidor. Dependiendo del servidor que empleemos dependerá el almacén. Si empleamos IIS o Apache, SQL Server o Mysql, PHP o ASP.NET, el tipo de conexión FTP o SFTP. El servidor se podrá encargar de almacenar estados, IPs, usuarios, puertos remotos, etc.

Tipos de ataques más comunes en la web.

Existen multitud de ellos, cada uno de ellos aprovecha una debilidad. Cada vez surgen nuevas vías. Vamos a ver las más comunes, sólo los más comunes.

Ataque XSS

Cross Site Scripting. Para evitar confundirlo con la tecnología CSS.

Su funcionamiento inyecta código no deseado en el lenguaje Javascript. Puede encontranrse también en el lado del servidor. Ejecuta partes no autorizadas o el nuevo código inyectado.

https://es.wikipedia.org/wiki/Cross-site_scripting

Inyección SQL

https://es.wikipedia.org/wiki/Inyecci%C3%B3n_SQL

Insertaremos una sentencia SQL en una entrada. Será necesario escapar el comando con el que estamos trabajando.

La Inyección SQL es un tipo de vulnerabilidad,  método de infiltración, que incrusta código SQL intruso.

Se dice que existe o se produjo una inyección SQL cuando, de alguna manera, se inserta o «inyecta» código SQL invasor dentro del código SQL programado, a fin de alterar el funcionamiento normal del programa y lograr así que se ejecute la porción de código «invasor» incrustado, en la base de datos.

Ataque por fuerza bruta

Este tipo de ataques consiste en probar múltiples combinaciones en una entrada, con el propósito de averiguar la contraseña de acceso.

https://es.wikipedia.org/wiki/Ataque_de_fuerza_bruta

Ataque con cookies.

Son pequeños paquetes de información persistente que residen en el navegador. Existen cookies por sesión y otras permanentes de aplicación con una fecha de caducidad más larga que se quedan en el navegador aunque se finalice la navegación.

Una cookie puede almacenar gustos, datos de usuario, para personalizar la experiencia de usuario. Recordemos la publicidad que nos suele aparecer cuando navegamos.

El peligro de las cookies es que son fácilmente manipulables. Se puede leer, escribir, etc.

Ocurren en el lado del cliente, donde no tenemos ningún control. Debemos evitar usar las cookies para almacenar información sensible.

https://es.wikipedia.org/wiki/Cookie_(inform%C3%A1tica)

Manipulación de la URL.

Muchas aplicaciones pasan parámetros mediante la URL por el protocolo HTTP mediante GET. Los parámetros GET son fácilmente editables. Al modificarlos podemos cambiar el comportamiento de la aplicación.

Fallas en CMS como wordpress, drupal, joombla y en sus plugins.

Muchos desarrollos web se basan en estas aplicaciones. Poseen fallos de seguridad que afectan a millones de webs. No solamente estos CMS sino sus extensiones o plugins que aportan funcionalidad extra.

Como medida adicional es altamente aconsejable el cifrado de datos y la encriptación. Puesto que los datos viajan del cliente hacia el servidor.

Al margen de las vulnerabilidades web, existen varias formas de codificación. Existen varios mecanismos para ello y evitar que sean interpretados los datos al ser capturados.

Mediante el cifrado ocultamos el contenido del mensaje. Mediante un algoritmo de cifrado se cifran los datos usando una clave. Pero al estar cifrados un atacante no “podría interpretarlos”. En destino se aplica el algoritmo inverso y se obtiene el mensaje original. La clave de cifrado debe ser guardada en secreto. Esta clave debe tener un nivel de fuerza alta, para evitar que sea difícil de descifrar. El acto de cifrado consume recursos de sistema. El cifrado va en contra de la eficiencia en los recursos hardware. La seguridad en determinadas ocasiones va en contra de la eficiencia. Es necesario buscar el equilibrio.

Por ejemplo en php:

$mensaje=Base64_encode(“El mensaje”) // Codificamos

Base64_decode($mensaje) // Decodificamos

La encriptación o hashing mediante un algoritmo de hash o encriptación, toma los datos originales y los cifra, obteniendo una cadena indescifrable. En destino se recibe el mensaje encriptado, se obtiene un valor a comparar, se encripta dicho valor y se comparan las cadenas.

El uso típico de este cifrado sin retorno es codificar información como contraseñas, se compara el hash de la contraseña. Es el motivo por el cual ninguna web actual te da la contraseña si la has olvidado. En muchos lenguajes podemos realizarlo con la función MD5. Es un algoritmo que devuelve el mismo resultado.

Por ejemplo, la base de datos almacenaría la contraseña cifrada en MD5 y se compara.

If (md5($contrasena) == “Cadena de hash”)

                Echo “existe coincidencia”

Gracias a esto, si un atacante accede a las password, no le serviría de nada porque se encuentran codificadas.

La seguridad web se ve afectada por la seguridad de los servidores. Independientemente de que sean Windows, Linux o Mac, deben ser actualizados periódicamente. Pero ojo, el comportamiento web de un sistema puede variar al ser actualizado. Por lo tanto, las actualizaciones del sistema se gana en seguridad, pero ciertas partes pueden dejar de funcionar.

Esto es aplicable a actualizaciones de los CMS. Si actualizamos el wordpress, puede que un determinado tema o plugin deje de funcionar. Es por ello, que actualmente, existen 2 versiones en los temas, una padre y otra hija. Las modificaciones se realizan en la hija, para que cuando se actualice la parent no se pierdan las modificaciones de la child.

El software que corre el los servidores también debe ser actualizados. Las aplicaciones instaladas pueden ser la pila

LAMP

Linux, Apache, MySQL y PHP. Estos 3 elementos deben ser actualizados y modificados. Suele ser el más extendido a nivel mundial.

Otras alternativas son Windows + .NET y servidor SQL Server.

Una tercera configuración es Linux + J2EE, servidor Linux o Windows + Apache Tomcat y bases de datos como Oracle, MySQL, PostgreSQL, etc

Muchos administradores gestionan sus servidores con paneles de control administrables como CPANEL, Plesk, etc. Gracias a estos, se puede configurar “fácilmente” aspectos de la máquina y ganar tiempo. Pero ojo, también tienen sus vulnerabilidades y necesitan ser actualizados.

Otro ejemplo de seguridad aplicado a servidores, es el relacionado con los servidores de datos. Muchas veces, tendremos abierto el puerto externo para conectar con la base, siendo innecesario ya que lo podremos realizar en localhost.