OWASP

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.
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.
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.
3. ¿Cuáles son las vulnerabilidades comunes de
seguridad de las aplicaciones web?
4.PRUEBAS DE SEGURIDAD
a. Recopilación de Información

Probar la mayor Análisis de Descubrimiento

cantidad de base código de error de aplicaciones
de código
Spiders, robots,
crawlers
Información
sobre la Formas Revisión de
aplicación comentarios y
metadata
Reconocimiento
Pruebas de Identificación
mediante
intrusión puntos de
motores de
entrada/salida
búsqueda
B. PRUEBAS DE GESTIÓN DE LA CONFIGURACIÓN
Código
Obtener fuente
datos Métodos
HTTP

Análisis sobre
la
infraestructura
o topología Configuraciones
Funcionalidades de la
Administrativas infraestructura
Métodos de
Autenticación
 1
VPer
uset
ibba
N
usl
udm
la IST e
pr co S ScoS
ot nf P nLg/
ec id 80 TuLe
ci en 0- Ste
ón ci 5
de alid 2, 3 m
laa D
d E
pu
y S
in s

2
te SH o
V Pr grid A1 AE
de esue ad p S
. ara pa
la tibbas r
B ul d la a
D um e
r
coec
ngep
uetor
te de
m e
pu sc
3 s uc
ha
VGe
st
ibó
En unl
qu co
udm
e
im e p ntra ecx
cr po ue r a otne
ed rta a rc d ngsu
en nt n u hiv ieo
ci e s sa os
al ntee
es ob rse sin
. re ms
la par refe pdue
in a o re
fra b nc
sa
4

es ten ia
rc
hi
V A r
tru er u
c i n ol vo
tu v
se esch ra form ida
gu tibivo o d
la aci os
En r u
id lu a s s ó n
qu co ad m nt
im e n i
p tra co gu
cr po ue r a ng os
ed rta da rc
en nt n u hiv ue , c
ci e s sa os
al teopi
es ob rse sin
. re
m as
pu d
la par refe
in a o re
fra
s e
5

bt nc
e ia
b.pruebas de gestión de la configuración

es
tru ner u
VPer ct in olv
ur fo id
sute a r a
o ma do
ib a la s
uls s ción
Lo um
co
el q
i
im i e m u ncfi
ong
ex ple a o n n
in plo m se es r guura
eci
st ta en a e teón
al c ta n s ma
ac ió c te en pup
ió n ión s d ci
n. po e l a slic
st pa la de ac
er ra be ió
io e
r a vi n
la tar
la
c. Pruebas lógicas de negociación

● manipular los
parámetros
Requiere mayor nivel de para comprobar si es ● datos de entrada
ya que gestiona varios ● moulos
creatividad por parte del posible evadir el flujo de
procesos diferentes ● con códigos
especialista en seguridades trabajo
dañinos
d. pruebas de autenticación
Se incluyen las pruebas de fortaleza
Es el proceso de intentar de los sistemas de preguntas y
verificar la identidad digital respuestas, cambio y reinicio de
del remitente de la contraseñas, políticas de creación
comunicación de contraseñas y descubrimiento
de mecanismo de autentificación

múltiples factores de
autenticación
● enumeración de usuarios
● pruebas de diccionario sobre pruebas de gestión de
cuentas de usuario caché de navegación
● comprobar sistemas de
recordatorio/ restauración de
contraseñas
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.
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
7. pruebas de 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, ataques locale/Unicode, sobre el sistema de

archivos y desbordamientos de búfer.

7. pruebas de negación de servicio
El tipo más común de ataque de Denegación de Servicio (Dos) es del tipo

empleado en una red para hacer inalcanzable a la comunicación a un

servidor por parte de otros usuarios válidos. 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).
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.
¿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.
· Para cualquier consulta dinámica residual, escapa los caracteres residuales usando la
sintaxis de escape específica para ese intérprete.
· 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
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.
¿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.
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.
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).
 F. Proyectos de código de owasp
Se divide en dos:
Ejemplos
14
14
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.
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.
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.
16. Usos de componentes con vulnerabilidad
desconocida
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
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
16. Usos de componentes con vulnerabilidad
desconocida
https://www.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf

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).

subnetin