Tema6 PDF

Test de la seguridad y protección online
de los servicios web

[6.1] ¿Cómo estudiar este tema?
[6.2] Evaluación de la seguridad de los servicios web
[6.3] Protección online. Firewalls y gateways XML
[6.4] Referencias
TEMA
Test de la seguridad y protección online de los servicios web
Esquema
TEMA 6 – Esquema
TEST DE LA SEGURIDAD Y
PROTECCIÓN ONLINE DE LOS
SERVICIOS WEB
Evaluación de la seguridad de los

servicios web Protección online de los
SSDLC: servicios web
Requisitos de seguridad Operaciones de seguridad online
Análisis de riesgos Gateways XML
Evaluación funcional de seguridad SW Firewalls XML
Análisis de seguridad del código
Test de penetración
Herramientas
© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones Online
Ideas clave
6.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave que encontrarás a continuación.
En este tema se repasan las metodologías, técnicas y herramientas para analizar la

seguridad de los servicios web dentro de un esquema ciclo de vida de desarrollo seguro
(SSDL) de servicios web donde se deben realizar una serie de actividades de seguridad
en cada una de las fases del ciclo de vida.
Se introducen mecanismos de defensa online como son operaciones de configuración

segura y de monitorización, así como los gateways y firewalls XML. Es necesario previo
al despliegue y en todo momento conocer el estado real de la seguridad de los servicios
web desplegados en una organización, para lo cual hay que conocer los métodos y
herramientas disponibles para evaluar su seguridad.
6.2. Evaluación de la seguridad de los servicios web
Las características de los servicios web hacen las pruebas de seguridad más difíciles
que para las aplicaciones más tradicionales. El modelo de servicios web proporciona un
mecanismo totalmente independiente de la implementación a través del cual las
aplicaciones pueden interactuar. El probador puede hacer suposiciones precisas acerca
de cómo se construye ese software de aplicación. Los evaluadores dependen en gran
medida de su comprensión del software en su interfaz y de las especificaciones del
sistema.
La naturaleza altamente distribuida de la tecnología de servicios web crea una

dependencia entre interacciones complejas que deben ser comprobables. El
probador tendrá que adoptar nuevas técnicas y procesos para muchos de los aspectos de
las pruebas de seguridad de servicios web. La prueba de la funcionalidad de seguridad,
en particular, requerirá un mayor uso de los agentes de test distribuidos y
tecnologías relacionadas.
TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Idealmente, el probador trazaría todos los caminos a través del código y todas las
interfaces internas entre los componentes dentro del servicio y todas las interfaces
externas entre el servicio y otros servicios y probar cada posible entrada para
asegurarse de que no causó una violación de seguridad inesperada.
Dependiendo de la complejidad del servicio la prueba de cada ruta posible, interfaz, y de

entrada puede no ser factible. Un objetivo más práctico es cubrir todos los caminos a
través de cada unidad y entre unidades y la interfaz externa al menos una vez.
El análisis de la seguridad de servicios web en la práctica tendrá dos vertientes:
» Una la más deseable sería analizar la seguridad durante el ciclo de vida de desarrollo
de software, que sería la más deseable.
» La otra analizar la seguridad de los servicios web ya en una instalación en producción
a modo de auditoría.
Para llevar a cabo la evaluación de la seguridad en el ámbito de servicios web se debe

incluir en el ciclo de vida de desarrollo Seguro la planificación de todas las actividades y
pruebas o test de seguridad de la misma forma que se hace para todos los tipos de
aplicaciones y se debe realizar iterativamente, según se puede consultar en Building
security In (McGraw, 2006) (ver figura siguiente). El grado de importancia de cada
actividad se muestra en los círculos negros.
Figura 1. Modelo de SSDL de MacGraw

» 1: Modelado de amenazas y casos de abuso.

» 2: Análisis de los requisitos de seguridad.
» 3: Análisis de riesgos de la arquitectura.
» 4: Pruebas funcionales de seguridad basadas en el riesgo.
» 5: Revisión del código.
» 6: Pruebas de penetración.
» 7: Operaciones de seguridad online.
» 8: Evaluación externa independiente.
Actividades de análisis de la seguridad en SW
A continuación se describen cada una de las actividades de análisis de seguridad desde

el punto de vista de los servicios web, contestando varias preguntas:
» Modelado de amenazas y casos de abuso.
o ¿En qué consisten? El resultado de estas actividades junto con el análisis de

riesgos de la arquitectura es un listado de amenazas y de casos de abuso que los
SW pueden tener que pueden dar lugar a que se materialicen ataques concretos.
Los casos de abuso son lo contrario de los casos de uso dentro del modelado
unificado de datos UML, como su propio nombre indica. Los casos de abuso son
casos en los que se puede comprometer alguna funcionalidad de los SW.
o ¿Cuándo se deben llevar a cabo? En la fase de análisis de requisitos y de diseño

de la arquitectura en el marco del SSDLC o en el instante que se solicite si es una
auditoría. En ambos casos es la primera actividad de análisis a realizar en conjunto
con las siguientes fases de modelados de amenazas y análisis de riesgos de la
arquitectura que determinarán las necesidades de requisitos y mecanismos de
defensas.
Si estamos en el caso de una auditoría todas estas actividades se realizan en una

primera fase de análisis, antes de las pruebas funcionales de seguridad.

o ¿Quién las debe llevar a cabo? En el caso de estar en SSDLC, el personal

desarrollador sí tiene experiencia en seguridad únicamente, el personal del
departamento de seguridad o de forma mixta. En el caso de ser una auditoria puede
ser el departamento de seguridad de la organización o personal externo contratado.
o ¿Cómo se debe realizar? Para la actividad de modelado de amenazas se puede

seguir la metodología Stride de Microsoft https://www.microsoft.com/en-
us/sdl/adopt/threatmodeling.aspx que proporciona una herramienta que permite
derivar las amenazas de una aplicación utilizada por servicios web. Una
metodología para derivar casos de abuso. Se puede consultar Building Security In
(McGraw, 2006), resumida en el siguiente esquema de la figura 2:
Figura 2. Metodología de derivación de casos de abuso

En la siguiente tabla se muestra un ejemplo de caso de abuso en comparación a un caso

de uso:
Caso de uso Caso de abuso

» Una interacción completa entre » Una familia de interacciones
uno o varios actores y un completas entre uno o varios
sistema. actores y un sistema que
» Basado en diagramas UML. resulta dañado.
» Típicamente descrito usando » Basado en diagramas UML.
lenguaje natural. » Típicamente descrito
usando lenguaje natural.
» Conjunto de clases de abuso
de privilegios y de
componentes que podrían
ser explotados.
» Incluye una descripción de
la gama de los privilegios y
de componentes que
podrían ser explotados.
» Incluye una descripción de
la gama de los privilegios de
seguridad que pueden ser
abusados.
» Incluye una descripción del
daño que resulta de un caso
de abuso.
Tabla 1. Caso de uso, caso de abuso.
» Análisis de los requisitos de seguridad.
o ¿En qué consiste? Esta actividad consiste en realizar un estudio de los requisitos
de seguridad que son necesarios para implementar la seguridad de la
comunicación y del almacenamiento de información entre los servicios web que
intervienen ya sean consumidores o proveedores del servicio. Como resultado se
obtiene una lista de funciones y mecanismos de seguridad necesarios para
conseguir los elementos de seguridad: Confidencialidad, autenticación,
autorización, integridad, no repudio, trazabilidad, rendimiento y disponibilidad.

o ¿Cuándo se deben llevar a cabo? En la fase de análisis de requisitos y de diseño

de la arquitectura en el marco del SSDLC o en el instante que se solicite si es una
auditoría. En ambos casos se realiza en conjunto con las actividades de modelados
de amenazas y análisis de riesgos de la arquitectura que determinarán las
necesidades de requisitos y mecanismos de defensas.
Si estamos en el caso de una auditoría, todas estas actividades se realizan en una

primera fase de análisis antes de las pruebas funcionales de seguridad, revisión de
código, etc.
o ¿Quién las debe llevar a cabo? En el caso de estar en SSDLC, el personal

desarrollador sí tiene experiencia en seguridad únicamente, el personal del
departamento de seguridad o de forma mixta. En el caso de ser una auditoria puede
ser el departamento de seguridad de la organización o personal externo contratado.
o ¿Cómo se debe realizar? Para derivar los requisitos de seguridad se pueden

emplear metodologías de ingenierías de requisitos como Square
http://resources.sei.cmu.edu/asset_files/TechnicalReport/2005_005_001_1459
4.pdf del CERT de la Universidad Carnige Mellon de EE. UU.
En esta metodología se utilizan árboles de ataque, modelado de casos de abuso y

análisis de riesgo conjuntamente para derivar los requisitos de seguridad, es decir,
el modelado de amenazas, derivación de casos de abuso, análisis de riesgos y
derivación de requisitos final se realizan como se muestra en la siguiente figura, en
las fases de análisis y diseño del SSDLC

Figura 3. Metodología de ingeniería de requisitos SQUARE

Resumiendo, el proceso de derivación de requisitos de seguridad:
o Partiendo de los objetivos de negocio y de calidad se obtienen y revisan los

requisitos funcionales a la vez que se identifican y revisan los objetivos de
seguridad que se verifican y validan contra los activos, amenazas y objetivos de
negocio.
o En una segunda fase se identifican los requisitos de seguridad, se revisan y se
verifican.
o Si son factibles los requisitos de seguridad se validan frente a los objetivos de
seguridad.
o Se construye, revisa y se verifica la arquitectura del sistema.
o Si es factible la arquitectura del sistema se valida su seguridad frente a los
requisitos de seguridad.
» Análisis de riesgos de la arquitectura.
o ¿En qué consiste? En un análisis de riesgos se modelan todos activos del sistema
en su ubicación real teniendo en cuenta el modelo de amenazas y casos de abuso
(nivel de riesgo) para obtener el impacto que la materialización de las amenazas
aprovechando las vulnerabilidades de seguridad puede tener en los activos.
Elementos que intervienen en el análisis de riesgos:
- Activo. Los objetos de los esfuerzos de protección. Pueden ser componentes del
sistema, datos o el sistema en su totalidad.
- Impacto. Degradación causada por una amenaza concreta en un activo.
- Riesgo. Cuando las amenazas pueden ocurrir con una cierta probabilidad sobre
un activo ocasionan un riesgo en el funcionamiento del activo y por tanto en el
sistema.
- Amenaza. Es el actor o el agente que es la fuente de peligro por diferentes
motivaciones como factores económicos, de prestigio u otros. Estas amenazas
pueden ser ataques como por ejemplo: inyección de SQL, ataques TCP/IP SYN,
desbordamientos de buffer, denegación de servicio, etc.
- Salvaguarda. Controles técnicos, operacionales y de gestión que se aplican a
un sistema y que conjuntamente lo protegen de la acción de las amenazas.

Figura 4. Elementos de un análisis de riesgos
o ¿Cuándo se debe llevar a cabo? Como se puede observar en la figura de abajo,

esta actividad está a caballo entre la fase de análisis y diseño, donde se obtienen los
requisitos de seguridad y casos de abuso de forma conjunta. Después de las pruebas
de penetración es necesario volver a actualizar el análisis de riesgos porque se han
encontrado nuevas vulnerabilidades que hay que solucionar.
Figura 5. Fases del análisis de riesgo

o ¿Quién las debe llevar a cabo? Personal del departamento de seguridad o

externo en el caso de una auditoría externa.
o ¿Cómo se debe realizar? En la fase de análisis al obtener los casos de abusos y

modelado de amenazas se han obtenido bastantes conclusiones acerca de los
activos del sistema y del impacto que los posibles ataques pueden causar.
Sin embargo, es en la actividad de análisis de riesgos de la arquitectura del sistema

y de su ubicación física real donde se especifican todos los activos porque se
obtienen todos los componentes hardware y software del sistema y se derivan los
requisitos de seguridad. También se deciden las salvaguardas concretas que van a
protegerlo en función del nivel de riesgo obtenido y del impacto que la
materialización de las amenazas tiene sobre los activos. Para cada riesgo los
controles pueden ser puestos en el lugar adecuado para prevenirlo o detectarlo
cuando se produce un ataque.
Metodologías estándar de riesgo que se pueden utilizar:
- Magerit.
- ASSET (Automated security self-evaluation tool). National institute on
standards and technology (NIST).
- Octave (Operationally critical threat, asset, and vulnerability evaluation). SEI
de la Universidad Carnegie Mellon.
- Cobit (Control Objectives for Information and Related Technology) from
information systems audit and control association (ISACA).

» Pruebas funcionales de seguridad:
o ¿En qué consisten? Prueban la eficacia de los mecanismos y funciones de

seguridad implementadas en los servicios web, en base al análisis del riesgo
obtenido previamente.
o ¿Cuándo se deben llevar a cabo? En la fase de pruebas del SSDLC o en fase de

producción si es una auditoría.
o ¿Quién las debe llevar a cabo? Personal del departamento de seguridad o

externo en el caso de una auditoría externa.
o ¿Cómo se debe realizar? Se deben de generar los casos de prueba necesarios

que permitan probar que las funciones y mecanismos de seguridad son los
adecuados. Es necesario también realizar un análisis de trazabilidad entre las
amenazas de seguridad y las funciones que contrarrestan cada una de ellas. Tres
capacidades son importantes en las herramientas utilizadas para probar la
seguridad de los servicios web:
- Generación y comprobación de mensajes de SOAP y XML: con el

examen de las dos interfaces de mensajería y el formato de mensajes
individuales.
- Generación automática de planes de pruebas a partir de archivos
WSDL que contienen metadatos sobre las interfaces de los servicios web a
testear.
- Simulación de las acciones de los proveedores y clientes.

» Revisión del código (ver tema 4).
o ¿En qué consiste? Esta actividad se trata en el tema 4. Como se comentó en

dicho tema consiste en revisar el código fuente con ayuda de herramientas de
análisis estático de código fuente Static analysis secutity tools (SAST) que lo
examinan en busca de vulnerabilidades como buffer overflow, sql injection, etc.
Revisar el tema 4 donde se explica la arquitectura y funcionamiento. Es una

actividad fundamental que cubre toda la superficie de ataque de una aplicación y
las herramientas SAST son capaces de encontrar un alto porcentaje de
vulnerabilidades. En la figura siguiente se puede ver un esquema de la arquitectura
de las herramientas SAST.
Figura 6. Arquitectura SAST.
o ¿Cuándo se debe llevar a cabo? En la fase de desarrollo o en fase de producción

si es una auditoría.
o ¿Quién las debe llevar a cabo? El personal de desarrollo sí está formado en la

actividad, el departamento de seguridad o de forma mixta.
o ¿Cómo se debe realizar? Como se comentó en el tema 3, la posibilidad de tener

falsos positivos (alertas falsas de vulnerabilidades) implica que hay que realizar
una auditoría del informe de salida de la herramienta para descartarlos.

» Pruebas de penetración (ver tema 4).
o ¿En qué consisten? Hay varias formas de llevarlas a cabo: con herramientas de
caja negra o con herramientas de caja blanca. Los scanners de vulnerabilidades de
aplicaciones web son herramientas de análisis dinámico de caja negra (DAST) que
intentan inyectar cadenas de datos malignas en los campos de entrada (interfaces)
de la aplicación que son accesibles externamente para tratar de descubrir
vulnerabilidades.
En base a las respuestas recibidas el scanner realiza un análisis sintáctico para

decidir si existe una vulnerabilidad. Esta decisión puede ser un falso positivo en
algunos casos por lo que es necesario hacer comprobaciones manuales de las
alertas de vulnerabilidad.
Las herramientas de análisis dinámico de caja blanca (IAST/RAST) se instalan de

forma que pueden observar el entorno de ejecución del proceso del servidor de
aplicaciones e incluso el código. Tienen información precisa de los valores de las
variables en tiempo de ejecución y no suelen tener falsos positivos. Normalmente
actúan en combinación con una herramienta DAST para confirmar las
vulnerabilidades que encuentran y entonces estamos en caso de herramientas
Híbridas.
Pueden actuar de tres formas:
- Informando de la existencia de vulnerabilidades.

- Bloqueando el ataque.
- Saneando la petición, eliminando la posibilidad de ataque.
o ¿Cuándo se deben llevar a cabo? En la fase de pruebas del SSDLC o en fase

de producción si es una auditoría. En el caso de las herramientas IAST se pueden
utilizar también en fase de producción bloqueando o saneando ataques.
o ¿Quién las debe llevar a cabo? Personal de seguridad especializado interno

o externo si es el caso de una auditoría externa.

o ¿Cómo se debe realizar? Lo mejor es utilizar herramientas híbridas

DAST+IAST que permiten confirmar la mayoría de las vulnerabilidades
obteniendo un resultado mucho más preciso. No obstante es necesario realizar
auditoría posterior para aquellas vulnerabilidades no confirmadas por la
herramienta IAST.
» Operaciones de seguridad online.
o ¿En qué consisten? Son todas aquellas actividades que tienen que ver con:
o Ejecutar los procedimientos de administración de control de acceso de forma

precisa.
o Actividades de monitorización de forma continua utilizando herramientas de
gestión de logs y de gestión de eventos de seguridad (SIEM) que incluyen
detectores de intrusión (IDS).
o Instalación de firewalls de nivel de aplicación, firewalls XML (ver apartado
siguiente) que permiten detener ataques que pueden sufrir los servicios web.
o Actividades de prueba de los procedimientos de backup y configuración.
o Gestión de incidentes de seguridad informática.
o ¿Cuándo se deben llevar a cabo? En fase de producción.

o ¿Quién las debe llevar a cabo? Tanto personal de administración de los
sistemas como los del departamento de seguridad en los casos de la gestión de
incidentes de seguridad que puedan detectarse.
Herramientas de análisis de la seguridad de SW
Los tipos de herramientas mencionados en el tema 4 para evaluar la seguridad de las

aplicaciones como: SAST de análisis estático white box, DAST de análisis dinámico, black
box de análisis dinámico, white box IAST e híbridas tienen capacidad para analizar la
existencia de vulnerabilidades en servicios web.
» Herramientas IAST:
o Seeker (quotium technologies).

o HP Fortyfy securityScope / RTA
o IBM APPSCAN glassbox.

» Herramientas DAST:
o Codenomicon.
o IBM.
o HP.
o Parasoft.
o Cenciz.
o Qualys.
o Netsparker.
» Herramientas SAST:
o Herramientas comerciales:
- Checkmarx.
- CodeSecure Armorize.
- CodeSonar gammatech.
- CoveritySave coverity.
- HP fortify source code analyzer.
- IBM rational appscan source edition.
- Klocwork insight.
- Development testing platform parasoft.
- bugScout buguroo.
- Eclair bugseng.
o Software-as-a-service:
- Fortify on demand fortify HP.

- Sentinel source whitehat.
- Veracode.
- CXCloud checkmarx.


o Free / open source tolos:
- FindBugs.
- FxCop.
- Lint.
- OWASP O2 Platform.
- PMD.
- PreFast.
- RATS – Rough auditing tool for security.
- Yasca.
- VisualCoeGrepper.
» Herramientas híbridas:
o HP Fortyfy hybrid analysis.

o IBM APPSCAN Enterprise.
o Acunetix + Acusensor.
o PHP Vulnerabillity hunter (open source).
o Whitehat sentinel.
o Acunetix+Acusensor.
» Herramientas específicas de análisis de seguridad de los servicios web:
o Soapsonar.
o SoapUI.
o wsScanner: herramientas para explorar y detectar vulnerabilidades WS en .NET.
o Wsfuzzer.
o WsBang.
o Wsdigger.
o Soapbox.
En las dos figuras siguientes se muestran varias pantallas de las herramientas

SOAPUI donde se aprecian los tipos de pruebas que se pueden llevar a cabo.

Figura 7. Soap UI
Fuente: http://resources.infosecinstitute.com/web-services-penetration-testing-part-2-automated-
approach-soapui-pro/
Figura 8. Soap UI
Fuente: http://resources.infosecinstitute.com/web-services-penetration-testing-part-2-automated-
approach-soapui-pro/

6.3. Protección online. Firewalls y gateways XML
El protocolo SOAP se soporta a través de http que se deja tradicionalmente abierto para
el tráfico web en los servidores de seguridad perimetrales. Además, con la llegada
de Liberty y SAML v2.0, los mensajes SOAP pueden pasar a través de gateways que
limitan el tráfico http entrante pero permiten el tráfico http saliente.
Algunos gateways han comenzado a bloquear o permitir peticiones SOAP basándose en

el origen o el destino de la solicitud pero se necesitan gateways más robustos e
inteligentes para defender las redes contra ataques maliciosos a SOAP (ver figura
sigueinte).
Una pasarela XML puede implementar servicios de autenticación, autorización,

confidencialidad, etc. y además implementar la funcionalidad de firewall XML para
protección ante ataques de inyección, denegación de servicio, validación de esquema o
XSS por poner algunos ejemplos.
Figura 9. Gateways XML

Para este fin se han desarrollado gateways XML para ofrecer la funcionalidad de
cortafuegos a nivel de aplicación específicamente para los servicios web. Los firewalls
de aplicaciones con conciencia no son nada nuevo sino que han existido en la forma de
proxies http para el tráfico basado en http y permitir a las organizaciones limitar lo que
un protocolo de capa de aplicación puede y no puede hacer.
Básicamente una pasarela XML actúa como el servicio web y transmite toda la
comunicación con el servicio web interno que actúa como intermediario entre los
servicios que no son de confianza y el servicio web interno. Los gateways XML
pueden proporcionar servicios como:
» Autenticación.
» Autorización.
» Confidencialidad de todo o de partes del mensaje XML.
» Integridad y no repudio mediante implementación de firma digital.
» Monitorización.
» Firewall de protección ante ataques, SQLi, XMLi, XSS, etc.
Varias pasarelas XML pueden utilizarse de forma conjunta para implementar un sistema
de gestión de identidades distribuido. En la actividad correspondiente al tema se
establece una comunicación entre servicios web implementando la seguridad mediante
pasarelas XML, conformado un sistema de gestión de identidades distribuido a la vez
que implementa la función de firewall XML (ver figura anterior).

En la actividad se implementan los servicios de autenticación, integridad, no repudio,

confidencialidad y capacidad de firewall XML en tres servicios web, consumidor, de
compra de libros y de pago de las compras efectuadas. La solución que se utiliza es una
implementación de gateway+firewall XML, de software libre de Corisecio y Eperi.
Figura 10. Gateways Xml +firewall XML
En la figura de abajo se muestra un ejemplo de un mensaje XML de comunicación que

muestra cifrados los datos de una orden de compra de libros. Para el cifrado de los datos
de la orden se utilizan tanto algoritmos de clave simétrica como de clave pública.
Este es un ejemplo de cifrado de una parte del mensaje para proporcionar seguridad de
extremo a extremo que no puede proporcionar la seguridad a nivel de transporte
mediante protocolos como SSL o TLS.

Son necesarios para proporcionar seguridad de extremo a extremo, tanto el cifrado a

nivel de capa de transporte como el cifrado XML que pueden proporcionar servicios
como XML encryption de W3C implementados en pasarelas XML.
Figura 11. Orden de compra cifrada de la actividad de seguridad de SW
Los firewalls XML: pueden restringir el acceso en función del origen, destino o de
tokens de autenticación WS-Security. También admiten la validación del esquema y
algunas ofrecen apoyo para la prevención de intrusiones de SOAP contra los siguientes
ataques y otros que aprovechan las vulnerabilidades nativas de XML y servicios basados
en XML:
» Escaneo WSDL. Intenta recuperar el WSDL de los servicios web para obtener
información que puede ser útil para un ataque.
» Manipulación de parámetros. Modificación de los parámetros de un servicio web
espera recibir en un intento de eludir la validación de entrada y obtener acceso no
autorizado a algunas funciones.
» Ataques de repetición. Los intentos para reenviar solicitudes SOAP a repetir las
transacciones sensibles.
» Ataques recursivos con payloads. Los intentos de realizar una denegación de
servicio contra el servicio web mediante el envío de mensajes diseñados para
sobrecargar el analizador XML.
» Ataques de referencia externa. Los intentos de eludir la protección mediante la
inclusión de referencias externas que se descargarán después del XML ha sido
validado pero antes de su procesado por la aplicación.
» Envenenamiento de esquema. El suministro de un esquema con el documento
XML de tal manera que el validador XML utilizará el esquema que se suministra, lo
que permite un documento XML malicioso para ser validado sin errores.
» SQL inyección. Proporcionar parámetros especialmente diseñados que se
combinarán en el servicio web para generar una consulta SQL definida por el
atacante.

» Desbordamiento de búfer. Proporcionar parámetros especialmente diseñados

que sobrecargará los buffers de entrada de la solicitud y se bloqueará el servicio de
web o potencialmente permite código arbitrario ejecutado.
» Cross site scripting. Redirección indebida a sitios web malignos desde los que se
inyecta código en el navegador de la víctima comprometiendo información del usuario
a disposición del atacante.
6.3. Referencias
Firewalls app. web practices configuration auditing, 2007. Recuperado el 24 de agosto

de 2017 de: http://www.sans.org/reading_room/whitepapers/firewalls/xml-firewall-
architecture-practices-configuration-auditing_1766
McGraw, G. (2006). Software security: building security in. San Francisco: Addison
Wesley.
Metodología square de ingeniería de requisitos. Recuperado (20 de junio de 2015) en,

http://resources.sei.cmu.edu/asset_files/TechnicalReport/2005_005_001_14594.pdf
Metodología de análisis de riesgos Magerit. Recuperado (20 de junio de 2015) en,

http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metod
olog/pae_Magerit.html#.VZFrGk3z74g
Metodología de análisis de riesgos ASSET (automated security self evaluation tool).

Recuperado (20 de junio de 2015) en, http://csrc.nist.gov/archive/asset/
Metodología de análisis de riesgos Octave (operationally critical threat, Asset and

vulnerability evaluation). Recuperado (20 de junio de 2015) en,
http://www.cert.org/resilience/products-services/octave/
Metodología de análisis de riesgos Cobit 5 (control objectives for information and

related technology). Recuperado (20 de junio de 2015) en,
http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metod
olog/pae_Magerit.html#.VZFplk3z74g

Lo + recomendado
Lecciones magistrales
Gateways XML
Los Gateways XML constituyen un medio online de protección del tráfico XML que los
servicios web emplean y de protección ante las amenazas más comunes que pueden sufrir
como SQLI, XSS y otras.
La lección magistral está disponible en el aula virtual
TEMA 6 – Lo + recomendado © Universidad Internacional de La Rioja (UNIR)

No dejes de leer…
Magic quadrant for SOA governance technologies
Este artículo es una comparativa sobre las prestaciones en cuanto a Servicios Web y
arquitecturas SOA ofrecidas por las compañías más importantes, estableciendo un
ranking entre ellas en base a varios criterios incluida la seguridad de los mismos.
Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

http://www.exclusive-networks.fr/wp-content/uploads/2014/07/Magic-Quadrant-for-
Secure-Web-Gateways-Juin-2014.pdf
Amenazas y ataques a servicios web
El consorcio de aplicaciones web WASC proporciona una clasificación detallada de las

amenazas que pueden sufrir las aplicaciones web, las cuales algunas de ellas pueden
materializarse en servicios web.

http://projects.webappsec.org/w/page/13246978/Threat%20Classification
TEMA 6 – Lo + recomendado © Universidad Internacional de La Rioja (UNIR)

+ Información
A fondo
XML technology
Aplicación de la tecnología XML que incluye: XML namespace, XML schema, XSLT,
efficient XML interchange (EXI).

https://www.w3.org/standards/xml/
Security design guidelines for web services
En esta página web se puede consultar una guía que puede servir de checklist para cubrir
todos los aspectos y funciones de seguridad de los servicios web para su protección.

http://msdn.microsoft.com/en-us/library/ff649737.aspx
TEMA 6 – + Información © Universidad Internacional de La Rioja (UNIR)

WASC: web application firewall evaluation criteria
Criterios para la evaluación de cortafuegos de las aplicaciones web del consorcio para la
seguridad de las aplicaciones web WASC.

http://projects.webappsec.org/w/page/13246985/Web%20Application%20Firewall%2
0Evaluation%20Criteria
Enlaces relacionados
OWASP
Página web del proyecto abierto para seguridad de las aplicaciones web.
Accede a la página desde el aula virtual o a través de la siguiente dirección web:

https://www.owasp.org/index.php/Web_Services
OASIS web services security (WSS) TC
Página del estándar abierto de seguridad de los servicios web.

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

National institute of standars and technology: information technology

laboratory
Página del Instituto de estándares y tecnología americano.

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss+
W3C
The world wide web consortium (W3C) es una comunidad internacional que desarrolla
open standards para asegurar el crecimiento de la web.

http://www.w3.org/

Cgisecurity
Cgisecurity proporciona información sobre seguridad web. Este sitio cubre aspectos de
seguridad de bases de datos, servidores web, web application security, http, web
services security y más.

http://www.cgisecurity.com/ws.html

Test
1. La metodología square es una metodología de:

A. Ingeniería de requisitos de seguridad.
B. Análisis de riesgos.
C. Análisis de la seguridad.
D. Ninguna de las anteriores.
2. ¿Cuándo se realizan los test de penetración?

A. En la fase de análisis.
B. En la fase de diseño.
C. En la fase de desarrollo.
D. En la fase de pruebas.
3. En la fase de pruebas se llevan a cabo:

A. Test funcionales de seguridad basados en el riesgo.
B. Test de penetración.
C. Análisis estático.
D. La A y la B son correctas.
4. Señala la afirmación correcta en cuanto a herramientas de análisis de la seguridad

SAST.
A. No tienen falsos positivos.
B. Necesitan auditoría posterior.
C. No cubren todo el código de la aplicación.
D. Todas las anteriores son falsas.
5. Señala la afirmación falsa:

A. Las herramientas IAST son de caja blanca.
B. Las herramientas DAST son de caja blanca.
C. Las herramientas SAST son de caja blanca.
D. Las herramientas RAST son de caja blanca.
TEMA 6 – Test © Universidad Internacional de La Rioja (UNIR)


A. Los servicios web pueden tener casi los mismos tipos de vulnerabilidades que
tienen las aplicaciones web.
B. Los servicios web pueden sufrir ataques XSS, SQLI, XML injection entre otros.
C. Se pueden utilizar herramientas de tipo DAST o SAST para testear la seguridad
de los servicios web.
D. Los servicios web no pueden tener ataques de escalada de privilegios.

A. Los firewall XML pueden realizar validación del esquema.
B. Los firewall XML pueden impedir escaneos WSDL.
C. Los gateways XML pueden implementar servicios de control de acceso.
D. Todas las anteriores son falsas.
8. El análisis de riesgos de seguridad se realiza en:

A. Las fases de análisis y diseño.
B. En la fase de análisis únicamente.
C. En la fase de diseño únicamente.
9. Para tener confidencialidad e integridad en servicios web, señala la afirmación falsa:

A. Los protocolos de transporte seguros pueden asegurar la seguridad de los
mensajes solo durante la transmisión.
B. Es importante hacer frente a los problemas de seguridad en la capa de aplicación
de forma independientemente de las capas de transporte.
C. En situaciones en las que se almacenan los mensajes y luego son remitidos es
necesaria seguridad de la capa de aplicación.
D. Con protocolos de transporte seguros como SSL es suficiente.
10. Respecto a la evaluación de la seguridad de los servicios web señala la afirmación

falsa:
A. Para llevar a cabo la evaluación de la seguridad en el ámbito de servicios web se
debe incluir en el ciclo de vida de desarrollo seguro la planificación de todas las
actividades y pruebas o test de seguridad.
B. Checkmarx y codesecure son dos herramientas de tipo DAST.
C. Klocwork insight y HP source code analyzer son herramientas de tipos SAST.
TEMA 6 – Test © Universidad Internacional de La Rioja (UNIR)

Tema6 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tema6 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Test de la seguridad y protección online

de los servicios web

[6.2] Evaluación de la seguridad de los servicios web

[6.3] Protección online. Firewalls y gateways XML

Evaluación de la seguridad de los

© Universidad Internacional de La Rioja (UNIR)

6.1. ¿Cómo estudiar este tema?

En este tema se repasan las metodologías, técnicas y herramientas para analizar la

Se introducen mecanismos de defensa online como son operaciones de configuración

6.2. Evaluación de la seguridad de los servicios web

La naturaleza altamente distribuida de la tecnología de servicios web crea una

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Dependiendo de la complejidad del servicio la prueba de cada ruta posible, interfaz, y de

El análisis de la seguridad de servicios web en la práctica tendrá dos vertientes:

Para llevar a cabo la evaluación de la seguridad en el ámbito de servicios web se debe

Figura 1. Modelo de SSDL de MacGraw

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

» 1: Modelado de amenazas y casos de abuso.

Actividades de análisis de la seguridad en SW

A continuación se describen cada una de las actividades de análisis de seguridad desde

» Modelado de amenazas y casos de abuso.

o ¿En qué consisten? El resultado de estas actividades junto con el análisis de

o ¿Cuándo se deben llevar a cabo? En la fase de análisis de requisitos y de diseño

Si estamos en el caso de una auditoría todas estas actividades se realizan en una

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

o ¿Quién las debe llevar a cabo? En el caso de estar en SSDLC, el personal

o ¿Cómo se debe realizar? Para la actividad de modelado de amenazas se puede

Figura 2. Metodología de derivación de casos de abuso

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

En la siguiente tabla se muestra un ejemplo de caso de abuso en comparación a un caso

Caso de uso Caso de abuso

» Análisis de los requisitos de seguridad.

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

o ¿Cuándo se deben llevar a cabo? En la fase de análisis de requisitos y de diseño

Si estamos en el caso de una auditoría, todas estas actividades se realizan en una

o ¿Quién las debe llevar a cabo? En el caso de estar en SSDLC, el personal

o ¿Cómo se debe realizar? Para derivar los requisitos de seguridad se pueden

En esta metodología se utilizan árboles de ataque, modelado de casos de abuso y

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Figura 3. Metodología de ingeniería de requisitos SQUARE

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Resumiendo, el proceso de derivación de requisitos de seguridad:

o Partiendo de los objetivos de negocio y de calidad se obtienen y revisan los

» Análisis de riesgos de la arquitectura.

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Figura 4. Elementos de un análisis de riesgos

o ¿Cuándo se debe llevar a cabo? Como se puede observar en la figura de abajo,

Figura 5. Fases del análisis de riesgo

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

o ¿Quién las debe llevar a cabo? Personal del departamento de seguridad o

o ¿Cómo se debe realizar? En la fase de análisis al obtener los casos de abusos y

Sin embargo, es en la actividad de análisis de riesgos de la arquitectura del sistema

Metodologías estándar de riesgo que se pueden utilizar:

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

» Pruebas funcionales de seguridad:

o ¿En qué consisten? Prueban la eficacia de los mecanismos y funciones de

o ¿Cuándo se deben llevar a cabo? En la fase de pruebas del SSDLC o en fase de

o ¿Quién las debe llevar a cabo? Personal del departamento de seguridad o

o ¿Cómo se debe realizar? Se deben de generar los casos de prueba necesarios

- Generación y comprobación de mensajes de SOAP y XML: con el

TEMA 6 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

» Revisión del código (ver tema 4).

o ¿En qué consiste? Esta actividad se trata en el tema 4. Como se comentó en