WEB HACKING – Conceptos Básicos sobre seguridad en aplicaciones Web, Metodología OWASP – Parte II – Seguridad en Sistemas y Técnicas de Hacking. TheHackerWay (THW)

Durante el proceso de pruebas de seguridad de una aplicación web, se suele tener la falsa concepción de que la revisión automatizada es eficiente y efectiva, es así como muchos testers y pentesters (especialmente los menos experimentados) suelen anteponer y priorizar los resultados devueltos por scanners de vulnerabilidades en aplicaciones web sobre la inspección manual, con esto no se pretende de ninguno modo desestimar la labor que desempeñan dichas herramientas como scanners y frameworks de penetración, solamente que es necesario comprender que dichas herramientas tienen sus propias LIMITACIONES y que no se puede esperar que una utilidad que ha sido creada para aplicaciones genéricas funcione del mismo modo para aplicaciones con un alto nivel de personalización. Dadas estas premisas, esta claro que el uso de las herramientas no es suficiente para afrontar el reto que implica desplegar una aplicación web segura, es necesario que la persona responsable y el equipo involucrado tenga presentes como mínimo las siguientes técnicas sobre el testing de una aplicación web

REVISIÓN DE CÓDIGO

Como su nombre lo indica, es una técnica que debe de ser aplicada por una persona o equipo que tenga conocimientos sobre la plataforma, framework y/o lenguaje de programación que se emplea para el desarrollo de la aplicación, debe ser llevada a cabo durante el proceso de desarrollo y despliegue con el fin de encontrar cualquier tipo de vulnerabilidad en fases previas al despliegue de la aplicación en un entorno productivo. La revisión “estática” del código (que es como le conoce a la inspección manual) se debe ser medida en función a los requerimientos de negocio, problemas intrínsecos relacionados con la plataforma o lenguaje de programación, Checklist de elementos que deben medirse dependiendo de las necesidades organizacionales (en este punto la guía de desarrollo de OWASP, cuenta listas bastante completas que pueden ser empleadas para verificar detalles concretos del desarrollo de una aplicación web)
MODELADO DE AMENAZAS Y RIEGOS
Dentro de los requerimientos de seguridad se necesita tomar en consideración muchos “marcos” de amenazas posibles y el riesgo de que estas se puedan reproducir con éxito. El modelado de amenazas y riesgos en cualquier tipo de entorno, normalmente suele asignar un nivel de criticidad a cada una de las amenazas detectadas en un análisis previo, aunque esta claro que no es posible medir todas las amenazas que pueden afectar a un sistema, tener una lista de estas amenazas y un nivel criticidad a cada una permite a los equipos de desarrollo y testing tener un “punto fijo” que debe tenerse en cuenta en el proceso de desarrollo para evitar que se puedan producir. Este estudio normalmente da paso (o viene acompañado) de lo que se conoce como “Base de Conocimiento de Vulnerabilidades” el cual es simplemente un repositorio donde se plasman las amenazas y sus correspondientes niveles de riesgo, que evidentemente dependen de las actividades de la organización, nivel de disponibilidad de las aplicaciones y otros factores de negocio relacionados.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE CON LA SEGURIDAD COMO OBJETIVO PRIMORDIAL
Aunque suene un poco repetitivo, es importante que en el ciclo de vida de desarrollo (SDLC por sus siglas en ingles Software Develop Life Cicle) se encuentre apoyado por expertos en seguridad y que los desarrolladores de la aplicación tengan conocimientos avanzados al respecto, además de esto, deben de ser conscientes de las implicaciones que pueden acarrear algunas decisiones técnicas a la hora de escribir código, dado que posiblemente estas decisiones, aunque en apariencia intenten resolver un problema, pueden representar un riesgo para la seguridad de la aplicación.
CONTROLES Y MEDIDAS DE SEGURIDAD COMUNES

Los controles y medidas de seguridad habituales deben tenerse en cuenta en todo momento, se trata de las medidas habituales tales como la correcta instalación de parches y actualizaciones, Firewalls, AV, IDS, NIDS, etc.
Con la entrada anterior y estos párrafos queda explicado de forma muy general, los conceptos básicos sobre el desarrollo de aplicaciones web y el rol que juegan los auditores y testers en seguridad.

NOTA: que si, que ya lo sé, se trata de una introducción demasiado breve y que posiblemente faltan tópicos importantes, pero la intensión de estas publicaciones no es hacer “un libro” con muchos conceptos teóricos sobre “como deberían de ser las cosas” para eso ya existe una gran cantidad de recursos en internet.
La intención de las siguientes publicaciones posteriores a esta es describir todo el proceso que de debe de llevar a cabo para realizar un proceso de pentesting exitoso sobre una aplicación web utilizando como apoyo la guía del pentester de OWASP donde se definen claramente, cada una de las fases que se deben de llevar acabo para conseguir unos resultados óptimos cuando se trata de medir la seguridad de una aplicación web sin importar el tipo de contenido o las funcionalidades que realice. Dicha guía se encuentra disponible para descargar de forma gratuita desde: https://www.owasp.org/index.php/OWASP_Testing_Project se intentará explicar cada una de las categorías expuestas en dicha guía con sus correspondientes controles por medio de ejemplos prácticos y herramientas que apoyen este proceso. Además de tomar como base la mencionada guía, también se utilizarán otros recursos disponibles para la realización de pruebas más concretas que se verán más adelante, esto responde a que ninguna guía ni metodología relacionada con el proceso de desarrollo de software y su posterior evaluación sobre sus controles de seguridad puede contener todas las formas de ataque y penetración que puedan llevar a comprometer la seguridad de una aplicación, de hecho, en la practica la mayor parte de vulnerabilidades que son “explotables” en aplicaciones web, son aquellas que mezclan una serie de técnicas sofisticadas de ataque y una buena creatividad e imaginación por parte del atacante.

En este orden de ideas, se procede a indicar las categorías descritas en la metodología de pentesting de OWASP para que en la próxima publicación se pueda comenzar realmente con la parte practica.

Information Gathering (Recolección de Información)

Se trata de una de las etapas del pentesting más importantes y a la usualmente exige mayor tiempo y dedicación, dado que entre mayor sea la cantidad (y evidentemente la calidad) de la información recolectada de un sistema, existirán mayores probabilidades de encontrar vulnerabilidades o “puertas” de acceso. Esta etapa se encuentra no solamente en la guía de OWASP, sino que es parte integral en cualquier metodología de testing de “caja negra” donde se asume que el auditor (o atacante) no cuenta con información sobre las herramientas de construcción o detalles técnicos que se han utilizado para la construcción de una aplicación determinada. Para conseguir toda la información posible sobre una aplicación y su plataforma subyacente, se cuenta con una gran cantidad de recursos que van desde herramientas automatizadas hasta la realización de pruebas manuales concretas. Algunas de las pruebas que se pueden llevar a cabo en esta categoría son:

Uso de herramientas como Spiders, inspección manual y/o automatizada de Robots y uso de motores de búsqueda (google, bing, etc.)
Identificación de puntos de entrada de la aplicación, reconocimiento de parámetros GET/POST, formularios de autenticación y recolección de peticiones/respuestas HTTP
Identificación del Fingerprint del servidor.
Descubrimiento de detalles técnicos de la aplicación, plataforma utilizada, lenguaje de programación y cualquier información útil.
Recolección de errores en la aplicación (controlados y no controlados) para analizar posteriormente las causas de fallo y si es posible aprovecharlas de algún modo.

Las anteriores pruebas pueden llevarse a cabo con múltiples herramientas tales como HTTP Interceptors, escaneadores, plugins del navegador (firefox o chrome por ejemplo) entre otras. Del mismo modo, es necesario realizar estas pruebas de forma manual y no depender por completo de las herramientas automatizadas.

Configuration Management Testing (Pruebas sobre la administración de la configuración)

Esta etapa permite al tester realizar un análisis de la infraestructura y la topología que pueda revelar cualquier tipo de “problema” con la aplicación web, normalmente en esta etapa el objetivo principal no es la aplicación en si misma, sino el servidor donde se encuentra alojada con el fin de relacionar estos datos con la información recolectada en el paso anterior. Algunas de las pruebas que pueden llevarse a cabo en esta categoría son:

Verificación sobre los detalles técnicos de los certificados SSL/TLS tales como algoritmo de cifrado, fechas de caducidad, cadenas de confianza, etc.
Verificación sobre el servicio de Base Datos (listener de conexiones) con el fin de buscar cualquier tipo de mala configuración o “exposición” de datos sensitivos.
Recolectar información sobre la configuración del servidor web. Esta información es importante en el sentido de que cualquier detalle “suelto” puede representar una amenaza seria para alguna de las aplicaciones alojadas en él.
Recolectar información sobre la configuración de la aplicación web. Descriptores de despliegue, parámetros de configuración, ficheros de propiedades y cualquier otro recurso que sea necesario para el despliegue y puesta en marcha de la aplicación.
Verificación de extensiones de las paginas (*.php, *.asp, *.jsp, etc.) además de verificación sobre los tipos MIME soportados por el servidor web.
Búsqueda de cualquier tipo de fichero que pueda ser leído del servidor.
Identificación de interfaces de administración web de cualquier aplicación alojada en el servidor, de este modo es posible realizar ataques de fuerza bruta sobre estas e intentar ganar acceso aunque dicha aplicación no sea el objetivo del ataque puede ser un vector de acceso valido al servidor.
Verificación de cualquier tipo de vulnerabilidad XST (Cross Site Tracing) sobre el servidor web.

Authentication Testing (Pruebas sobre el mecanismo de autenticación)

En el caso de que la aplicación web tenga zonas de acceso privadas para cada uno de sus usuarios, es necesario realizar un proceso de testing sobre los mecanismos de autenticación implementados y la posibilidad de “evadirlos”. Las pruebas que puede llevar a cabo un tester en esta categoría podrán ser:

Verificación de credenciales viajando sobre canales cifrados y no cifrados
Pruebas para enumeración (recolección) de usuarios, el listado de usuarios validos obtenidos puede ser utilizado posteriormente para ataques de fuerza bruta.
Pruebas de bypassing sobre el esquema de autenticación con el fin de intentar acceder a recursos restringidos sin previa autenticación.
Si la aplicación permite la opción de “Recordar Password”, analizar el comportamiento de dicha funcionalidad así como también analizar el comportamiento de otras funcionalidades relacionadas tales como la de “recordar contraseña”
Pruebas sobre CAPTCHAS en busca de vulnerabilidades conocidas.
Testing sobre las condiciones de “competición” especialmente utilizando peticiones automatizadas con los mismos datos sobre sesiones (navegadores) distintos, de esta forma es posible medir si la aplicación maneja adecuadamente la concurrencia y la integridad de los datos.

Session Management Testing (Pruebas Administración de Sesiones)

HTTP es un protocolo sin estado, lo que obliga a que la interacción con el usuario y su previo almacenamiento de información tenga que ser tratado por medio de soluciones externas que involucran la plataforma (servidor web) y el lenguaje de programación utilizado. En este orden de ideas, un tester debe probar este mecanismo para determinar si es posible romperlo y acceder a información sensible y/o secuestrar sesiones de otros usuarios. Las pruebas relacionadas con esta categoría son:

Pruebas sobre el esquema de sesiones implementado por el programador acompañado con la configuración del servidor web.
Pruebas sobre los atributos de las cookies generadas para mantener el estado de las sesiones en el lado del cliente.
Pruebas para medir la “fijación” de sesión: Cuando una aplicación web no renueva la cookie de un usuario después de una autenticación correcta, es posible que un atacante pueda “forzar” a un usuario a utilizar una cookie previamente conocida por el atacante.
Pruebas sobre “Session Tokens” para determinar si tienen algún tipo de vulnerabilidad explotable.
Pruebas de CSRF (Cross Site Request Forgery).

Authorization Testing (Pruebas sobre el mecanismo de autorización)

Una vez que el mecanismo de autenticación ha finalizado, el siguiente paso lógico para prácticamente todas las aplicaciones web, es el proceso de autorización donde se consultan los roles, permisos y privilegios que tiene el usuario que acaba de autenticarse en la aplicación, dichos permisos/privilegios se asocian a recursos para que el usuario pueda acceder a ellos. En esta etapa del testing, se deben tener en cuenta las siguientes pruebas:

Pruebas de Path Transversal: consiste en la búsqueda de vulnerabilidades en el proceso de autenticación (del tipo Path Transversal) que permita acceder a información sensible (como por ejemplo información personal de otros usuarios en el sistema)
Pruebas para evadir el esquema de autenticación y acceder a información reservada/sensible en el sistema.
Pruebas de elevación de privilegios para determinar si es posible que un usuario pueda elevar su rol y acceder a recursos para los que inicialmente no debería acceder.

Business Logic Testing (Pruebas sobre la lógica de negocio)

Se trata posiblemente de la etapa que más tiempo y creatividad requiere por parte del tester, ya que es en este punto donde se verifica la funcionalidad de la aplicación web, es aquí donde el tester (o atacante dependiendo del rol) comienza a realizar una serie de preguntas del estilo “que pasa si…”, normalmente relacionadas con la búsqueda de errores sobre la aplicación para “tomar nota” sobre su comportamiento en circunstancias anormales. En esta etapa es posible reconocer como reacciona la aplicación ante errores lógicos, por ejemplo, que pasa si un campo de entrada que solamente permite valores numéricos, recibe por parte del usuario un valor alfanumérico? Que pasa si se cambian en las peticiones HTTP valores esperados por la aplicación? “Que pasa si…”. El tester debe cambiar sus modelos mentales y olvidar la “finalidad” de las funcionalidades que esta probando, debe intentar ser creativo para detectar cualquier tipo de vulnerabilidad que pueda ser explotada. Es una de las partes más difíciles del proceso de pentesting dado que recae directamente sobre las habilidades y experiencia del tester y no hay escáneres o herramientas automatizadas que le permitan hacer este tipo de pruebas “personalizadas” para una aplicación concreta. En este paso la categorías más habitual es:

Pruebas sobre las funcionalidades de la aplicación en función a “checklists” correctamente elaborados con el nombre de la funcionalidad a probar y los resultados esperados.

Por otro lado también es necesario que el tester tenga presente que este tipo de pruebas pueden ser peligrosas y difíciles de llevar a cabo dado que si alguna de las pruebas resulta exitosa puede desestabilizar la aplicación y/o provocar daños, por lo tanto, si es posible, estas pruebas deberían llevarse a cabo en un entorno distinto al de producción real (si es posible hacerlo), desde el punto de vista de un atacante, debe tomar las medidas oportunas para evitar ser descubierto y verse implicado en posibles acciones legales.

Data Validation Testing (Pruebas sobre la validación de datos)

En el mundo de las aplicaciones web una de las principales debilidades en términos de seguridad se encuentra en una inapropiada gestión en la validación de datos de entrada. Si una aplicación no filtra correctamente los datos que un usuario puede ingresar, existe el riesgo de que un atacante suministre datos maliciosos que le permitan explorar más a fondo el sistema e incluso ejecutar código externo a la aplicación, este tipo de amenazas son las más frecuentes y también las más peligrosas. Los controles que normalmente se deben implementar en esta etapa son:

Probar si la aplicación es vulnerable a XSS Reflejado.
Probar si la aplicación es vulnerable a XSS Almacenado.
Probar si la aplicación es vulnerable a XSS basado en DOM.
Probar si la aplicación es vulnerable a XSS basado en Flash.
Intentar determinar el motor de base de datos utilizado y probar si la aplicación es vulnerable a SQL Injection utilizando consultas especificas para dicho motor.
Probar si la aplicación es vulnerable a LDAP Inyection.
Probar si la aplicación es vulnerable a XML Inyection.
Probar si la aplicación es vulnerable a XPATH Inyection.
Probar si la aplicación es vulnerable a ORM Inyection, siguiendo un modelo similar a las pruebas de SQL Injection pero aplicadas al ORM (como por ejemplo Hibernate, JPA, etc).
Probar si la aplicación utiliza servicios web y si estos son vulnerables a SSI Injection
Probar si la aplicación soporta IMAP o SMTP para llevar a cabo algún tipo de funcionalidad, en el caso de que sea así, probar si es vulnerable a IMAP/SMTP Injection.
Probar si es posible suministrar un comando del sistema operativo por medio de la aplicación web.
Probar si la aplicación es vulnerable a HTTP Splitting/Smuggling.
Probar si la aplicación es vulnerable a cualquiera de las formas de Buffer Overflow (Heap, Stack, Format).
Probar si la mezcla de varias de las pruebas anteriores da como resultado la explotación del sistema en cualquier forma.

Como se puede apreciar, el trabajo de un tester o de un atacante en esta etapa es el que más pruebas puede contener, dado que es donde “realmente” se localizan vulnerabilidades sobre la aplicación y se determina su impacto. Aunque se han listado las más generales, en este apartado es necesario que el tester determine si existe alguna otra validación necesaria y que se salga del procedimiento estándar.

Denial of Service Testing (Pruebas de Denegación de servicio)

Se trata de una serie de pruebas que frecuentemente se apoyan en el paso anterior, dado que en la practica, es poco lo que un programador puede hacer para defender su código de este tipo de ataques, normalmente una solución mucho más valida y eficiente involucrará un modelo de arquitectura de red adecuado y herramientas externas a la aplicación que intenten determinar cuando una petición (o serie de peticiones) puede tener el comportamiento anómalo y posiblemente sean parte de un ataque DOS. Un ataque de denegación de servicio puede ser aun más “dañino” si es realizado desde varias máquinas en diferentes puntos de la red (intranet o incluso internet) esta clasificación de DoS, es conocida como DDoS y resulta ser exponencialmente perjudicial para un servidor web y las aplicaciones que hospeda dado que suele consumir la totalidad de recursos disponibles del servidor. aunque este tipo de ataques no son realmente parte de un tester de seguridad de aplicaciones web, es necesario verificar que la aplicación esta en condiciones para no permitir que un ataque DoS sea llevado a cabo por medio de algún tipo de vulnerabilidad en la aplicación, en este orden de ideas los controles que deben ser tomados en cuenta son:

Probar si la aplicación es vulnerable a SQL Injection y si es el caso, verificar si es posible realizar un ataque utilizando “wildcards” especiales que afecten el rendimiento de las consultas SQL llevadas a cabo.
Probar si una cuenta de usuario puede ser bloqueada por un atacante por medio de ataques de “login” o “password” incorrectos.
Probar si existe cualquier tipo de condición de Buffer Overflow que pueda guiar a denegación del servicio.
Probar que el código de la aplicación no depende directamente de la entrada de usuario, por ejemplo, que a partir de una entrada especifica se puedan crear de forma dinámica múltiples referencias a objetos o crear ciclos indefinidos.
Probar que las operaciones que lleva a cabo un usuario no pueden afectar el rendimiento y la disponibilidad de la máquina por exceso de escrituras a disco, como por ejemplo múltiples entradas de logs en los registros.
Probar que los recursos consumidos por la aplicación son correctamente liberados cuando dejan de usarse, como por ejemplo conexiones a bases de datos, descriptores de ficheros abiertos, etc.
Probar que no existan condiciones de almacenamiento excesivo de objetos en la sesión de cada usuario.

Web Services Testing (Pruebas de Servicios Web)

Las aplicaciones web actualmente no solamente incluyen páginas web que enseñan información al usuario final, actualmente el auge que tienen los servicios web y toda la arquitectura de SOA es impresionante, hasta tal punto que se ha convertido en el mecanismo preferido por cualquier arquitecto de software para interactuar con otros sistemas sin importar el lenguaje de programación en el que se encuentran desarrollados, esta es una de las principales características que poseen los web services: La interoperabilidad, no obstante esto trae consigo nuevas amenazas que deben de ser medidas y tratadas con el fin de prestar servicios seguros y que los datos que intercambian dos o más sistemas no se vean comprometidos de ninguna forma. Sin embargo, las vulnerabilidades que se pueden explotar en cualquier web service no son muy diferentes de las vulnerabilidades comúnmente aplicadas a páginas web dinámicas, de hecho las mismas pruebas explicadas anteriormente pueden ser perfectamente validas en este caso, solamente que se enfocan concretamente el la estructura y consistencia de los ficheros XML intercambiados entre cliente y servidor. Las pruebas más comunes en este apartado son las siguientes:

Recolección de información de Servicios Web tales como el esquema de comunicación, end-points, entry-points y cualquier información que describa el proceso de transporte y comunicación de datos, normalmente una muy buena fuente de información en estos casos es la chequeo manual del WSDL del servicio web.
Pruebas sobre el WSDL y los entry-points y end-points encontrados de la prueba anterior.
Pruebas sobre la consistencia estructural de los ficheros XML para determinar como es el comportamiento del web service en el caso de recibir ficheros XML mal formados, aunque en condiciones normales el parser del web service debería fallar dado que el fichero XML no cuenta con el formato esperado, en algunos casos puede darse que el parser no falla ante tales circunstancias y continua con su ejecución, permitiendo a un atacante inyectar campos con contenidos maliciosos. Además de lo anterior, el procedimiento de parseo de un fichero XML es un proceso que frecuentemente tiende a ser muy exigente en términos de uso de la CPU, por lo tanto, un atacante puede aprovechar esta situación para enviar ficheros XML demasiado largos o mal formados para generar una condición de Denegación del Servicio por un consumo desbordado de recursos. Esta prueba no solamente se encuentra limitada a los servicios web de la aplicación, también puede ser extendida al servidor que hospeda la aplicación manipulando ficheros XML de intercambio, dado que en los WSDL de cualquier web service, lo que se suele definir son funciones con parámetros que se ejecutan en el servidor (del mismo modo que cualquier página web dinámica utilizando alguno de los lenguajes de programación más comunes), donde dichos parámetros pueden incluir datos en texto plano hasta ficheros binarios. La posibilidad de solicitar al servidor que ejecute determinadas funciones con parámetros maliciosos, puede ser un mecanismo valido para que un atacante pueda encontrar una vulnerabilidad y posteriormente aprovecharla (como por ejemplo, una vulnerabilidad SQL Injection). En este punto un atacante podría perfectamente crear un fichero XML de forma manual y enviar el mensaje SOAP con dicho fichero (que evidentemente contiene elementos maliciosos) con el fin de comprometer el sistema.
Probar si el web service admite “Attachments” (ficheros binarios) incluyendo ejecutables o documentos, en el caso de que sea así, probar enviando ficheros maliciosos que contengan maleware.
Probar condiciones de intercepción y replicación de mensajes SOAP. Este tipo de prueba es lo que comúnmente se conoce como un ataque MITM, donde un mensaje enviado por un destinatario es interceptado por un tercero, el cual manipula y retransmite el mensaje con modificaciones (o un mensaje nuevo creado por el atacante con su propio contenido), comprometiendo de esta forma la información el mecanismos de transporte entre cliente y servicio.

Ajax Testing (Pruebas sobre funcionalidades con Ajax)

Actualmente es bastante poco frecuentemente encontrar aplicaciones que no utilicen Ajax para brindar a sus usuarios elementos que actúan de un modo muy similar a como lo hacen las aplicaciones de escritorio, esto se consigue gracias al uso de un mecanismo de comunicación asíncrono entre el cliente y el servidor, donde en el lado del cliente existen scripts en JavaScript que formatean las peticiones asíncronas con el servidor utilizando XML. Este modelo tiene una serie de beneficios funcionales importantes, dado que los usuarios pueden interactuar con la aplicación web de una forma mucho más eficiente y distribuyendo los tiempos de espera en las peticiones de una forma bastante óptima, sin embargo, también trae consigo una gran cantidad de posibles ataques se pueden llevar a cabo con bastante éxito, por este motivo es necesario tener presente algunos de los principales mecanismos utilizados por atacantes para conseguir comprometer una aplicación por medio de las funcionalidades en Ajax que esta ofrece. Algunas de las pruebas que resulta conveniente aplicar en este apartado son las siguientes:

Prueba de vulnerabilidades de Ajax, en concreto, las relacionadas con el objeto XMLHttpRequest.
Verificación manual de las funciones expuestas en el lado del cliente (código javascript).
Ejecución de las pruebas indicadas para SQL Injection y Cross-Site Scripting (XSS) y las pruebas relacionadas a la entrada de datos que se han indicado anteriormente.
Intentar encontrar los endpoints para las llamadas asíncronas que se realiza desde las funciones con Ajax y su formato esperado. Para descubrir dichos endpoints se puede parsear el código del lado del cliente (JavaScript/HTML) y posteriormente utilizar un proxy (como por ejemplo OWASP ZAP) para interceptar las peticiones realizadas con Ajax y manipular sus contenidos con el fin de probar vulnerabilidades comunes tales como XSS, CSRF, SQL Injection, etc.
Interceptar y depurar código Javascript con navegadores como Firefox, utilizando extensiones tales como Firebug y Venkman Javascript Debbuger.

En esta entrada se ha intentado explicar los conceptos teóricos necesarios para llevar a cabo pruebas de penetración completas contra aplicaciones web tomando como base la guía oficial del proyecto OWASP. Sin embargo, los conceptos teóricos son insuficientes cuando hacen falta los conceptos prácticos, por este motivo, en las siguientes publicaciones se intentará utilizar herramientas y técnicas que apoyen cada una de las fases expuestas aquí.