Spanish (pdf)
Article in xml format
Article references
Automatic translation
Send this article by e-mail
Cited by SciELO 
Cited by Google 
Similars in
SciELO 
Similars in Google 
Permalink
Introducción
Desde el momento en que una aplicación web de tipo organizacional es desplegada en un ambiente de producción bajo una determinada infraestructura es susceptible de recibir ataques malintencionados. Prevenir que esos ataques resulten exitosos es uno de los principales intereses del área de seguridad de cualquier entidad gubernamental o privada.
El proyecto se enfoca en dos áreas complementarias: (a) modelos de base de conocimiento del dominio de seguridad de aplicaciones web [1] y (b) auditorías de vulnerabilidad a vectores de ataque SQL Injection en servicios web[2] Lo anterior abordado desde los fundamentos, estándares, métodos y conceptos técnicos [3]..
Este proyecto en modalidad de profundización busca crear un modelo base de conocimiento para guiar procesos de auditoría de seguridad web en un prototipo organizacional, frente a los riesgos informáticos a los que esté expuesto. En concordancia con los recientes ataques cibernéticos a las plataformas de las grandes multinacionales, se ofrecen alternativas de solución con el fin de contribuir en el campo de investigación de la seguridad de la información[4]..
A su vez, se busca a futuro evaluar el estado de seguridad en los servicios web expuestos en los aplicativos en producción de una entidad. Enmarcado en un modelo de información específico, y mediante herramientas y técnicas del modelo, se permitirá la visualización y definición de un estado de seguridad de su información digital y de los datos expuestos de dicha organización[5].
Este proyecto bajo la modalidad de profundización ejecuta una prueba del modelo en el marco del área de seguridad de la información, específicamente la seguridad informática, para mitigar ataques de tipo SQL Injection (SQLi) como vector de ataque de este proyecto[5]. La taxonomía del modelo se desarrolló con ideas propias y extrayendo ideas de varias investigaciones previas, las cuales se irán referenciando a medida que se adelanta el documento[1]
Metodología
Para la elaboración de este modelo, se utilizaron varias metodologías integradas una dentro de otra, las cuales se ejemplifican en un diagrama (Figura 1).
Metodología general del modelo base de conocimiento
Esta sección constituye la definición metodológica general para el desarrollo del modelo en sus diferentes elementos; por lo tanto, se contextualizan varias investigaciones, artículos, trabajos y definiciones de los componentes esenciales al momento de realizar un análisis a los modelos de base de conocimiento. Este proyecto incluye dos tipos de metodologías de trabajo. La primera corresponde al diseño del prototipo del sistema recolección, procesamiento y depuración de la base de conocimiento para preparar el modelo prototipo. La segunda corresponde al proceso de sistematización del modelo de diagnóstico. Ambas metodologías tienen como soporte la investigación y, Figura 2. Metodología de desarrollo para la Base de Conocimiento Fuente: [7]. aunque se dan de manera simultánea, para efectos de presentación se analizan por separado (Figura2).
Una base de conocimiento tiene como objetivo principal modelar y almacenar bajo forma digital un conjunto de conocimiento, ideas, conceptos o datos que permitan ser consultados o utilizados en la base de conocimientos. Existen varios métodos y programas para crear bases de conocimientos[8].
Metodología para ejecutar la auditoría en seguridad web
Para la preparación de la auditoría se presentará la metodología, los tiempos y recursos que se utilizarán. Se recolecta y analiza la información evidenciando los hallazgos, las oportunidades de mejora y las fortalezas encontradas durante la auditoría. Una vez se culmine, se presentarán las conclusiones. Con base en el informe de la auditoría, se establecerán las acciones de mejora pertinentes[9].
La metodología inicia con un proceso de planeación. En esta se fijan los objetivos y las herramientas a usar, esto implica qué hacer, cómo hacerlo y cuándo hacerlo. Esta etapa incluye una investigación previa con el fin de conocer la operación de lo que se va a evaluar[9].
Para el desarrollo de la auditoría es importante tener presente que dentro de la metodología general se incluyeron una serie de guías en cada una de las fases del modelo. El proyecto hará uso de estándares, buenas prácticas, herramientas y consejos profesionales tales como: NTC-ISO-IEC 27000, 27001, 27002, 27005, 31000, OSSTMM, OWASP, JUnit y las guías de gestión de riesgos y auditoría emitidas por el MinTIC. Todo esto aplicado al vector de ataque SQL Injection[10], [11].
En la Figura 3, extraída del reporte de seguridad de IBM con la herramienta X-Force IRIS (por sus siglas en inglés de Incident Response and Intelligence Services), entre 2011 y 2019 semuestra cómo los ataques de inyección de SQL han afectado diferentes tipos de organizaciones o industrias de diferentes países en 2011. También se determina que en el 2012 hubo la mayor cantidad de ataques de este tipo, 79 en total. A partir de ahí fue disminuyendo; sin embargo, no han desaparecido totalmente, incluso en enero de este año ocurrió un ataque en Dinamarca[12].
Metodología de desarrollo de software
Para crear la metodología de desarrollo de este proyecto se usó el método OpenUP. Este se define como un proceso unificado ligero que aplica enfoques iterativos e incrementales dentro de un ciclo de vida estructurado. OpenUP adopta una filosofía pragmática y ágil que se centra en la naturaleza colaborativa del desarrollo de software. Es un proceso agnóstico de herramientas y de baja ceremonia que se puede extender para abordar una amplia variedad de tipos de proyectos.
Para las pruebas a la aplicación desarrollada se utilizó JUnit, un marco de código abierto diseñado con el propósito de escribir y ejecutar pruebas en el lenguaje de programación Java. JUnit, originalmente escrito por Erich Gamma y Kent Beck, ha sido importante en la evolución del desarrollo basado en pruebas, lo cual forma parte de un paradigma de diseño de software más amplio conocido como extreme programming (XP).
Modelo de arquitectura del modelo base de conocimiento
La arquitectura de la solución se desarrollará bajo la arquitectura cliente-servidor del lado de la base de conocimiento y de componentes independientes del lado de la auditoría del web service.
Arquitectura base de conocimiento en OpenKM (cliente-servidor):
Arquitectura del modelo base de conocimiento para auditoría de web service (Figura 4).
El objetivo consiste en aplicar la revisión de SQL Injection a un dominio de información (Factura ElectrónicaWeb) para evitar ataques en servicios web mediante una auditoría de seguridad (Figuras 5, Figura 6 y Figura 7).
Considerando los requisitos funcionales, se establecen los comportamientos deseados del aplicativo Factura ElectrónicaWeb, los cuales fueron traducidos en especificaciones técnicas utilizando el lenguaje de descripción de aplicaciones web (WADL) utilizado por la herramienta Netbeans, que permitió desarrollar la construcción del servicio web RESTFul. Este permite escoger el método (GET, utilizado únicamente para consultar información al servidor, o POST, utilizado para solicitar la creación de un nuevo registro) y el formato (XML, un lenguaje de marcado extensible, o JSON, un formato ligero de intercambio de datos) para la consulta o ingreso de datos de la aplicación (Figura 8).
Se virtualizó Kali Linux para ejecutar la propuesta de auditoría sobre el Web Service de la aplicación Factura Electrónica Web (Figura 9).
Se realizaron pruebas unitarias con la herramienta JUnit a la clase encargada de gestionar la seguridad para el aplicativo y el web service (Figura 10).
Resultados
Para implementar el prototipo se utilizó el estilo arquitectónico por capas ejemplificado en un modelo vista-controlador (MVC). Estos sistemas constituyen uno de los estilos que aparecen con mayor frecuencia mencionados como categorías mayores del catálogo, o, por el contrario, como una de las posibles encarnaciones de algún estilo más envolvente. En [15] definen el estilo en capas como una organización jerárquica, tal que cada capa proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le brinda la inmediatamente inferior. Instrumentan así una vieja idea de organización estratigráfica que se remonta a las concepciones formuladas por el patriarca Edsger Dijkstra en la década de 1960, largamente explotada en los años subsiguientes.
Se definió el modelo de datos e identificadores que representan los recursos a exponer. La construcción del WS se limitó a la implementación de la tecnología de servicio web RESTful (Representational State Transfer, based on Rest architecture), con dos métodos HTTP, GET y POST, para especificar las acciones de consulta y registro de información respectivamente. Cabe aclarar que se estableció así, de acuerdo con el masivo uso que se tiene en las entidades y organizaciones del estado colombiano (probablemente por su potencial escalable, así como el acceso con escaso consumo de recursos). Sin embargo, si se prefiere implementar SOAP por su robustez, la seguridad, el control y la validación que ofrecen los esquemas debido a su alto acoplamiento, se podría usar en integraciones de cores bancarios o pasarelas de pago. Para las fases de inicio, elaboración, construcción y transición de la aplicación y del servicio web de la aplicación objeto de auditoría se implementó el método OpenUP en cuatro iteraciones, una por cada fase.
Fase inicial: En primera instancia, se realizaron reuniones de trabajo entre el director del proyecto y el estudiante, en las que se explicó la visión de la aplicación, la metodología y el entorno en que se desenvolverá el proyecto. Finalmente se seleccionó la tecnología y técnica a utilizar en el desarrollo del prototipo de aplicativo del proyecto.
Fase elaboración: Tomando en cuenta los requisitos funcionales y no funcionales se implementó la aplicación, la cual soporta la solución de Factura Electrónica Web y se crea el inicio de sesión general de dicho aplicativo con un tipo de usuario.
Fase implementación:Considerando los requisitos funcionales, se establecen los comportamientos deseados del aplicativo Factura Electrónica Web, los cuales fueron traducidos en especificaciones técnicas a través del lenguaje de descripción de aplicaciones web (WADL) utilizado por la herramienta Netbeans. Este permitió desarrollar la construcción del servicio web RESTFul, el cual posibilitó escoger el método (GET o POST) y el formato (XML) para la consulta o ingreso de datos de la aplicación.
Fase transición: Finalmente, para realizar el despliegue en el ambiente de desarrollo y la integración a del aplicativo con el web service, se usó un módulo de seguridad de la solución, el cual consiste en la implementación de una librería llamada AuthorizationFilter, debido al impacto que tiene en el modelo de negocio del proyecto.
Se definió el modelo y se implementó en el portal de RITA UD (Red de Investigaciones de Tecnología Avanzada de la Universidad Distrital) la herramienta en la cual se soporta la base de conocimiento, ello de acuerdo con las investigaciones descritas anteriormente y seleccionando la más idónea para el proyecto. Esta solución es OpenKM en su versión libre (Figura 11).
Se realizó una auditoría de seguridad en servicios web de una entidad o un prototipo organizacional enfatizando en el tema de SQL Injection.
Como resultado final, se ejemplifica el modelo con cada uno de los segmentos de la jerarquía de base de conocimiento (la cual se expondrá a continuación para futuras confrontaciones) para la auditoría en servicios web con el fin evitar los ataques de tipo SQL Injection como vector de ataque del proyecto. Esta servirá para que el usuario tenga una orientación de la taxonomía manejada en este modelo. La taxonomía del modelo se desarrolló extrayendo ideas propias y de varias investigaciones previas, las cuales se irán referenciando a medida que va avanzando el documento. A continuación, se presenta cada uno de los segmentos [6] y[2].
Con el documento maestro resultado del punto anterior, se alimentó la base de conocimiento orientado a la seguridad informática.
En cada subsección se mostrará al lado un ítem de obligatoriedad u opcionalidad de acuerdo con el modelo que se está proponiendo, por ejemplo: Escaneo de puertos y versiones (obligatorio), análisis SSL (opcional). En caso tal de que el usuario no desee desarrollar los ítems propuestos en el modelo, este modelo no se hará responsable de los resultados finales en cuestión de la base de conocimiento y de la auditoría de los servicios web. Las secciones principales son obligatorias en este modelo, ya que se manejan en las auditorías de servicios de aplicaciones web [16] (Figura 12).
La herramienta permite visualizar los archivos en .pdf almacenados en la base, con formato .doc para documentos, .xls para hojas de cálculo y .ppt para presentaciones (Figura 13).
Jerarquía del modelo base de conocimiento para auditorías de servicios web
Acerca de la auditoría
En esta sección introductoria de vital importancia se realiza un primer acercamiento al negocio de la auditoría de aplicaciones web, ya que se deben conocer los inicios del proyecto que abordará el usuario. Esta sección se desarrollará de acuerdo con el modelo del negocio definido por el usuario. Se hace con el fin de orientar al usuario y ubicarlo en una primera instancia del modelo.
Contexto (obligatorio)
En esta subsección se realiza una descripción y contextualización del negocio al cual el usuario requiere hacer la auditoría. La subsección se desarrollará con los modelos y diagramas que se obtengan del negocio definido por el usuario, tales como el modelo de arquitectura, diagrama de componentes o diagrama de clases. Esta subsección se hace con el fin de que el usuario halle disponibles sus modelos y diagramas iniciales del negocio objeto de auditoría en la base de conocimiento.
Justificación (obligatorio)
En esta subsección se redactan los motivos de la importancia de realizar la auditoría en un modelo de negocio predefinido por el usuario. Se desarrollará con las necesidades propias del negocio por el cual se quiere hacer la auditoría. Tiene el fin de que el usuario halle siempre disponibles las necesidades y motivos del negocio objeto de auditoría en la base de conocimiento.
Objetivos (obligatorio)
En esta subsección se redactan los objetivos generales y específicos a alcanzar por el usuario en la auditoría. Se desarrollará con los objetivos del usuario en el contexto propio del modelo de negocio. Tiene el fin de que el usuario halle siempre disponible los objetivos generales y específicos del negocio objeto de auditoría en la base de conocimiento.
Productos entregables (obligatorio)
En esta subsección se describen los productos a entregar previstos por el usuario una vez realizada la auditoría. Se desarrollará con los productos previstos propios del modelo de negocio que el usuario tiene que entregar. Tiene el fin de que el usuario halle siempre disponible la lista de productos a entregar de acuerdo con la auditoría realizada.
Recursos necesarios (obligatorio)
En esta subsección se describen los recursos mínimos preliminares y necesarios que debe tener el proyecto y el modelo de negocio. Se desarrollará con investigaciones previas que se han realizado+ a nivel de infraestructura (hardware y software) y de las herramientas necesarias en el proyecto. Tiene el fin de que el usuario halle siempre disponible el listado de recursos mínimos necesarios para lograr los objetivos del proyecto en cuestión para realizar la auditoría
Descripción de metodologías (obligatorio)
En esta subsección se describen las metodologías y buenas prácticas utilizadas de acuerdo con el proyecto y al modelo de negocio. Se desarrollará con investigaciones previas que se han realizado sobre las metodologías acordes al proyecto y definidas en el anteproyecto, con aplicación en contexto nacional e internacional. Tiene el fin de que el usuario halle siempre disponible las metodolog ías definidas para la elaboración del proyecto en cuestión y para realizar la auditoría.
Planificación (obligatorio)
En esta subsección se propone como opcional debido a que, dependiendo de las metodologías implementadas por el proyecto y también la dimensión del modelo de negocio, el concepto de tiempo en la planificación entraría como temporal. Esta subsección se desarrollará con la herramienta Project de Microsoft con el proyecto en cuestión. Tiene el fin de que el usuario halle siempre disponible un cronograma planificado con las iteraciones, fases, actividades y tiempos del proyecto actual para realizar la auditoría.
Actual situación y metodología
En esta sección de referencia del modelo se realiza un estado del arte de la seguridad de las aplicaciones web y de las metodologías utilizadas en la misma, ya que es necesario conocer el punto de partida del proyecto. Se desarrollará de acuerdo con el estado del arte de seguridad de las aplicaciones web, las metodologías y las buenas prácticas actuales en este campo. Tiene el fin de hacer que el usuario esté inmerso en este tema de seguridad de aplicaciones web y para ver cuáles metodologías y buenas prácticas puede aplicar de acuerdo con su modelo de negocio.
Osstmm (obligatorio)
En esta subsección se expone brevemente, el manual de metodologías de la OSSTMM y los casos de pruebas catalogados por el manual en cuestión, ya que es un elemento importante que se requiere en la auditoría y que ayudará al usuario en la práctica. Se desarrollará con los tipos y casos de acuerdo con las últimas versiones propuestas por el OSSTMM. Tiene el fin de que el usuario halle disponibles los conceptos, tipos y casos de prueba de seguridad en el modelo propuesto.
Owasp (opcional)
En esta subsección se exponen los tipos de ataques y las vulnerabilidades más populares actualmente, concernientes a la guía de seguridad de pruebas de OWASP, ya que es un referente mundial importante en el tema de la seguridad de aplicaciones y servicios web. Esta subsección se desarrollará de acuerdo con el último top diez propuesto por el OWASP. Esta subsección se hace con el fin de que el usuario halle disponibles los tipos de ataques y vulnerabilidades de seguridad de acuerdo con el modelo propuesto 16.
MinTIC (opcional)
En esta subsección se exponen los lineamientos, modelos de seguridad y guías metodológicas y de auditorías propuestas actualmente por MinTIC, ya que es el referente nacional en el tema de la seguridad de aplicaciones y servicios web. Se desarrollará de acuerdo con las últimas versiones de los documentos mencionados previamente. Tiene el fin de que el usuario halle disponibles los lineamientos, modelos de seguridad y guías metodológicas y de auditorías de seguridad de acuerdo con el modelo propuesto.
Auditoría WEB
En esta sección se explican los temas más destacados de auditoría web en un ambiente organizacional.
Perfil de auditor (opcional)
Perfil de auditor (opcional) Esta subsección describe el perfil del auditor informático, encargado de aplicar sus conocimientos para lograr unos resultados de calidad y generar así recomendaciones de valor para la auditoría. Se marca como opcional en tanto no es un ítem bloqueante para poder proceder con la auditoría. Esta subsección se desarrollará con la información que se tenga de perfiles de auditores en revisiones en auditorías de información. Tiene el fin de que el usuario halle disponibles las características del perfil de un auditor de seguridad informático de acuerdo con el modelo propuesto.
Tipos de test (obligatorio)
En esta subsección se exponen los tipos (interna o externa) y enfoques de la auditoría, ya que puede ser aplicada a diferentes contextos. Se desarrollará con la información de revisiones que se tenga de los diferentes enfoques. Tiene el fin de que el usuario halle disponibles los enfoques de auditoría de acuerdo con el modelo propuesto.
Aspectos contractuales de auditoría (obligatorio)
En esta subsección se exponen los aspectos contractuales de la auditoría, ya que son los que el auditor firma con la organización en caso de ser aplicada. Se desarrollará con la información de revisiones que se tenga de los tipos de permisos, acuerdos, reglas y del alcance al aplicar una auditoría. Tiene el fin de que el usuario halle disponibles los aspectos más comunes de una auditoría.
Aspectos normativos legales (obligatorio)
En esta subsección se exponen las normas y leyes que apliquen en la auditoría, ya que si la organización encuentra vulnerabilidades que afecten información personal (habeas data), esta debe blindarse según las leyes expuestas en este apartado. Esta subsección se desarrollará con la información de revisiones que se tenga de las leyes y normas que apliquen en la auditoría. Tiene el fin de que el usuario halle disponibles las leyes y normas, ya sean nacionales o internacionales, al realizar la auditoría.
Ética profesional (obligatorio)
En esta subsección se exponen algunos aspectos éticos del auditor de vital importancia, ya que la reputación y la confianza son temas que se gana el auditor en el desarrollo y resultados de su trabajo. Esta subsección se desarrollará con la información de revisiones que se tenga de asuntos destacables en el tema de la ética profesional en la auditoría. Tiene el fin de que el usuario halle disponibles los acuerdos de confidencialidad y de imparcialidad que se tenga al aplicar la auditoría.
Informe de resultados (obligatorio)
En esta subsección se expone la estructura y la forma como se elabora el informe de resultados final, ya que este documento reúne todo el trabajo realizado en la auditoría. La subsección se desarrollará con la información de revisiones que se tenga de estructuras y elaboraciones de informes que se tenga en auditorías. Tiene el fin de que el usuario halle disponible una estructura general del informe de resultados de la auditoría.
Fase de reconocimiento
En esta sección se hace la recolección de toda la información que sea posible acerca del objetivo en el marco organizacional establecido o modelo de información definido; información como direcciones IP, nombres de máquinas, infraestructura de la red, perfiles y configuración de servidores, software, entre otros 6.
Definición del alcance (obligatorio)
En esta subsección se define con el cliente el alcance de la auditoría, ya que se debe saber con exactitud lo que se va a hacer, qué tanto se va a hacer y hasta dónde se va a hacer. Esta subsección se desarrollará con la información de los requerimientos funcionales y no funcionales del modelo de negocio. Se hace con el fin de que el usuario tenga disponible el alcance de la auditoría y pueda tomar decisiones concernientes al tipo de prueba que se aplicará (caja negra, blanca o gris).
Búsquedas en registros de internet (obligatorio)
En esta subsección se definen y se aplican herramientas para búsqueda específica en la web, ya que se deben identificar datos particulares de la infraestructura básica del modelo de negocio objetivo de testeo. La subsección se desarrollará con datos clave como el tipo de servidor de la máquina, bajo qué sistema operativo funciona, qué servicios tiene, qué puertos están abiertos, cuál es su configuración, con qué otras máquinas se conectan, entre otros. Se tiene el fin de que el usuario tenga los datos generados con las herramientas disponibles.
Consultas en páginas públicas (opcional)
Esta subsección muestra información asociada a la organización a la cual le se le está realizando la auditoría; sin embargo, se marca opcional, ya que si bien pueden ser útiles los datos que se encuentran en la web pública, no es un ítem bloqueante para poder proceder con la auditoría. La subsección se desarrollará con páginas, grupos, listas y motores de búsqueda generales públicos en la web. Se tiene el fin de que el usuario halle disponibles las fuentes públicas de las cuales se extrajo información extra.
Búsquedas con motores de búsqueda (opcional)
Esta subsección muestra información relacionada con motores de búsqueda concretos; sin embargo, se marca opcional, ya que si bien pueden ser útiles los datos que se encuentren con el motor, no es un ítem bloqueante para poder proceder con la auditoría. La subsección se desarrollará con información del fichero “robots.txt” y datos de motores de búsqueda concretos. Se tiene el fin de que el usuario halle disponibles las fuentes concretas de las cuales se extrajo información extra.
Búsqueda de subdominios (obligatorio)
Esta subsección muestra información relacionada con la forma de encontrar nuevas máquinas objetivo, ya que se puede comprobar si el dominio que se audita tiene subdominios asociados. La subsección se desarrollará con información que se extraiga de la herramienta Fierce de Kali Linux. Se tiene el fin de que el usuario halle disponibles los datos extraídos de la herramienta de penetración Fierce.
Elaboración de diccionarios (obligatorio)
Esta subsección muestra información relacionada con la elaboración de diccionarios, ya que es otra técnica de hacking que puede servir en la auditoría. Esta subsección se desarrollará con información que se extraiga de la herramienta CeWL de Kali Linux. Se hace con el fin de que el usuario tenga disponibles los datos extraídos de la herramienta generadora de listas de palabras CeWL.
Fase de mapeado
En esta sección se hace la recolección de toda la información que sea posible acerca aplicación web objetivo, el servicio web expuesto y el servidor web que los aloja. Para ello, se emplearán distintas herramientas que generarán datos específicos como puertos, uso de protocolos y seguridad explícita de la aplicación[17].
Escaneo de puertos y versiones (obligatorio)
Esta subsección muestra información relacionada con el escaneado de puertos, ya que en el tema de mapeado es una tarea inevitable para la auditoría. La subsección se desarrollará con información que se extraiga de la herramienta de escaneado de puertos TCP y UDP Nmap. Se tiene el fin de que el usuario tenga disponible la información de los puertos extraídos con herramienta.
Análisis SSL (obligatorio)
Esta subsección muestra información relacionada con el análisis del protocolo seguro SSL, ya que este garantiza la confidencialidad de las comunicaciones vía web para la aplicación objeto de auditoría. Esta subsección se desarrollará con información que se extraiga de las herramientas TLSSled y SSLDigger, las cuales analizan la seguridad de las implementaciones en los protocolos SSL/TLS de un servidor objetivo. Se tiene el fin de que el usuario tenga disponible la información del análisis SSL realizado con dichas herramientas.
Balanceadores de carga y WAF (obligatorio)
Esta subsección muestra información relacionada con los balanceadores de carga y con cortafuegos de aplicaciones web (WAF), ya que con estos datos se sabrá si la aplicación objeto de auditoría se encuentra alojada en varios servidores o solo en uno, también si está protegida detrás de un cortafuegos. La subsección se desarrollará con información que se extraiga de las herramientasWafw00f y Halberd, las cuales analizan el balanceo de carga y protección de la aplicación web. Se tiene el fin de que el usuario halle disponible la información sobre balanceadores de carga y firewall de aplicaciones web.
Análisis de configuración del software (obligatorio)
Esta subsección muestra información relacionada con la configuración de la aplicación objeto de auditoría, ya que con estos datos se entenderá cómo está construido el sistema a nivel de software.
La subsección se desarrollará con información que se extraiga de la herramienta Nikto, la cual sirve para buscar estas vulnerabilidades en aplicaciones web. Se hace con el fin de que el usuario tenga disponible la información sobre dichas vulnerabilidades, si las hay.
Spidering. Navegación manual (obligatorio)
Esta subsección muestra información relacionada con la navegación manual en profundidad de la aplicación (también llamado rastreo de la aplicación), ya que con estos datos es posible conocer a fondo el sitio web e identificar todas las funciones que implemente. La subsección se desarrollará con información que se extraiga de la herramienta ZAP, la cual sirve para identificar objetivos, recursos y parámetros que luego se escanearon con el fuzzer contenido en la herramienta. Se hace con el fin de que el usuario tenga disponible la información con base en los datos extraídos con ZAP.
Spidering. Análisis de resultados (obligatorio)
Esta subsección muestra información relacionada con el análisis de los resultados una vez realizado el recorrido manual de todas las páginas, ya que el objetivo es encontrar archivos en el servidor web. La subsección se desarrollará con información que se extraiga con la función “Spider” de la herramienta ZAP. Se hace con el fin de que el usuario tenga disponible la información con base en los datos encontrados con la función “Spider” de ZAP.
Fase de explotación
En esta sección se desarrollarán dos tareas principales, las cuales son detección y verificación. Cada una de estas tareas estará compuesta por hallazgos concretos que se logren encontrar en esta auditoría. Cada una de las demás auditorías será distinta, sobre todo en esta fase, ya que los hallazgos serán distintos cada vez, así que las pruebas que habrá que realizar cambiarán. También cambiarán en función de otros factores como la aplicación a auditar, o las tecnologías que use el prototipo. Para este caso específicamente son JSF, JPA, EJB, Primefaces, Glassfish, entre otras[7].
Detección (obligatorio)
Esta subsección muestra información relacionada con la búsqueda y detección de vulnerabilidades a partir de los resultados obtenidos durante la fase de mapeado, ya que se debe probar cómo se comporta la aplicación ante errores introducidos a propósito. La subsección se desarrollará con información que se arroje del ejercicio del comportamiento de la aplicación ante errores, luego se escanean los recursos o métodos que envían parámetros al servidor objetivo y, por último, se emplearán ataques de fuzzing (técnica de pruebas en software) sobre los parámetros encontrados en los puntos anteriores. Se hace con el fin de que el usuario tenga disponible la información obtenida de toda la tarea de detección.
Verificación SQL Injection (obligatorio)
Esta subsección muestra información relacionada con la verificación manual de los descubrimientos previos, ya que se debe analizar cada hallazgo sospechoso que aún no haya sido confirmado. La subsección se desarrollará con información específica del segmento de SQL Injection en el modelo propuesto con base en la revisión que se hizo en dicho apartado. Se hace con el fin de que el usuario tenga disponible la información obtenida de todo el ejercicio de verificación de vulnerabilidades usando el vector de ataque SQL Injection.
Resultados y conclusiones
En esta sección se muestran los resultados finales de la auditoría y unas conclusiones del trabajo realizado. Además, se compara con los objetivos propuestos al inicio del proceso para comprobar si efectivamente se cumplieron.
Conclusiones
De acuerdo con el objetivo general y los objetivos específicos, se relacionarán a continuación cada uno de estos con la conclusión de cada punto, demostrando si las actividades realizadas cumplen con el planteamiento inicial de este proyecto.
“Implementar un modelo base de conocimiento para la auditoría de seguridad en servicios web”. Con este proyecto se logró crear un modelo de base de conocimiento implementado sobre una herramienta libre, ejecutando una auditoría en seguridad de servicios web con SQL Injection sobre un prototipo organizacional.
“Implementar metodologías y buenas prácticas en el tema de seguridad de la información”. Se logró establecer una metodología propia para el desarrollo del modelo propuesto, incluyendo metodologías ya definidas, métodos, buenas prácticas, técnicas, recomendaciones y tendencias actuales relacionadas con conceptos de base de conocimiento, auditoría de aplicaciones web, seguridad de la información y desarrollo de software.
“Establecer una metodología propia para el modelo, con metodologías definidas, métodos y buenas prácticas”. En contexto con el anterior objetivo, se hicieron revisiones literarias sobre investigaciones en el tema y se estudiaron guías, técnicas y herramientas para llevar a cabo la auditoría en servicios web, determinando que para el vector de ataque SQL Injection, en el contexto establecido, la prevención no es responsabilidad del JSF. La forma de evitar el ataque depende del API de persistencia que se esté utilizando (JPA, para el caso), pero todo se reduce a que nunca se debe concatenar la entrada controlada por el usuario en cadenas SQL, siempre se debe usar consultas parametrizadas cuando corresponda.
“Alimentar un software de base de conocimiento con datos resultantes de pruebas de Inyección SQL”. Se realizó la instalación, configuración y alimentación del software OpenKM, como herramienta que soporta el modelo propuesto, con los datos y la información resultante del proceso de auditoría de los servicios web en un prototipo definido.
Finalmente, con la socialización de este modelo, se aclara que queda expuesto de manera libre para que sea usado e implementado por cualquier organización, entidad o personas y se pueda trabajar en proyectos futuros si así se quiere.
