Esquema general de pasos a seguir para la detección de posibles riesgos y vulnerabilidades. Se incluyen algunas recomendaciones generales.

Artículo relacionado: Valoración de riesgos tecnológicos

Basado en la guía de pruebas de OWASP (Open Web Application Security Project).

Índice

Obtención pasiva de información
Lógica de la aplicación
Pruebas de autentificación
Gestión de sesiones
Validación de los datos
Riesgos referentes a ataques de denegación de servicio
Servicios Web
AJAX (Asynchronous JavaScript and XML)

Obtención pasiva de información:

Descubrimiento de aplicaciones:

• Detectar puertos abiertos e identificar servicios/aplicaciones escuchando (según su “fingerprint”)

  • nmap –P0 –sT –sV –p1-65535 192.168.1.100

• Información proporcionada por servicios web.

  • telnet XX.XX.XX.XX 80

  • GET / HTTP/1.0

Códigos de error:

• Provocar errores “HTTP 404 – Not Found” para obtener información adicional, por ejemplo:

  Not Found

  The requested URL
  /page.html was not found on this server.

  Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at localhost Port 80

Vulnerabilidades de los servicios:

• Comprobar que no existen vulnerabilidades en las versiones de las aplicaciones descubiertas.

  Comprobación de la validez de certificados SSL:

• Si se están utilizando conexiones seguras mediante HTTPS, comprobar el certificado del servidor según los siguientes puntos:

  • Quien firma el certificado.

  • Fecha de validez (comprobar que no ha caducado)

  • ¿El nombre del certificado corresponde al sitio que estamos accediendo?

  Acceso directo a los sistemas de almacenamiento de datos:

• ¿Es posible acceder a los sistemas de almacenamiento mediante otra aplicación diferente a la interfaz web?

• De ser así, ¿es posible conectar con los mismos usuarios/passwords de la interfaz web?

• De ser así, ¿los usuarios mantienen las mismas restricciones sobre la información tanto si trabajan sobre interfaz web como directamente sobre los datos?

  Ficheros/Directorios no referenciados, backups o tests antiguos:

• Identificar posibles ficheros antiguos, backups o tests comentados en el HTML retornado por el servidor.

• Deducir esquema de nombres de las URL

  • Por ejemplo, si tenemos acceso a “/app/user”, quizás también exista “/app/admin”

• Comentarios del código HTML retornado por el servidor.

  • Código HTML comentado

  • Código JavaScript que muestra elementos en función del tipo de usuario (e.g. si el usuario es administrador, mostrar el formulario X)

  • Formularios HTML con botón submit oculto (posibles antiguos tests)

  • Fichero “/robots.txt”

• Comprobar si existen ficheros con extensiones como “.old”, “.bak”, etc…

Lógica de la aplicación:

• Comprender la aplicación mediante manuales, análisis de requerimientos, especificaciones funcionales, etc…

• Creación de información para realizar tests lógicos

• Desarrollar pruebas:

  • Secuencias de uso no lógicas

  • Introducción de datos incorrectos (números negativos, letras en campos numéricos, etc…)

Pruebas de autentificación:

• Usuarios por defecto o fácilmente deducibles.

  • Por ejemplo: “admin.”, “administrador”, “root”, “system”, “test”…

• Posibilidad de evitar el proceso de autentificación.

  • Cambiando la URL

  • Cambiando parámetros GET o POST

  • Cambiando valor de cookies

  • Predicción de la sesión (si esta es secuencial, podríamos “robar” sesiones)

  • SQL Injection

• “Directory Traversal”

  • Identificar cookies y parámetros GET o POST cuyo valor pueda ser utilizado para abrir y mostrar ficheros (e.g. http://example.com/index.php?file=content) e intentar asignar valores como “../../etc/passwd”

Gestión de sesiones:

General:

• Cuestiones generales:

  • ¿El ordenador utilizado para acceder a la web es de uso compartido?

  • ¿Cuantas sesiones concurrentes puede tener un usuario?

  • ¿Cuál es el timeout de desconexión por inactividad?

  • ¿Las sesiones están asociadas a IPs?

  • ¿Existe la funcionalidad “recordar mi usuario”?

• ¿El identificador de sesión se guarda en una cookie, como parámetro GET (en la URL) o como parámetro POST (en formularios)?

• Analizar la aleatoriedad del identificador de sesión (e.g. ¿números son secuenciales? ¿se asigna un identificador diferente después de cada autentificación?)

• ¿El identificador de sesión es siempre transportado por un canal seguro?

• ¿Las cookies tiene asignada una fecha de expiración?

• ¿Qué otras cookies establece la aplicación?

Cross Site Request Forgeries (Session riding):

• Una web externa puede contener un enlace oculto (por ejemplo en un tag IMG) que provoque una acción determinada en otra web (http://ejemplo.com/borrar?todo=true) donde el usuario este identificador. El atacante debe conocer la URL que provoca la acción.

• En aplicaciones internas de empresas, este ataque puede ser realizado por compañeros o ex-empleados.

• Comprobar si la aplicación web puede verse afectada por esta situación.

• ¿Todas las acciones requieren confirmación?

• ¿La aplicación añade información relacionada con la sesión en la URL para evitar este tipo de ataques?

• ¿Utiliza métodos POST en las acciones que realizan modificaciones sobre datos? (Aunque también es posible simular mediante javascript por el atacante, es una medida de contención)

• ¿La aplicación comprueba el Referer? (Aunque el atacante también podría manipularlo o hacer que no existe utilizando iframes)

Validación de los datos:

Cross Site Scripting (XSS):

• Un ataque XSS puede ser llevado a cabo mediante: HTML, JavaScript, VBScript, ActiveX, Flash, y otros lenguajes del lado del cliente.

• El objetivo más común es el robo de sesiones abiertas mediante la obtención del identificador de sesión (guardado en una cookie) y así poder acceder a página que requieran autentificación.

• Para llevarlos a cabo se utilizan parámetros (GET o POST) o campos (guardados en la BBDD) que son usando para crear una página de respuesta para el cliente. Por ejemplo, una web que acepte un parámetro error “http://www.example.com/index.php?error=Conexion” e imprima dicho valor en la página de respueta.

• Identificar este tipo de posible situación analizando la información que se intercambia con el servidor y el código HTML de respuesta.

• Recomendaciones que ayudan a reducir riesgos:

  • Codificar elementos HTML. Por ejemplo, convertir “<script>alert(‘xss’);</script>” en “lt;script&gt;alert(‘xss’);&lt;/script&gt;”

  • Vigilar lugares donde la anterior medida pueda no ser de utilidad, como por ejemplo si tenemos el siguiente código “<img src=’$url’>”, podria injectarse “doesntexist.jpg’ onerror=’alert(document.cookie)" sin problemas.

Métodos HTTP:

• Un servidor web puede aceptar varios comandos, los más habituales e inofensivos son GET y POST pero el resto podrían comprometer la seguridad (HEAD, GET, POST, PUT, DELETE , TRACE, OPTIONS, CONNECT):

  • PUT: Permite al cliente subir ficheros. Un atacante podría utilizarlo para subir código maligno (e.g. un fichero PHP).

  • DELETE: Permite al cliente borrar un fichero en el servidor.

  • CONNECT: Permite utilizar el servidor como proxy.

  • TRACE: Devuelve la cadena de texto que haya sido enviada. Puede ser utilizado para generar un ataque Cross Site Tracing (XST).

• Identificar los métodos soportados:

  $ telnet servidor.com 80

  OPTIONS / HTTP/1.0

SQL Injection:

• El objetivo radica en “inyectar” en la base de datos una consulta/orden SQL creada por el atacante, pudiendo así leer/modificar información o cambiar el comportamiento de la aplicación.

• Por ejemplo, si la aplicación web realiza la siguiente consulta con parámetros procedentes de un formulario:

  SELECT * FROM Users WHERE Username=’$username’ AND Password=’$password’

  Un atacante podria rellenar el formulario indicando los siguientes valores:

  $username = 1′ or ‘1’ = ‘1

  $password = 1′ or ‘1’ = ‘1

  De forma que se ejecutaria:

  SELECT * FROM Users WHERE Username= ‘1’ OR ‘1’ = ‘1’ AND Password= ‘1’ OR ‘1’ = ‘1’

  Y podría engañar el sistema de autentificación.

• Tipos de SQL Injection:

  • Inband: La información se obtiene por el mismo canal que se inyecta la sentencia SQL (e.g. inyección por formulario y presentación de resultado en la siguiente respuesta HTML)

  • Out-of-band: La información se obtiene por un canal diferente al que se ha usado para inyectar la sentencia SQL (e.g. se inyecta mediante un email y se obtienen a través de la interfaz web)

  • Inferencial: La información no llega a traspasarse, pero el atacante es capaz de reconstruir la información observando las respuestas del servidor de BBDD.

• Para que el ataque sea efectivo la sentencia SQL debe ser correcta, por tanto si la aplicación web muestra los mensajes de error generados por la BBDD se facilita el ataque. Se recomienda ocultar dichos errores (Blind SQL Injection).

• Identificar los puntos donde la aplicación web realiza consultas a una base de datos (e.g. autentificación, visualización de elementos dinámicos, búsquedas).

• Testear los puntos identificados introduciendo datos (en formularios o modificando parámetros GET/POST y cookies) que provoquen errores en la BBDD (e.g. comillas, punto y coma, comentarios –, operadores lógicos AND/OR).

• Recomendación:

  • Filtrar los datos recibidos del cliente antes de utilizarlos en sentencias SQL.

  • Utilizar placeholders si nuestra base de datos lo soporta.

Otros ataques “Injection”:

• Los “Stored Procedures” de las BBDD también pueden verse afectados por SQL Injection.

• Si se trabaja con servidores LDAP, es posible que las consultas sean vulnerables a inyección.

• Sistemas ORM (Object-Relational Managment) como Hibernate, también pueden ser vulnerables a SQL Injection.

• Si la información es guardad o transportada en XML, también puede ser vulnerable a inyección de datos.

• Si el servidor soporta SSI (Server Side Incluyes), este responderá a tags del tipo:

  <!–#echo var="DATE_LOCAL" –>

  <!–#exec cmd="ls" –>

  <!–#include virtual="/footer.html" –>

  Si es posible inyectar este tipo de código tal y como se lleva a cabo en ataques de Cross Site Scripting, podriamos ejecutar comandos en el servidor.

• Inyección de código (PHP, ASP) es posible si la aplicación realiza incluyes de ficheros con el nombre compuesto por datos introducidos por el usuario.

• Si la aplicación web interactua con servicios SMTP/IMAP, podría verse afectado por inyección.

• Si la aplicación web realiza ejecuciones de comandos que son construidos con datos proporcionados por el cliente, podría inyectarse sentencias para que sean ejecutadas en el sistema (e.g.
  http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|).

Riesgos referentes a ataques de denegación de servicio:

• Bloqueo de usuarios por intentos de autentificación fallidos.

• Posibilidad de provocar buffers overflows.

• Saturación por carga excesiva de objetos en el servidor.

• Provocar una gran cantidad de iteraciones sobre una parte de código que requiera un uso intensivo de CPU.

• Agotar el espacio en disco duro del servidor generando una gran cantidad de información en logs o mediante otros ficheros de disco.

• Identificar incorrecta liberación de recursos (e.g. conexiones a BBDD abiertas que no son usadas)

• Intentar que el servidor guarde una gran cantidad de información en la sesión, agotando la memoria disponible.

Servicios Web:

• Identificar si existen servicios web (SOAP/Web services) para analizar los posibles riesgos que puedan implicar.

AJAX (Asynchronous JavaScript and XML):

• Técnica de desarrollo web que permite la creación de interficies web con capacidad de respuesta más rápida, dado que únicamente recarga/modifica partes de la página visualizada sin generar una nueva petición completa. Para ello se hace uso del objeto XMLHttpRequest de JavaScript y respuestas codificadas en HTML, XML, JavaScript Object Notation (JSON), etc…

• Las interficies que hacen uso de AJAX pueden ser también vulnerables a los ataques anteriormente descritos (XSS, SQL Injection, etc…), dificultando su subsanación por la propia naturaleza de la tecnología).

• Riesgos:

  • Incremento de las posibilidades de ataque dado el aumento de puntos de entrada a asegurar.

  • Mayor exposición de funciones internas de la aplicación.

  • Acceso a recursos de terceros sin mecanismos de codificación y seguridad.

  • Posibles fallos de protección de información de autentificación y sesiones.

  • Mayor riesgo de errores de seguridad, por menor claridad en la línea que separa el código del lado cliente del lado servidor.

• Identificar el framework AJAX que esta siendo utilizado con el objetivo de determinar el tipo de codificación utilizada para la transmisión de información (XML, JSON, etc…).

• Identificar en el código HTML que llamadas se están realizado utilizando AJAX.

• Observar mediante un Proxy o sniffer, en que momento se ejecutan dichas llamadas y que tipo de información se transmite.

• Utilizar depuradores de código JavaScript en el navegador cliente para determinar posibles errores potenciales.

• Basar el estudio de vulnerabilidades en los puntos vistos anteriormente (XSS, SQL Injection, etc…).