\nEsquema general de pasos a seguir para la detección de posibles riesgos y vulnerabilidades. Se incluyen algunas recomendaciones generales.<\/p>\n
Art\u00edculo relacionado: Valoraci\u00f3n de riesgos tecnol\u00f3gicos<\/a><\/i><\/p>\n \nBasado en la guía de pruebas de OWASP<\/a> (Open Web Application Security Project).<\/p>\n <\/p>\n Obtenci\u00f3n pasiva de informaci\u00f3n<\/a> Descubrimiento de aplicaciones:<\/u><\/p>\n Detectar puertos abiertos e identificar servicios\/aplicaciones escuchando (según su \u201cfingerprint\u201d)<\/p>\n nmap \u2013P0 \u2013sT \u2013sV \u2013p1-65535 192.168.1.100<\/p>\n<\/li>\n<\/ul>\n<\/li>\n Información proporcionada\tpor servicios web.<\/p>\n telnet XX.XX.XX.XX 80<\/p>\n<\/li>\n GET \/ HTTP\/1.0<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n Códigos de error:<\/u><\/p>\n Provocar errores \u201cHTTP 404 \u2013 Not Found\u201d para obtener información adicional, por ejemplo:<\/span><\/p>\n Not Found<\/i><\/p>\n The requested URL 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<\/i><\/p>\n \n<\/li>\n<\/ul>\n Vulnerabilidades de los servicios:<\/u><\/p>\n Comprobar que no existen vulnerabilidades en las versiones de las aplicaciones descubiertas.<\/p>\n Comprobación de la validez de certificados SSL:<\/u><\/p>\n<\/li>\n Si se están utilizando conexiones seguras mediante HTTPS, comprobar el certificado del servidor según los siguientes puntos:<\/p>\n Quien firma el certificado.<\/p>\n<\/li>\n Fecha de validez (comprobar que no ha caducado)<\/p>\n<\/li>\n ¿El nombre del certificado corresponde al sitio que estamos accediendo?<\/p>\n<\/li>\n<\/ul>\n Acceso directo a los sistemas de almacenamiento de datos:<\/u><\/p>\n<\/li>\n ¿Es posible acceder a los sistemas de almacenamiento mediante otra aplicación diferente a la interfaz web?<\/p>\n<\/li>\n De ser así, ¿es posible conectar con los mismos usuarios\/passwords de la interfaz web?<\/p>\n<\/li>\n De ser así, ¿los usuarios mantienen las mismas restricciones sobre la información tanto si trabajan sobre interfaz web como directamente sobre los datos?<\/p>\n Ficheros\/Directorios no referenciados, backups o tests antiguos:<\/u><\/p>\n<\/li>\n Identificar posibles ficheros antiguos, backups o tests comentados en el HTML retornado por el servidor.<\/p>\n<\/li>\n Deducir esquema de nombres de las URL<\/p>\n Por ejemplo, si tenemos acceso a \u201c\/app\/user\u201d, quizás también exista \u201c\/app\/admin\u201d<\/p>\n<\/li>\n<\/ul>\n<\/li>\n Comentarios del código HTML retornado por el servidor.<\/p>\n Código HTML comentado<\/p>\n<\/li>\n Código JavaScript que muestra elementos en función del tipo de usuario (e.g. si el usuario es administrador, mostrar el formulario X)<\/p>\n<\/li>\n Formularios HTML con botón submit oculto (posibles antiguos tests)<\/p>\n<\/li>\n Fichero \u201c\/robots.txt\u201d<\/p>\n<\/li>\n<\/ul>\n<\/li>\n Comprobar si existen ficheros con extensiones como \u201c.old\u201d, \u201c.bak\u201d, etc\u2026<\/p>\n<\/li>\n<\/ul>\n Comprender la aplicación mediante manuales, análisis de requerimientos, especificaciones funcionales, etc…<\/p>\n<\/li>\n Creación de información para realizar tests lógicos<\/p>\n<\/li>\n Desarrollar pruebas:<\/p>\n Secuencias de uso no lógicas<\/p>\n<\/li>\n Introducción de datos incorrectos (números negativos, letras en campos numéricos, etc\u2026)<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n Usuarios por defecto o fácilmente deducibles.<\/p>\n Por ejemplo: \u201cadmin.\u201d, \u201cadministrador\u201d, \u201croot\u201d, \u201csystem\u201d, \u201ctest\u201d\u2026<\/p>\n<\/li>\n<\/ul>\n<\/li>\n Posibilidad de evitar el proceso de autentificación.<\/p>\n Cambiando la URL<\/p>\n<\/li>\n Cambiando parámetros GET o POST<\/p>\n<\/li>\n Cambiando valor de cookies<\/p>\n<\/li>\n Predicción de la sesión (si esta es secuencial, podríamos \u201crobar\u201d sesiones)<\/p>\n<\/li>\n SQL Injection<\/p>\n<\/li>\n<\/ul>\n<\/li>\n \u201cDirectory Traversal\u201d<\/p>\n 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 \u201c..\/..\/etc\/passwd\u201d<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n General:<\/u><\/p>\n Cuestiones generales:<\/p>\n ¿El ordenador utilizado para acceder a la web es de uso compartido?<\/span><\/p>\n<\/li>\n ¿Cuantas sesiones concurrentes puede tener un usuario?<\/p>\n<\/li>\n ¿Cuál es el timeout de desconexión por inactividad?<\/p>\n<\/li>\n ¿Las sesiones están asociadas a IPs?<\/p>\n<\/li>\n ¿Existe la funcionalidad \u201crecordar mi usuario\u201d?<\/p>\n<\/li>\n<\/ul>\n<\/li>\n ¿El identificador de sesión se guarda en una cookie, como parámetro GET (en la URL) o como parámetro POST (en formularios)?<\/p>\n<\/li>\n 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?)<\/span><\/p>\n<\/li>\n ¿El identificador de sesión es siempre transportado por un canal seguro?<\/p>\n<\/li>\n ¿Las cookies tiene asignada una fecha de expiración?<\/p>\n<\/li>\n ¿Qué otras cookies establece la aplicación?<\/p>\n<\/li>\n<\/ul>\n Cross Site Request Forgeries (Session riding):<\/span><\/u><\/p>\n 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.<\/span><\/p>\n<\/li>\n En aplicaciones internas de empresas, este ataque puede ser realizado por compañeros o ex-empleados.<\/p>\n<\/li>\n Comprobar si la aplicación web puede verse afectada por esta situación.<\/p>\n<\/li>\n ¿Todas las acciones requieren confirmación?<\/p>\n<\/li>\n ¿La aplicación añade información relacionada con la sesión en la URL para evitar este tipo de ataques?<\/p>\n<\/li>\n ¿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)<\/span><\/p>\n<\/li>\n ¿La aplicación comprueba el Referer? (Aunque el atacante también podría manipularlo o hacer que no existe utilizando iframes)<\/p>\n<\/li>\n<\/ul>\n Cross Site Scripting (XSS):<\/u><\/p>\n Un ataque XSS puede ser llevado a cabo mediante: HTML, JavaScript, VBScript, ActiveX, Flash, y otros lenguajes del lado del cliente.<\/span><\/p>\n<\/li>\n 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.<\/p>\n<\/li>\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 \u201chttp:\/\/www.example.com\/index.php?error=Conexion\u201d e imprima dicho valor en la página de respueta.<\/p>\n<\/li>\n Identificar este tipo de posible situación analizando la información que se intercambia con el servidor y el código HTML de respuesta.<\/p>\n<\/li>\n Recomendaciones que ayudan a reducir riesgos:<\/span><\/p>\n Codificar\telementos HTML. Por ejemplo, convertir \u201c<script>alert(‘xss’);<\/script>\u201d en \u201c<\/span>lt;script>alert(‘xss’);<\/script>\u201d<\/span><\/p>\n<\/li>\n Vigilar lugares donde la anterior medida pueda no ser de utilidad, como por ejemplo si tenemos el siguiente código \u201c<img\tsrc=’$url’>\u201d, podria injectarse \u201cdoesntexist.jpg’ onerror=’alert(document.cookie)" sin problemas.<\/span><\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n Métodos HTTP:<\/u><\/p>\n 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):<\/span><\/p>\n PUT: Permite al cliente subir ficheros. Un atacante podría utilizarlo para subir código maligno (e.g. un fichero PHP). <\/span>\n\t\t<\/p>\n<\/li>\n DELETE: Permite al cliente borrar un fichero en el servidor. <\/span>\n\t\t<\/p>\n<\/li>\n CONNECT: Permite utilizar el servidor como proxy. <\/span>\n\t\t<\/p>\n<\/li>\n TRACE: Devuelve la cadena de texto que haya sido enviada. Puede ser utilizado para generar un ataque Cross Site Tracing (XST).<\/span><\/p>\n<\/li>\n<\/ul>\n<\/li>\n Identificar los métodos soportados:<\/p>\n $ telnet servidor.com 80<\/span><\/i><\/p>\n OPTIONS \/ HTTP\/1.0<\/i><\/p>\n<\/li>\n<\/ul>\n SQL Injection:<\/u><\/p>\n El objetivo radica en \u201cinyectar\u201d 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.<\/span><\/p>\n<\/li>\n Por ejemplo, si la aplicación web realiza la siguiente consulta con parámetros procedentes de un formulario:<\/p>\n SELECT * FROM Users WHERE Username=’$username’ AND Password=’$password’<\/i><\/p>\n Un atacante podria rellenar el formulario indicando los siguientes valores:<\/p>\n $username = 1′ or ‘1’ = ‘1<\/i><\/p>\n $password = 1′ or ‘1’\t= ‘1<\/i><\/p>\n<\/p>\n De forma que se ejecutaria:<\/span><\/p>\n SELECT * FROM Users WHERE Username= ‘1’ OR ‘1’ = ‘1’ AND Password= ‘1’ OR ‘1’ = ‘1’<\/i><\/p>\n Y podría engañar el sistema de autentificación.<\/span><\/p>\n<\/li>\n Tipos de SQL Injection:<\/p>\n 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)<\/p>\n<\/li>\n 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)<\/span><\/p>\n<\/li>\n 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.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n 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).<\/p>\n<\/li>\n 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).<\/p>\n<\/li>\n 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).<\/span><\/p>\n<\/li>\n Recomendación:<\/p>\n Filtrar los datos recibidos del cliente antes de utilizarlos en sentencias SQL.<\/p>\n<\/li>\n Utilizar placeholders si nuestra base de datos lo soporta.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n Otros ataques \u201cInjection\u201d:<\/u><\/p>\n Los \u201cStored Procedures\u201d de las BBDD también pueden verse afectados por SQL Injection.<\/p>\n<\/li>\n Si se trabaja con servidores LDAP, es posible que las consultas sean vulnerables a inyección.<\/p>\n<\/li>\n Sistemas ORM (Object-Relational Managment) como Hibernate, también pueden ser vulnerables a SQL Injection.<\/span><\/p>\n<\/li>\n Si la información es guardad o transportada en XML, también puede ser vulnerable a inyección de datos.<\/span><\/p>\n<\/li>\n Si el servidor soporta SSI (Server Side Incluyes), este responderá a tags del tipo:<\/p>\n <!–#echo var="DATE_LOCAL" –><\/i><\/p>\n <!–#exec cmd="ls" –><\/i><\/p>\n <!–#include virtual="\/footer.html" –><\/i><\/p>\n<\/p>\n 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.<\/p>\n<\/li>\n 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.<\/span><\/p>\n<\/li>\n Si la aplicación web interactua con servicios SMTP\/IMAP, podría verse afectado por inyección.<\/p>\n<\/li>\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. Bloqueo de usuarios por intentos de autentificación fallidos.<\/p>\n<\/li>\n Posibilidad de provocar buffers overflows.<\/p>\n<\/li>\n Saturación por carga excesiva de objetos en el servidor.<\/p>\n<\/li>\n Provocar una gran cantidad de iteraciones sobre una parte de código que requiera un uso intensivo de CPU.<\/p>\n<\/li>\n Agotar el espacio en disco duro del servidor generando una gran cantidad de información en logs o mediante otros ficheros de disco.<\/p>\n<\/li>\n Identificar incorrecta liberación de recursos (e.g. conexiones a BBDD abiertas que no son usadas)<\/p>\n<\/li>\n Intentar que el servidor guarde una gran cantidad de información en la sesión, agotando la memoria disponible.<\/p>\n<\/li>\n<\/ul>\n\u00cdndice<\/h3>\n
\nL\u00f3gica de la aplicaci\u00f3n<\/a>
\nPruebas de autentificaci\u00f3n<\/a>
\nGesti\u00f3n de sesiones<\/a>
\nValidaci\u00f3n de los datos<\/a>
\nRiesgos referentes a ataques de denegaci\u00f3n de servicio<\/a>
\nServicios Web<\/a>
\nAJAX (Asynchronous JavaScript and XML)<\/a><\/p>\nObtención pasiva de información:
\n<\/a><\/h3>\n\n
\n
\n
\n
\n\t\/page.html was not found on this server.<\/i><\/p>\n\n
\n
\n
\n
Lógica de la aplicación:<\/a><\/h3>\n
\n
\n
Pruebas de autentificación:<\/a><\/h3>\n
\n
\n
\n
\n
Gestión de sesiones:
\n<\/a><\/h3>\n\n
\n
\n
Validación de los datos:
\n<\/a><\/h3>\n\n
\n
\n
\n
\n
\n
\n
\n
\n\thttp:\/\/sensitive\/cgi-bin\/userData.pl?doc=\/bin\/ls|).<\/span><\/p>\n<\/li>\n<\/ul>\nRiesgos referentes a ataques de denegación de servicio:
\n<\/a><\/h3>\n\n
Servicios Web:
\n<\/a><\/h3>\n