1. OWASP es una comunidad abierta dedicada a mejorar la seguridad de aplicaciones web. Publica listas de vulnerabilidades comunes como la OWASP Top 10 y herramientas gratuitas como ZAP. 2. Algunas vulnerabilidades comunes incluyen configuraciones débiles, comunicaciones no encriptadas, y software desactualizado. 3. OWASP recomienda pruebas como la recopilación de información, pruebas de configuración, autenticación, autorización, validación de datos y denegación de servicio.

1. INGENIERÍA EN SISTEMAS E INFORMÁTICA
Tema:
OWASP
Proyecto Integrador II
Tutor:
EDGAR FERNANDO SOLÍS A.
SANGOLQUÍ-ECUADOR

2. A. ¿Qué es OWASP #1
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.
B. ¿Por qué es relevante OWASP? #2
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. Las 10 vulnerabilidades más importantes son
examinadas por los miembros y las organizaciones contribuyentes, y son
problemas del mundo real, no debería haber instancias de estas
vulnerabilidades en el código
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. OWASP y un gran grupo de voluntarios
mantienen el código y la lista de vulnerabilidades.

3. 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.
C. ¿Cuáles son las vulnerabilidades comunes de seguridad de las
aplicaciones web? #3
–Configuración débil, por defecto o mal configurado. Esto suele producirse
por intentar desplegar el servicio lo más rápido posible o por una confianza
excesiva en el software utilizado, incluso por desconocimiento. Cuando se
expone a Internet un sistema con su configuración por defecto, si se encuentra
una vulnerabilidad en el mismo, el exploit por defecto funcionará. Es necesario
revisar el servicio a desplegar y buscar una configuración suficientemente
fuerte.
– Comunicación insegura entre cliente y servidor. Es muy importante que
la comunicación entre cliente y servidor esté cifrada, sobre todo, cuando se
trata de envíos de formularios, por ejemplo, para autentificarse en sitio web. En
muchas ocasiones, se configura el sitio web para usar cifrado, con una
configuración débil, permitiendo protocolos inseguros, como SSLv2 y SSLv3,
o suites de cifrado vulnerables, como MD5. Esto dará una falsa sensación de
seguridad, el cliente verá que hay un certificado, que el sitio web,
aparentemente está cifrado, y, sin embargo, por culpa de los protocolos
permitidos, podría ser relativamente fácil descifrar esta comunicación. Es por
ello que es necesario revisar el estado de la calidad en la configuración de
nuestros certificados.

4. – Software desactualizado. Una vez desplegado el sistema,
independientemente de que se hiciese el trabajo correctamente, pasado el
tiempo, el software se desactualiza. Se localizan vulnerabilidades, se corrigen
en versiones posteriores, etc. Es necesario llevar un control de las versiones
utilizadas, así como mantener el software actualizado, en el menor tiempo
posible, desde que se libera una nueva versión. En caso contrario, al cabo de
un tiempo, nuestro sistema será vulnerable y existirán exploits públicos que
permitirán atacarlo.
Tipos de vulnerabilidades de aplicación
Cross-Site Scripting (XSS)
XSS, del inglés Cross-site scripting es un tipo de vulnerabilidad o agujero de
seguridad típico de las aplicaciones Web, que permite a un usuario
malintencionado inyectar código JavaScript en páginas web visitadas.
Un atacante puede realizar una petición post inyectando un string.
Multiple Cross-Site Scripting (XSS)
Se realizan múltiples ataques de XSS lo cual permite a un usuario
malintencionado inyectar código JavaScript en páginas web visitadas.
Stored XSS (inyección de código almacenado)
Se trata de uno de los ataques más peligrosos ya que el código que inyecta el
atacante se almacena en tu base de datos.
Los ataques almacenados son aquellos en los que el script insertado se
almacena permanentemente en los servidores de destino, como en una base

5. de datos, foro de mensajes, registro de visitantes, campo de comentarios, etc.
La víctima recupera el script malicioso del servidor cuando solicita la
información almacenada. Stored XSS también se conoce como Persistent o
Type-I XSS.
Unauthenticated Stored XSS
Un usuario no autenticado o un usuario sin privilegios, que puede enviar un
evento, puede insertar código JavaScript en la páginas web a través del
navegador.
Se ejemplifica donde un usuario sin privilegios, que puede enviar un evento,
puede insertar código JavaScript en la miniatura del mapa de Google Maps y
la víctima será cualquier usuario que visite la web y vea el mapa.
SQL Injection
Aprovechando un fallo en la programación de la aplicación, un usuario puede
ejecutar consultas en el navegador de la víctima. Estas consulta sirven para
ver o recopilar información sobre la aplicación atacada y todos sus datos.
CSRF
Authenticated Stored XSS & CSRF
El CSRF (del inglés Cross-site request forgery o falsificación de petición en
sitios cruzados) es un tipo de exploit malicioso de un sitio web en el que
comandos no autorizados son transmitidos por un usuario en el cual el sitio
web confía.

6. Server Side Request Forgery (SSRF)
Se refiere a un ataque en el que un atacante puede enviar una solicitud
elaborada desde una aplicación web vulnerable. La SSRF generalmente se
utiliza para atacar sistemas internos detrás de firewalls que normalmente no
son accesibles para un atacante desde la red externa. Además, también es
posible que un atacante aproveche la SSRF para acceder a los servicios desde
el mismo servidor que está escuchando en la interfaz loopback (127.0.0.1)
D. Pruebas de Seguridad Según OWASP
a. Recopilacion de Informacion #4
Fase primordial para evaluación de seguridad, en la cual se debe
recoger tanta información como sea posible sobre la aplicación y es
necesario para las pruebas de intrusión.
La prueba de seguridad debe esforzarse por probar la mayor cantidad
posible de la base del código. Por lo tanto, la asignación de todos los
caminos posibles a través del código para facilitar las pruebas
completas es primordial.
Existen varias formas de lograrlo, por ejemplo herramientas públicas
(motores de búsqueda), escáneres, envío de solicitudes HTTP simples
o solicitudes especialmente diseñadas, es posible forzar a la aplicación
a filtrar información, por ejemplo, revelar mensajes de error o revelar las
versiones y tecnologías utilizadas.

7. Spiders, robots y crawlers: Explorar y capturar recursos relacionados
con la aplicación que se está probando.
Análisis de códigos de error: Durante una prueba de penetración, las
aplicaciones web pueden divulgar información que no debe ser vista por
un usuario final. La información como los códigos de error puede
informar al probador sobre las tecnologías y los productos que utiliza la
aplicación.
En muchos casos, los códigos de error pueden invocarse fácilmente sin
la necesidad de habilidades o herramientas especializadas, debido a la
mala excepción en el diseño y la codificación.
Identificación puntos de entrada/salida: Identificar y mapear cada
área dentro de la aplicación, además de los puntos de salida funcionales
de la aplicación y los puntos donde la aplicación pasa a otra aplicación.

8. b. Pruebas de Gestión de la Configuración #4
Los análisis sobre la infraestructura o topología de la arquitectura
pueden revelar datos importantes sobre una aplicación web. Se pueden
obtener datos como por ejemplo el código fuente, los métodos HTTP
permitidos, funcionalidades administrativas, métodos de autenticación y
configuraciones de la infraestructura.
La gestión adecuada de la configuración de la infraestructura del
servidor web es muy importante para preservar la seguridad de la
aplicación. Si elementos como el software del servidor web, los
servidores de bases de datos de back-end o los servidores de
autenticación no se revisan y protegen adecuadamente, podrían
presentar riesgos no deseados o introducir nuevas vulnerabilidades que
podrían comprometer la aplicación en sí.
Las verificaciones que se pueden realizar son:
● Pruebas de SSL/TLS: SSL es el acrónimo de Secure Sockets
Layer (capa de sockets seguros), la tecnología estándar para
mantener segura una conexión a Internet, así como para proteger
cualquier información confidencial que se envía entre dos
sistemas e impedir que los delincuentes lean y modifiquen
cualquier dato que se transfiera. Los siguientes estándares se
pueden usar como referencia al evaluar los servidores SSL son
NIST SP 800-52 (recomienda que los sistemas federales de EE.
UU. Utilicen al menos TLS 1.0 con conjuntos de cifrados basados

9. en el acuerdo de clave RSA o DSA con el efímero Diffie-Hellman),
3DES o AES para la confidencialidad y SHA1 para la protección
de la integridad. NIST SP 800-52 no permite específicamente los
algoritmos no compatibles con FIPS como RC4 y MD5. Una
excepción son los sistemas federales de los EE. UU. Que
realizan conexiones a servidores externos, donde estos
algoritmos se pueden usar en el modo de cliente SSL.
● Pruebas del receptor de escucha de la BD: La escucha de la
base de datos es un demonio de red exclusivo de las bases de
datos Oracle. Espera solicitudes de conexión de clientes
remotos. Este demonio a veces puede verse comprometido y, por
lo tanto, puede afectar la disponibilidad de la base de datos o la
validez de los datos almacenados en ella.
● Pruebas de gestión de configuración de la aplicación: La
configuración adecuada de los elementos individuales que
conforman la arquitectura de una aplicación es importante para
evitar errores que puedan comprometer la seguridad de toda la
arquitectura. La revisión y prueba de la configuración es una
tarea crítica en la creación y el mantenimiento de una
arquitectura. Esto se debe a que a muchos sistemas diferentes
generalmente se les proporcionarán configuraciones genéricas
que pueden no ser adecuadas para la tarea que realizarán en el
sitio específico en el que están instalados. Si bien la instalación

10. típica del servidor de aplicaciones y la web contendrá una gran
cantidad de funcionalidades (como ejemplos de aplicaciones,
documentación, páginas de prueba), lo que no es esencial debe
eliminarse antes de la implementación para evitar la explotación
posterior a la instalación.
● Gestión de extensiones de archivo
● Archivos antiguos, copias de seguridad y sin referencias, entre
otras.
c. Pruebas de la lógica de negocio #5
Dentro de las fases de pruebas, esta es una en la que se requiere
mayor nivel de creatividad por parte del especialista de seguridad,
debido a que cada aplicación web gestiona procesos diferentes. Se
incluyen pruebas de seguridad para comprobar si es posible evadir el
flujo de trabajo, si es posible manipular los parámetros, datos de
entradas y módulos, si se impide la subida de archivos con extensiones
no consideradas dentro del proceso y con códigos dañinos. Si se
realizan comprobaciones de integridad y validación de datos de entrada.
d. Pruebas de autenticación #5
En esta fase se ejecutan pruebas de seguridad para evaluar el
proceso de autenticación. Dentro de las pruebas de seguridad
propuestas se encuentra el análisis para determinar si las credenciales
son transmitidas sobre un canal encriptado, identificación de
credenciales por defecto, comprobación de los mecanismos de bloqueo

11. de credenciales. También se incluye las pruebas de fortalezas de los
sistemas de preguntas y respuestas, cambio y reinicio de contraseñas,
políticas de creación de contraseñas y descubrimiento de mecanismos
de autenticación.
e. Pruebas de autorización #6
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 #6
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
g. Pruebas de validación de datos #7
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.
h. Pruebas de denegación de servicio #7

12. 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).
i. Pruebas de servicios web #8
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.
j. Pruebas ajax #8
AJAX, acrónimo de JavaScript Asíncrono y XML, es una técnica de
desarrollo web usada para crear aplicaciones web más interactivas y
con mejor facilidad de uso. Utiliza una combinación de tecnologías para
proveer una experiencia más parecida a utilizar una aplicación de

13. escritorio. Esto se lleva a cabo utilizando el objeto XMLHttpRequest y
JavaScript para hacer peticiones asíncronas al servidor web, analizando
las respuestas y posteriormente actualizando el DOM HTML y el CSS
de la página.
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
E. Proyectos emblemáticos de herramientas de OWASP (ejemplos) #9
Proyectos que han demostrado un valor estratégico para OWASP y la seguridad de
la aplicación en su conjunto.

14. OWASP Zed Attack Proxy (ZAP)
Encuentra automáticamente vulnerabilidades de seguridad en sus aplicaciones web
mientras desarrolla y prueba sus aplicaciones.
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.
Puede ayudarlo a encontrar automáticamente vulnerabilidades de seguridad en sus
aplicaciones web mientras desarrolla y prueba sus aplicaciones. También es una gran
herramienta para pentesters experimentados para usar en pruebas de seguridad
manuales.
F. Proyectos de código de owasp (ejemplos) #10
Se divide en dos:
1. OWASP ModSecurity Core Rule Set (CRS)

15. Conjunto de reglas de detección de ataques genéricas para su uso con
ModSecurity o firewalls de aplicaciones web compatibles cuyo objetivo es
proteger las aplicaciones web de una amplia gama de ataques.
2. OWASP CSRFGuard
Una biblioteca que implementa una variante del patrón de token del
sincronizador para mitigar el riesgo de ataques de falsificación de solicitudes
entre sitios “Cross-Site Request Forgery”(CSRF).
Arquitectura CSRFGuard

16. EJEMPLO:
Contiene error.
Prueba de caja gris
G. Proyectos de documentación owasp (ejemplos ) #11
H. Fallas de seguridad de las aplicaciones web
a. Inyección #12
Una inyección de código 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 para hacer.
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.

17. 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?
Prevenir inyecciones requiere mantener los datos separados de los
comandos y las consultas.
● 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 #12
Una vulnerabilidad de autenticación rota les 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.

18. 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?
Estas son las recomendaciones técnicas de OWASP:
● Siempre que sea posible, implementa autenticación multi-factor
para evitar ataques automáticos como credential stuffing, fuerza
bruta y utilización de credenciales robadas.
● No despliegues ninguna credencial por defecto, sobre todo para
los usuarios administradores.
● Implementa verificaciones de contraseñas débiles
● Asegura que el registro, la recuperación de credenciales y las
rutas de API están protegidas contra ataques de enumeración de
cuentas al escoger el mismo mensaje para todos los resultados.
● 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
de Sesiones nunca deben estar incluidos en las URLs.

19. ● 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 #13
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,
lo que pone en riesgo los nombres de usuario, las contraseñas, los números
de tarjetas de crédito, los registros de salud y otros datos confidenciales.
En lugar de atacar directamente el cifrado, los piratas informáticos prefieren
ejecutar ataques de intermediarios, robar claves o acceder a datos de texto sin
cifrar desde el servidor o el navegador del cliente. Cualquier dato almacenado
o transmitido sin cifrado es susceptible de ser atacado. Incluso cuando se
emplea criptografía, las claves débiles, la administración incorrecta de las
claves o los esquemas de rotación pueden comprometer la seguridad y
exponer datos confidenciales.
Prevención: el cifrado es la mejor manera de prevenir la exposición de datos
confidenciales. Todos los datos en tránsito 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.

20. d. Entidades externas xml #13
Extensible Markup Language (XML) es un formato de datos popular apreciado
por su extensibilidad y flexibilidad.
Un ataque de entidad externa XML (XXE) ocurre cuando 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.
El infame billón de risas DoS Attack es un excelente ejemplo de un ataque
XXE.
Prevención: la forma más sencilla de prevenir un ataque XXE es deshabilitar
las entidades externas y el procesamiento DTD (definición del tipo de
documento) en todos los analizadores XML de la aplicación. También es una
buena práctica 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 e implemente la validación de entrada del
lado del servidor (por ejemplo, listas blancas).
e. Control acceso remoto :Las restricciones de control de acceso
implican que los usuarios no pueden actuar fuera de los permisos
previstos. Típicamente, las fallas conducen a la divulgación,

21. modificación o destrucción de información no autorizada de los datos, o
a realizar una función de negocio fuera de los límites del usuario. Las
vulnerabilidades comunes de control de acceso incluyen:
• Pasar por alto las comprobaciones de control de acceso modificando
la URL, el estado interno de la aplicación o HTML, utilizando una
herramienta de ataque o una conexión vía API.
• Permitir que la clave primaria se cambie a la de otro usuario, pudiendo
ver o editar la cuenta de otra persona.
• Elevación de privilegios. Actuar como un usuario sin iniciar sesión, o
actuar como un administrador habiendo iniciado sesión como usuario
estándar
f. Mala configuración de la seguridad :
La aplicación puede ser vulnerable si:
• Falta hardening adecuado en cualquier parte del stack tecnológico, o
permisos mal configurados en los servicios de la nube.
• Se encuentran instaladas o habilitadas características innecesarias (ej.
puertos, servicios, páginas, cuentas o permisos).
• Las cuentas predeterminadas y sus contraseñas siguen activas y sin
cambios.
• El manejo de errores revela a los usuarios trazas de la aplicación u
otros mensajes demasiado informativos.
g. Secuencias de comandos entre sitios #15
La secuencia de comandos en sitios cruzados, más conocida como XSS, es en
realidad un subconjunto de inyección HTML. XSS es la más prevaleciente y perniciosa
problemática de seguridad en aplicaciones Web. Las fallas de XSS ocurren cuando

22. una aplicación toma información originada por un usuario y la envía a un navegador
Web sin primero validarla o codificando el contenido.
● XSS permite a los atacantes ejecutar secuencias de comandos en el
navegador Web de la víctima, quienes pueden secuestrar sesiones de usuario,
modificar sitios Web, insertar contenido hostil, realizar ataques de phising, y
tomar control del navegador Web del usuario utilizando secuencias de
comando maliciosas.
● Generalmente JavaScript es utilizado, pero cualquier lenguaje de secuencia de
comandos soportado por el navegador de la victima es un potencial objetivo
para este ataque.
Vulnerabilidad
Existen tres tipos conocidos de secuencias de comandos en sitios cruzados: reflejado,
almacenado e inyección DOM. XSS reflejado es el más fácil para explotar – una
página reflejara información suministrada por el usuario directamente de vuelta al
usuario:
echo $_REQUEST['userinput'];
XSS almacenado toma información hostil, la almacena en un fichero, una base de
datos, u otro sistema de almacenamiento, y luego en una etapa posterior, muestra
dicha información sin filtrado alguno. Esto es extremadamente peligroso en sistemas
de administración de contenidos (CMS), blogs, o foros, donde un gran número de
usuarios accederá a la información introducida por otros usuarios.
Con ataques basados en inyección DOM, el código JavaScript del sitio Web y sus
variables son manipuladas, en lugar de los elementos HTML.
Alternativamente, los ataques pueden ser una mezcla o un híbrido de los tres tipos
mencionados anteriormente. El peligro con la secuencia de comandos en sitios

23. cruzados no es el tipo de ataque, sino la posibilidad del mismo. Un comportamiento
fuera del estándar o inesperado del navegador Web puede introducir sutiles vectores
de ataque.
Verificando la seguridad
El objetivo es verificar que todos los parámetros en la aplicación sean validados y/o
codificados antes de ser incluidos en paginas HTML.
● Verificación automatizada: herramientas automáticas de testeo de
penetración son capaces de detectar XSS reflejado a través de inyección de
parámetros, pero generalmente fallan a la hora de encontrar XSS persistente,
particularmente si la salida del vector XSS inyectado es restringida a través de
pruebas de autorización (tales como si un usuario introduce información hostil
que puede ser visualizada solamente por los administradores de la aplicación).
● Verificación manual: si se ha utilizado un mecanismo centralizado de
validación y codificación, la manera más eficiente de controlar la seguridad es
revisando el código. Si en cambio, se ha utilizado una implementación
distribuida, entonces la verificación tomará considerablemente mucho más
tiempo.
h. Deserializacion insegura #15
i. Uso de componentes con vulnerabilidades conocidas #16
j. Insuficiente registro y monitoreo. #16

24. Bibliografia
Sierra, T. (2019). Tipos de vulnerabilidades en aplicaciones web | Tomás Sierra.
Retrieved from https://tomassierra.com/tipos-de-vulnerabilidades-en-aplicaciones-
web/(vulnerabilidades comunes de aplicaciones web)
https://www.upwork.com/hiring/development/cybersecurity-basics-owasp-top-10-
critical-web-application-security-risks/
https://seguridadaguijon.blogspot.com/2018/03/que-es-owasp.html
https://www.owasp.org/images/2/2f/OWASP_SUSCERTE.pdf
https://www.owasp.org/index.php/Main_Page