Temas owasp

1. OWASP

2. 1. QUE ES OWASP?
El Proyecto Abierto de Seguridad en Aplicaciones Web (OWASP ) es
una comunidad abierta dedicada a permitir que las organizaciones
desarrollen, adquieran, mantengan aplicaciones y APIs en las que
se pueda confiar.
Todas las herramientas de OWASP, documentos, videos,
presentaciones y capítulos son gratuitos y abiertos a cualquier
interesado en mejorar la seguridad en aplicaciones. No está afiliada
con ninguna compañía de tecnología y produce muchos tipos de
materiales en una manera abierta y colaborativa.

3. 2. pOR QUE ES RELEVANTE OWASP
Hay muchas cosas útiles de seguridad que OWASP hace, pero
las tres cosas principales que hacen que OWASP sea
relevante.
Proyecto OWASP Top 10: OWASP publica cada pocos años una
lista de las 10 principales vulnerabilidades. Estas
vulnerabilidades son examinadas por los miembros y las
organizaciones contribuyentes, y son problemas del mundo
real.

4. OWASP ZED Attack Proxy (ZAP): Es la herramienta de
seguridad gratuita más popular que existe. Se utiliza
para buscar e informar vulnerabilidades de seguridad
en software basado en web.
Serie OWASP Cheat Sheet: Este es actualmente un grupo
de 9 listas rápidas de cómo configurar procesos
específicos. Algunos ejemplos son cómo usar la gestión
de sesión segura, cómo configurar un registro
adecuado, etc.

5. 3. ¿Cuáles son las vulnerabilidades comunes de
seguridad de las aplicaciones web?
–Configuración débil, por defecto o mal configurado.
– Comunicación insegura entre cliente y servidor.
– Software desactualizado.

6. 1. Cross-Site Scripting (XSS para
inyectar código JavaScript)
2. Multiple Cross-Site Scripting (XSS)
3. Stored XSS (inyección de código
almacenado)
4. Unauthenticated Stored XSS(sin
privilegios)
5. SQL Injection
6. Authenticated Stored XSS &
CSRF(falsificación de petición en
sitios cruzados)
7. Server Side Request Forgery (SSRF )
Tipos de vulnerabilidades de aplicación

7. 4.PRUEBAS DE SEGURIDAD
a. Recopilación de Información
Información
sobre la
aplicación
Formas
Probar la mayor
cantidad de base
de código
Pruebas de
intrusión
Descubrimiento
de aplicaciones
Spiders, robots,
crawlers
Revisión de
comentarios y
metadata
Identificación
puntos de
entrada/salida
Análisis de
código de error
Reconocimiento
mediante
motores de
búsqueda

8. B. PRUEBAS DE GESTIÓN DE LA CONFIGURACIÓN
Análisis sobre
la
infraestructura
o topología
Obtener
datos
Configuraciones
de la
infraestructura
Funcionalidades
Administrativas
Métodos de
Autenticación
Código
fuente
Métodos
HTTP

9. b.pruebas de gestión de la configuración
54321 54321

10. c. Pruebas lógicas de negociación
● manipular los
parámetros
● datos de entrada
● moulos
● con códigos
dañinos
para comprobar si es
posible evadir el flujo
de trabajo
ya que gestiona varios
procesos diferentes
Requiere mayor nivel de
creatividad por parte del
especialista en seguridades

11. d. pruebas de autenticación
múltiples factores de
autenticación
Se incluyen las pruebas de
fortaleza de los sistemas de
preguntas y respuestas, cambio y
reinicio de contraseñas, políticas de
creación de contraseñas y
descubrimiento de mecanismo de
autentificación
Es el proceso de intentar
verificar la identidad digital
del remitente de la
comunicación
● enumeración de usuarios
● pruebas de diccionario sobre
cuentas de usuario
● comprobar sistemas de
recordatorio/ restauración
de contraseñas
pruebas de gestión de
caché de navegación

12. E. pruebas de AUTORIZACIÓN
Autorización es el concepto de permitir el acceso a
recursos únicamente a aquellos que tienen permiso
para ello. Las pruebas de Autorización significan
entender cómo funciona el proceso de autorización, y
usar esa información para saltarse el mecanismo de
autorización.

13. F. pruebas de gestión de sesiones
La gestión de sesiones cubre ampliamente todos los controles que se
realizan sobre el usuario, desde la autenticación hasta la salida de la
aplicación. HTTP es un protocolo sin estados, lo que significa que los
servidores web responden a las peticiones de clientes sin enlazarlas
entre sí. Es importante que la seguridad de la aplicación sea
considerada en el contexto de los requisitos y expectativas del
proveedor

14. 7. validación de datos
La debilidad más común en la seguridad de aplicaciones web, es la falta de una validación
adecuada de las entradas procedentes del cliente o del entorno de la aplicación. Esta
debilidad conduce a casi todas las principales vulnerabilidades en aplicaciones, como
inyecciones sobre el intérprete y desbordamientos de búfer.

15. 7. DEnegación de servicio
El concepto fundamental de un ataque DoS de red es un usuario malicioso inundando con
suficiente tráfico una máquina objetivo para conseguir hacerla incapaz de sostener el volumen
de peticiones que recibe. Cuando el usuario malicioso emplea un gran número de máquinas
para inundar de tráfico una sola máquina objetivo, se conoce generalmente como ataque
denegación de servicio distribuidos (DDoS).

16. 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
interoperan 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
Las vulnerabilidades 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..

17. Pruebas Ajax
El uso de técnicas AJAX puede tener enormes beneficios de usabilidad para aplicaciones web. Sin embargo, desde un punto de vista
de seguridad, las aplicaciones AJAX tienen una mayor superficie de ataque que las aplicaciones web normales, y a menudo se
desarrollan con un enfoque en lo que se puede hacer en lugar de lo que se debe hacer.
Problemas de seguridad en AJAX
● Mayor superficie de ataque con muchas más entradas para asegurar.
● Funciones internas expuestas de la aplicación.
● Acceso del cliente a recursos de terceros sin mecanismos de codificación y seguridad incorporados
● Fallo al proteger la información de autenticación y las sesiones
● Línea borrosa entre el lado del cliente y el código del lado del servidor, posiblemente dando como resultado
errores de seguridad

18. proyectos emblemáticos owasp
Proyectos que han demostrado un valor estratégico para OWASP y la seguridad de la aplicación en su
conjunto.
El Proxy Zed Attack (ZAP) de OWASP es una de las herramientas de seguridad gratuitas más populares
del mundo y es mantenido activamente por cientos de voluntarios internacionales

19. 8. Fallas de seguridad de las aplicaciones web
A.INYECCIÓN
● Ocurre cuando un atacante envía datos inválidos a
la aplicación web con la intención de hacerla hacer
algo distinto para lo que fue diseñada/programada.
● El núcleo de una vulnerabilidad de inyección de
código es la falta de validación de los datos
consumidos por la aplicación web. Lo que significa
que esta vulnerabilidad puede estar presente en
casi cualquier tipo de tecnología.
● Todo lo que acepte parámetros como entradas
puede ser potencialmente vulnerable a un ataque
de inyección de código.

20. ¿Cómo se previenen las vulnerabilidades de inyecciones de código?
· La opción preferida es usar una API segura que evite el uso del intérprete de manera
completa, o provea una interfaz parametrizada.
· Usa un “whitelist” como validación de datos del lado del servidor.
· Usa LIMIT y otros controles SQL dentro de la consulta para prevenir la divulgación en
masa de registros en el caso de una inyección SQL exitosa.
· Separación de datos con la lógica de la aplicación web
· Ajustes para limitar la exposición de datos en caso de ataques de inyección exitosos

21. B. autenticación rota
● Permite a los atacantes usar medios manuales y/o
automáticos para tratar de ganar control sobre
una de las cuentas en el sistema, o peor, para
ganar control completo del sistema.
● La autenticación rota usualmente se debe a
problemas de lógica en el mecanismo de
autenticación de la aplicación, como el mal
manejo de sesiones o el listado de nombres de
usuarios.
● La segunda forma más común de esta
vulnerabilidad es permitir que los usuarios
hagan ataques de fuerza bruta contra esas
páginas utilizando combinaciones de nombres de
usuario y contraseñas.

22. ¿Cómo se previenen las vulnerabilidades de autenticación rota?
● Siempre que sea posible, implementa autenticación multi-factor
● No despliegues ninguna credencial por defecto, sobre todo para los
usuarios administradores.
● Implementa verificaciones de contraseñas débiles
● Limita o incrementa cada vez más los intentos de inicio de sesión
fallidos. Registra todos los intentos fallidos y alerta a los
administradores cuando se detecten ataques de credential stuffing, fuerza
bruta u otros.
● Usa un gestor de sesiones integrado y seguro que genere un nuevo ID de
sesión aleatorio luego del inicio de sesión.
● Los IDs también deben estar almacenados de forma segura y ser invalidados
luego de cerrar la sesión, tiempos de inactividad y tiempos absolutos.

23. c. Exposición a datos sensibles
En julio de 2018, Chrome comenzó a marcar todas las páginas
utilizando HTTP como no seguro en un impulso para convertir la web
a HTTPS . Y por una buena razón. Los datos que se pasan a través
de HTTP no están encriptados.
Prevención: el cifrado es la mejor manera de prevenir la exposición
de datos confidenciales, deben estar protegidos con protocolos como
TLS y SSL.
Se recomienda utilizar cifrados perfectos de seguridad directa (PFS),
priorización de cifrado por el servidor y parámetros seguros.
Proteja los datos en reposo cifrando los datos almacenados cuando
sea posible.
Nunca almacene contraseñas como texto sin formato, es preferible
utilizar “la sal” y cifrar con funciones hash como Argon2 y scrypt.

24. D. ENTIDADES EXTERNAS XML
Un analizador XML es engañado
para que haga referencia a una
entidad externa manipulada.
El ataque puede llevar a datos
confidenciales comprometidos,
ataques de denegación de servicio
(DoS) y falsificaciones de solicitudes
del lado del servidor (SSRF), entre
otros impactos del sistema.
Prevención: deshabilitar las entidades externas y el procesamiento DTD (definición del tipo de documento) en todos
los analizadores XML de la aplicación.
Evitar la serialización de datos confidenciales y utilizar formatos de datos menos complejos, como JSON.
Mantenga al día todos los procesadores XML y las bibliotecas.
Implementar la validación de entrada del lado del servidor (por ejemplo, listas blancas).

25. F. Proyectos de código de owaspSe divide en dos:

26. Ejemplos

27. G.-Proyecto de seguridad backend OWASP
El objetivo de este proyecto OWASP es crear una nueva
guía que permita a los desarrolladores, administradores y
evaluadores comprender cualquier parte del proceso de
seguridad acerca de los componentes de back-end que se
comunican directamente con las aplicaciones web, así
como las bases de datos, ldaps, pasarela de pago, y mucho
más.
El proyecto está compuesto por tres secciones (desarrollo
de seguridad, fortalecimiento de seguridad y pruebas de
seguridad). El objetivo es definir las directrices para las
empresas y los profesionales de TI que trabajan en el
campo de la seguridad en el desarrollo de procesos y la
gestión / pruebas de componentes de back-end en la
arquitectura empresarial.

28. 14 ConTROL DE ACCESO REMOTO

29. 14 Configuración de seguridad incorrecta

30. 15. Secuencias de comandos entre sitios
● Mediante correos
engañosos.
● Atacantes utilizan un
buscador insertando un
mensaje de alerta en
JavaScript o mensaje
en HTML.

31. CÓMO IDENTIFICAR ESTA VULNERABILIDAD
Las aplicaciones ofrecen páginas de salida utilizando
intérpretes como:
● JavaScript
● ActiveX
● Flash o Silverlight.
dificultando la detección automática de las vulnerabilidades
de XSS, sin embargo se podrían obviar aplicando técnicas de
revisión de código y pruebas de penetración en forma manual.

32. PREVENCIÓN
● Separar los datos no confiables basados en HTML del
contenido activo del navegador, para ello OWASP ofrece
algunos de trucos o “cheat Sheets” para aplicar las
técnicas en las rutinas de programación de una
aplicación WEB.
● Se deben validar las entradas positivas o de lista
blanca.

33. 16. Usos de componentes con vulnerabilidad
desconocida
La aplicación es vulnerable si:
● No conoce las versiones de todos los componentes que utiliza (tanto del lado del cliente
como del servidor). Esto incluye componentes utilizados directamente como sus
dependencias anidadas.
● No se analizan los componentes periódicamente ni se realiza seguimiento de los boletines de
seguridad de los componentes utilizados.
● El software es vulnerable, no posee soporte o se encuentra desactualizado. Esto incluye el
sistema operativo, servidor web o de aplicaciones, DBMS, APIs y todos los componentes,
ambientes de ejecución y bibliotecas

34. 16. Usos de componentes con vulnerabilidad
desconocida
Cómo se previene
● Remover dependencias, funcionalidades, componentes, archivos y documentación innecesaria y no
utilizada.
● Utilizar una herramienta para mantener un inventario de versiones de componentes (por ej.
frameworkso bibliotecas) tanto del cliente como del servidor. Por ejemplo, Dependency Checky
retire.js.
● Obtener componentes únicamente de orígenes oficiales utilizando canales seguros. Utilizar
preferentemente paquetes firmados con el fin de reducir las probabilidades de uso de versiones
manipuladas maliciosamente

35. 16. Usos de componentes con vulnerabilidad
desconocida

36. 16. Usos de componentes con vulnerabilidad
desconocida
Ejemplos de escenarios de ataque
Escenario #1: típicamente, los componentes se ejecutan con los mismos
privilegios de la aplicación que los contienen y, como consecuencia, fallas en
éstos pueden resultar en impactos serios. Estas fallas pueden ser accidentales
(por ejemplo, errores de codificación) o intencionales (una puerta trasera en un
componente).

38. Referencias
Sierra, T. (2019). Tipos de vulnerabilidades en aplicaciones
web | Tomás Sierra. Retrieved from
https://tomassierra.com/tipos-de-vulnerabilidades-en-
aplicaciones-web/