Las fallas relacionadas a fuga de información, proporcionan datos adicionales para la etapa de reconocimiento, las cuales son muy útiles durante un proyecto de hacking ético y pruebas de penetración.

Típicamente estás fallos no conducen directamente a la explotación. Pero la información obtenida durante esta etapa es utilizada como una entrada para etapas posteriores, como por ejemplo inyección SQL, adivinar contraseñas, y otros escenarios más.

Anotación importante

SecLists es el compañero del profesional en pruebas de penetración y hacking ético. Es una colección de múltiples tipos de listas utilizadas durante las evaluaciones en ciberseguridad, recopiladas en un solo lugar. Los tipos de listas incluyen nombres de usuario, contraseñas, URLs, patrones de datos confidenciales, cargas útiles (Payloads) para fuzzing, shells vía web y mucho más. Su propósito es permitir un profesional coloque este repositorio dentro de una nueva caja para pruebas, para tener acceso hacia todo tipo de listas factibles de ser necesitadas.

Los comentarios pueden ser muy reveladores. Pueden incluir de todo, desde nombres de usuario y contraseñas, hasta elementos relevantes sobre la gestión, además de lenguajes particulares. Como mínimo los comentarios pueden proporcionar información la cual puede ayudar a lanzar ataques de ingeniería social. En muchos casos también pueden mostrar como funciona la aplicación en su interior ,o indicar partes de la aplicación conteniendo problemas.

Las herramientas automáticas para realizar Spidering se conocen como "robots". Estos son frecuentemente utilizados por los motores de búsqueda, como Google, Bing, o Yandex, para generar una base de datos de las páginas disponibles en la Web. Los robots también pueden ser utilizados por los administradores del sitio web para verificar la validez de los enlaces, por spammers para recolectar direcciones de correo electrónico, o para otros propósitos.

Nikto 2.5 es un escáner de fuente abierta (GPL) para servidores web, el cual realiza pruebas completas contra servidores web por múltiples elementos, incluidos más de 7,000 archivos/programas potencialmente peligrosos, busca versiones obsoletas de más de 1,250 servidores, además de problemas específicos de versiones en más de 270 servidores. También verifica elementos sobre la configuración del servidor, como la presencia de múltiples archivos índice, opciones del servidor HTTP, además intentará identificar los servidores web y el software instalados.

Un elemento a buscar durante las evaluaciones son las páginas por defecto. Estos pueden ser archivos instalados cuando se construyó el servidor. Ejemplos de esto son la página de bienvenida de Apache o sobre algunos de los scripts de muestra instalados en IIS.

Este script inicia repetidamente conexiones SSLv3/TLS, cada vez intentando un nuevo cifrado o compresor mientras registra si un host lo acepta o rechaza. El resultado final es una lista de todas las suites de cifrado y compresores aceptadas por un servidor.

Los parámetros criptográficos sobre el estado de sesión son producidos por el protocolo TLS Handshake, el cual opera sobre la capa de registro TLS. Cuando un cliente y un servidor TLS comienzan a comunicarse por primera vez, acuerdan una versión de protocolo, seleccionan algoritmos criptográficos, opcionalmente se autentican entre sí, y utilizan técnicas para encriptación de clave pública, con el propósito de generar secretos compartidos.

A continuación se detallan el proceso TLS Handshake:

El campo de cabecera "Server" contiene información sobre el software utilizado por el servidor de origen para manejar la petición, los cuales los clientes frecuentemente utilizan para ayudar a identificar el alcance sobre problemas de interoperabilidad reportados, para solucionar o adaptar peticiones para evitar limitaciones particulares del servidor, y para análisis sobre el uso del servidor o del sistema operativo. Un servidor de origen PUEDE generar un campo de cabecera del servidor en sus respuestas.

El método OPTIONS permite rápidamente preguntar a los servidores comuniquen sus métodos soportados. Aunque los métodos GET y HEAD se espera sean soportados, como los estándares sugieren su soporte es requerido, los otros métodos no necesitan ser soportados. Si el servidor receptor soporta el método OPTIONS, responde con la lista de los métodos soportados en la cabecera de repuesta Allow HTTP.