¿Qué es OWASP?

OWASP (Open Web Application Security Project/ Proyecto abierto de seguridad de aplicaciones web) nació en 2001 como un proyecto de código abierto. En 2004 se transformó en la Fundación OWASP, organismo sin ánimo de lucro cuyo objetivo es señalar los peligros y ayudar a los desarrolladores de todo el mundo a garantizar la seguridad de las aplicaciones y los dispositivos que consumimos. Dicha Fundación está formada por empresas, organizaciones educativas y particulares, que aúnan esfuerzo, conocimiento y consenso sobre cómo realizar dichas pruebas, de una manera rápida, exacta y eficiente.

Inicialmente se centraron en las amenazas de seguridad en las webs. Sin embargo, con el paso del tiempo, han ido incorporando las tecnologías que han pasado a ser fundamentales en nuestras sociedades.

Así, su ámbito de actuación incluye a las webs, pero también móviles, dispositivos IoT, interfaces de programación de aplicaciones (API) y riesgos de privacidad.

 

Guías OWASP

OWASP ha producido varias guías que juntas hacen una gran base de conocimiento en seguridad de aplicaciones:

• Preguntas Frecuentes sobre Seguridad en Aplicaciones web (OWASP FAQ)
• Guía de Desarrollo Seguro (OWASP Development)
• Guía de Pruebas (OWASP Testing Guide)
• Guía de Revisión de Código (OWASP Code Review)
• OWASP TOP-10 (Los 10 riesgos más importantes en aplicaciones web)
• OWASP Seguridad Móvil (OWASP mobile Security)
• Cómo detectar y responder en tiempo real a los ataques de aplicaciones
• Estándar de Verificación de Seguridad en Aplicaciones

Estas guías se han convertido en herramientas de extrema utilidad para las empresas, guiándolas en las pruebas de seguridad de las aplicaciones web y los servicios web, a priorizar las vulnerabilidades y a aportar soluciones para combatirlas. Creadas gracias a los esfuerzos de colaboración de profesionales de ciberseguridad y voluntarios dedicados, proporcionan un marco de las mejores prácticas utilizadas por los probadores y las organizaciones de todo el mundo.

La ejecución de las pruebas de seguridad de las guías de pruebas OWASP garantizan que el software y las aplicaciones web estén libres de vulnerabilidades, amenazas, y riesgos que puedan ocasionar un grave perjuicio a las empresas.

 

Pruebas de intrusión de aplicaciones web

La metodología de pruebas de intrusión de aplicación web OWASP se basa en un enfoque de caja negra y permiten evaluar la seguridad de una aplicación mediante la simulación de un ataque. Al detectar puntos de vulnerabilidad, por el que un usuario malicioso pudiera realizar un ataque, se informará de la incidencia de seguridad y se evaluará su impacto para proponer una solución técnica.

OWASP ha establecido 10 subcategorías para la realización de pruebas de intrusión de aplicaciones web:

1.Recopilación de Información. Es un paso necesario en una prueba de intrusión. Se recoge toda la información sobre la aplicación a tratar para poder entenderla y como el usuario o el navegador se comunica con ella. Se puede llevar a cabo mediante:

• Spiders, Robots, y Crawlers.
• Reconocimiento mediante motores de Búsqueda.
• Identificación de puntos de entrada de la aplicación.
• Pruebas para encontrar firmas de Aplicaciones Web.
• Descubrimiento de aplicaciones.
• Análisis de códigos de error.

2.Pruebas de gestión de la configuración. Analizar la infraestructura o la topología de la arquitectura pueden revelar datos importantes sobre una aplicación Web. De esta manera se podrán identificar vulnerabilidades o fallos de configuración que puedan existir en toda la arquitectura de la aplicación. Se llevarán a cabo mediante:

• Pruebas de SSL/TLS.
• Pruebas del receptor de escucha de la BD.
• Pruebas de gestión de configuración de la infraestructura.
• Pruebas de gestión de configuración de la aplicación.
• Gestión de extensiones de archivo.
• Archivos antiguos, copias de seguridad y sin referencias.
• Interfaces de administración de la infraestructura y de la aplicación.
• Métodos HTTP y XST.

3.Pruebas de Autenticación. Con estas pruebas se intenta confirmar o verificar la identidad digital del remitente de una comunicación. Si la información que introduce por ejemplo un usuario en un formulario web se realiza utilizando protocolos, etc. Si se comprende cómo funciona el proceso de autenticación se podrá vulnerar dicho mecanismo. Las pruebas son:

• Transmisión de credenciales a través de un canal cifrado.
• Enumeración de usuarios.
• Pruebas de diccionario sobre cuentas de Usuario o cuentas predeterminadas.
• Pruebas de Fuerza Bruta.
• Saltarse el sistema de autenticación.
• Comprobar Sistemas de recordatorio/restauración de contraseñas vulnerables.
• Comprobar Sistemas de recordatorio/restauración de contraseñas vulnerables.
• Pruebas de gestión del Caché de Navegación y de salida de sesión.
• Pruebas de CAPTCHA.
• Múltiples factores de autenticación.
• Probar por situaciones adversas.

4.Pruebas de gestión de sesiones. Una aplicación web puede interactuar con un usuario de diferentes maneras, dependiendo del servidor y de los requisitos de seguridad y disponibilidad de la aplicación.

La gestión de sesiones de una aplicación web va desde que el usuario entra en dicha web y hace su autenticación hasta la salida de la aplicación. Si la realiza a través de HTTP, este es un protocolo sin estados. Es decir, responde a las peticiones del cliente sin enlazarlas entre sí. Para poder asociar dichas peticiones entre sí, se requiere de un “Identificador de sesión” “Session ID” o Cookie. Con estas pruebas, se verifica como ha sido desarrollado el mecanismo de Gestión de Sesión y una vez entendido poder romperlo, saltar la sesión de usuario y de esta manera vulnerarlo.

• Pruebas de vulnerabilidad para el esquema de gestión de sesiones.
• Pruebas de vulnerabilidad para atributos de sesión.
• Pruebas de vulnerabilidad para fijación de sesión.
• Pruebas de vulnerabilidad para variables de sesión expuestas.
• Pruebas de vulnerabilidad para CSRF.

5.Pruebas de Autorización. La autorización llega después de que se haya realizado una autenticación correcta, por lo tanto, se parte desde ese punto. Con estas pruebas se entiende el proceso de autorización y de qué forma se puede evitar el sistema de autorización, haciéndolo vulnerable. Se harán pruebas de ruta transversal, para acceder a información reservada, pruebas para saltarse el esquema de autorización y acceder a funciones o recursos reservados y pruebas de escalación de privilegios para comprobar que un usuario no puede acceder a más funcionalidades de las que tenía asignadas.

6.Pruebas de la lógica de negocio. La lógica de negocio puede contener fallos de seguridad que permiten a un usuario hacer algo no permitido por el negocio. Los ataques sobre la lógica de negocio de una aplicación son peligros, difíciles de detectar y específicos de cada aplicación. Si la persona que realiza las pruebas es ajena al negocio, tendrá que utilizar sentido común y preguntar al negocio si la aplicación debería permitir operaciones diferentes. Cuando las aplicaciones son muy complejas, necesitará más información de la aplicación y tendrá que pedir al cliente dicha información para entenderla, antes de comenzar la comprobación. También los desarrolladores podrán ayudar dando las explicaciones necesarias respecto a la funcionalidad de la aplicación. Con OWASP se puede hacer de una forma sistemática, que consiste en:

• Comprender la aplicación.
• Crear datos en bruto para diseñar comprobaciones lógicas.
• Diseñar las comprobaciones lógicas.
• Prerrequisitos estándar.
• Ejecución de comprobaciones lógicas.

7.Pruebas de validación de datos. En la seguridad de las aplicaciones web, la debilidad más común, es la falta de una validación adecuada de las entradas del cliente o del entorno de la aplicación. Esta debilidad conduce a casi todas las principales vulnerabilidades en las aplicaciones, como por ejemplo:

• Vulnerabilidad de la integridad de los datos: El atacante manipula los datos introduciendo intencionadamente datos erróneos que manipulan la función de negocio.

• Violación del formato de los datos: Un atacante consigue introducir datos sin la sintaxis correcta, fuera de los límites de longitud, que contenga caracteres no permitidos, con signo incorrecto o fuera de los límites del rango. Esto provoca un mal funcionamiento de la aplicación.

• Desbordamientos de búfer o memoria: Cuando la cantidad de datos supera la capacidad de memoria preasignada, esos datos sobrantes se almacenan en zonas de memoria adyacentes, sobrescribiendo su contenido original y produciendo un fallo.

Nunca se debe confiar en los datos introducidos por el cliente, ya que tiene todas las posibilidades de manipular los datos. Hay que garantizar que la aplicación sea robusta contra todas las formas de ingreso de datos, ya sea obtenida del usuario, de la infraestructura, de entidades externas o de sistemas de base de datos.

Con estas pruebas se van a ver todas las formas posibles de validaciones de entrada. Y se podrá establecer si la aplicación es resistente ante cualquier entrada de datos.

8.Pruebas de denegación de Servicio. Cuando no se puede establecer comunicación entre el servidor y el usuario válido, puede ser debido a que tiene el acceso denegado. Esto lo ha podido originar un usuario malicioso, inundando con suficiente tráfico una máquina para hacerla incapaz de sostener el volumen de peticiones que recibe.

La denegación de servicio puede deberse a:

• Ataques con wildcards SQL.
• Ataques para bloquear cuentas de usuario registrándose repetidas veces con contraseña errónea.
• Desbordamiento de búfer
• Agotando los recursos del servidor asignándole gran número de objetos.
• Reduciendo su rendimiento haciendo entradas de usuario como bucle.
• Fallos en la liberación de recursos.
• Grabando grandes cantidades de datos incluso en los discos locales.
• Agotando los recursos del servidor llenando toda su memoria.

9.Pruebas de Servicios Web. Los servicios web y SOA (Arquitectura Orientada a Servicios) son aplicaciones en expansión que están permitiendo que los negocios interoperen y crezcan a un ritmo sin precedentes. Los clientes de servicios web generalmente no son frontales web, sino otros servidores. Los servicios web están expuestos a la red como cualquier otro servicio, pero pueden ser utilizados en HTTP, FTP, SMTP o acompañados de cualquier otro protocolo de transporte. Un servicio web es un sistema software diseñado para soportar la interacción máquina-a-máquina, a través de una red, de forma interoperable. Cuenta con una interfaz descrita en un formato procesable por un equipo informático (específicamente en WSDL), a través de la que es posible interactuar con el mismo, mediante el intercambio de mensajes SOAP, transmitidos usando serialización XML sobre HTTP conjuntamente con otros estándares web. Los puntos débiles en servicios web son similares a otras vulnerabilidades como la inyección SQL, revelación de información, etc., pero también tienen vulnerabilidades de XML. Los siguientes apartados describen las pruebas a realizar a los servicios Web:

• Obtención de Información en Servicios Web.
• Pruebas de WSDL.
• Pruebas estructurales de XML.
• Comprobación de XML a nivel de contenido.
• Comprobación de parámetros HTTP GET/REST.
• Adjuntos SOAP Maliciosos.
• Pruebas de Repetición.

10.Pruebas de AJAX. AJAX (acrónimo de JavaScript Asíncrono y XML), es un término que describe un modo de utilizar varias tecnologías existentes a la vez: HTML, XHTML, CSS, JavaScript, DOM, XML, XSLT o XMLHttpRequest. Cuando estas tecnologías se combinan en un modelo AJAX, se puede conseguir aplicaciones web capaces de actualizarse conjuntamente sin tener que volver a cargar la página completa. De esta manera crea aplicaciones más rápidas y con una mejor respuesta. Los beneficios que se pueden conseguir son enormes, pero desde el punto de vista de la seguridad se ven más expuestas a los ataques que las aplicaciones web convencionales, ya que las aplicaciones AJAX se extienden entre el cliente y el servidor a diferencia de las webs tradicionales que existen sólo en el servidor. Al ser una técnica relativamente reciente, todavía no se han investigado muchos temas de seguridad. Pueden afectar a dichas aplicaciones AJAX, los siguientes:

• Mayor superficie de ataque, con más puntos de entrada que proteger.
• Funciones internas de la aplicación expuestas.
• Acceso por parte del cliente a recursos de terceros sin seguridad integrada ni mecanismos de cifrado.
• Fallos al proteger información de autenticación y sesiones.

Los equipos de calidad y pruebas de SIPSA trabajan para alcanzar los más altos niveles de calidad del software, centrándose en la definición de los casos de prueba desde las primeras etapas del ciclo de vida del producto. Ayudando así a prevenir, identificar y resolver las vulnerabilidades o defectos lo antes posible. A menudo, el nivel de estrés de las empresas a la hora de cumplir los plazos de entrega es tan alto, que el equipo de desarrollo tiene que priorizar funcionalidades frente a seguridad. La realidad es que no tiene sentido entregar un producto que no satisfaga al usuario final tanto en términos de funcionalidad como de seguridad. Aquí es donde la automatización adquiere una gran importancia, ya que al automatizar proporcionamos una mayor cobertura de las pruebas y una mayor eficiencia.

Con TAST | Test Automation System Tool, se maximiza la automatización de pruebas en todo el proceso desde la perspectiva del usuario final, siendo una pieza clave para la aceleración DevOps. Es fácil de usar, sin necesidad de tener conocimientos en programación y su interfaz define los casos de prueba automatizados en todas las plataformas tecnológicas.

Próximamente compartiremos, en nuestro canal de Youtube y Vimeo, demos de TAST en los que diseñamos casos de pruebas con los que vamos a probar la seguridad/vulnerabilidad del login a varios sitios web, siguiendo el estándar OWASP.

Aprendamos a prevenir y a aplicar todos los medios necesarios; humanos, tecnológicos y económicos, en esa prevención. 

Contacta haciendo clic aquí