Documentos de Académico
Documentos de Profesional
Documentos de Cultura
3 TEMA
Seguridad de los servicios web
Esquema
TEMA 3 – Esquema
SERVICIOS WEB:
Arquitectura
Dimensiones seguridad
Requisitos de seguridad
Amenazas y riesgos
FUNCIONES DE SEGURIDAD
2
Autenticación SEGURIDAD ONLINE:
Gestión de identidad y relación de TEST Monitorización y auditoría
confianza Evaluación de la Disponibilidad
Autorización y control de acceso seguridad SW Seguridad servicio
Confidencialidad e integridad descubrimiento
Protección online:
Seguridad SOA
Firewalls XML
Seguridad en Aplicaciones en Línea
Seguridad en Aplicaciones en Línea
Ideas clave
Los servicios web, como se estudió en el tema 1, tienen su origen en lo que se denomina
Arquitectura Orientada a Servicios (SOA, Service-Oriented Architecture). Como
ejemplos de esta arquitectura se pueden nombrar tecnologías tan conocidas como RPC,
RMI, CORBA o DCOM. Los servicios web se pueden definir como un conjunto de
aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas
aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos
servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los
usuarios solicitan un servicio llamando a estos procedimientos a través de la Web.
Figura 1.
Figura 1. http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
Para la comunicación entre las diferentes entidades o aplicaciones que actúan como
consumidores de servicios o proveedores de los mismos, los servicios web emplean un
protocolo denominado SOAP que tiene estructura XML tienen, (figura 2):
Una envoltura.
Una cabecera con datos descriptivos.
Un body o contenido.
Web Service Description Language (WSDL): Es el estándar que se utiliza para describir
un Servicio Web. Está basado en XML y permite especificar cómo deben representarse
los parámetros, tanto de entrada como de salida, en una invocación de tipo externo al
servicio. Permite comprender cómo operar con el Servicio Web, a los diferentes
clientes.
SERVICIO
REGISTRO
UDDI (BROKER) UDDI
question register
SERVICIO SERVICIO
CONSUMIDOR PROVEEDOR
CLIENTE SERVICIO
SOAP (XML)
Las diferentes entidades que intervienen en la prestación de uno o varios servicios web
determinados pueden estar ubicados en cualquier parte en Internet y se instalan en
servidores de aplicaciones similares a los de las aplicaciones web con las que comparten
muchas de sus características. Las medidas de seguridad han de extremarse teniendo
en mente todos los elementos de la seguridad:
Identificación y autenticación.
Autorización.
Confidencialidad.
Integridad.
No repudio.
Privacidad.
Para ello hay que asegurar todas aquellas partes de los servicios web que constituyen
sus dimensiones de seguridad. Es decir, los elementos de seguridad deben
garantizarse a través de las dimensiones de seguridad que tiene un entorno de servicios
web:
Cualquier software, incluidos los servicios web, deben satisfacer los requisitos de
rendimiento, coste, facilidad de uso y seguridad. Ejemplos de posibles
requisitos de software seguro son la corrección y la disponibilidad. En la figura 4, se
muestra un modelo de seguridad de servicios web que refleja por capas cuáles son los
estándares de seguridad de referencia. Las capas inferiores son las de red de nivel 3,
pasando por la de transporte y por último de aplicación.
» Consorcio World Wide Web (W3C) [1]. La W3C nace con un objetivo claro, ser
un foro de discusión abierto y fomentar la interoperabilidad en la evolución técnica
que se produce en el mundo Web. En un periodo de tiempo menor a diez años, se
Las vulnerabilidades que pueden tener los servicios web, junto con las posibles
deficiencias de implementación de mecanismos de seguridad adecuados y suficientes
pueden posibilitar la materialización de amenazas convirtiéndose en ataques. Las
principales amenazas y riesgos a que se enfrentan los servicios web son:
Los servicios web pueden tener casi los mismos tipos de vulnerabilidades que tienen
las aplicaciones web (consultar el proyecto web security threat classification de WASC:
http://projects.webappsec.org/w/page/13246978/Threat%20Classification) y otras
añadidas debido a sus propias características, que posibilitan ataques de:
» XSS
» SQLI
» PATH TRAVERSAL
» INFORMATION DISCLOSURE.
» FORMAT STRING
» BUFFER OVERFLOW
» ESCALADA DE PRIVILEGIOS
» PARAMETER TAMPERING
» COMMAND INJECTION
» XML INJECTION
» SOAP ARRAY ABUSE
» XQUERY INJECTION
» XPATH INJECTION
» XML EXTERNAL ENTITIES
» XML ATTRIBUTE BLOWUP
» XML ENTITY EXPANSION
Para mitigar todos los posibles ataques contra seguridad de los servicios web hay que
aplicar funciones y tecnologías de seguridad correspondientes a los estándares de
seguridad, introducidas en el apartado anterior. El objetivo es cumplir con los
requisitos de seguridad que deben satisfacer los servicios web. Muchos de los conceptos
de seguridad usados en las aplicaciones web son la base para entender la seguridad de
los servicios web. A continuación se introducen las especificaciones de seguridad más
adecuadas para implementar los requisitos de seguridad de los SW como:
» Política de seguridad.
» Confidencialidad e integridad.
» Sistemas de gestión de identidades: autenticación, autorización.
» Monitorización.
» Disponibilidad.
» Seguridad en el servicio de descubrimiento.
» WS-Federation. En una comunicación entre SW, una de las partes podrá utilizar
Kerberos y otro Certificados X.509, podría necesitarse una traducción de los datos
que afectan a la seguridad entre las partes afectadas. Una federación es una
colección dominios de seguridad que han establecido relaciones en virtud del cual
un proveedor de uno de los dominios puede proporcionar acceso autorizado a los
recursos que gestiona sobre la base de la información de los participantes (como
puede ser su identidad) la cual debe ser afirmada por un proveedor de identidad
(Security Token Service).
» XML Digital Signature. Establecido por W3C, tiene como objetivo crear una
serie de mecanismos que permitan la creación y manejo de firmas digitales basadas
en el lenguaje XML. XML Signature, es el estándar de firmado desarrollado para
establecer un esquema que permite interpretar el resultado obtenido de las firmas
digitales y aplicarlas sobre los datos. Dentro del esquema se contempla la integridad
Si un mensaje debe pasar a través de varios puntos para llegar a su destino, cada
punto intermedio debe reenviarlo a través de una nueva conexión SSL. En este
modelo, el mensaje original del cliente no está protegido mediante cifrado puesto
que atraviesa servidores intermedios y para cada nueva conexión SSL que se
establece se realizan operaciones de cifrado adicionales que requieren una gran
cantidad de programación. El estándar WS-Security se basa en estándares y
certificaciones digitales para dotar a los mensajes SOAP de los criterios de seguridad
necesarios. Se definen cabeceras y usa XML Signature para el manejo de firmas en
el mensaje. La encriptación de la información la realiza mediante XML Encryption.
Hace uso del intercambio de credenciales de los clientes.
XAdES define seis perfiles (formas) según el nivel de protección ofrecido. Cada perfil
incluye y extiende al previo:
o XAdES-BES, forma básica que simplemente cumple los requisitos legales de la
Directiva para firma electrónica avanzada.
o XAdES-EPES, forma básica a la que se la ha añadido información sobre la política
de firma.
o XAdES-T (timestamp), añade un campo de sellado de tiempo para proteger
contra el repudio.
o XAdES-C (complete), añade referencias a datos de verificación (certificados y
listas de revocación) a los documentos firmados para permitir verificación y
validación off-line en el futuro (pero no almacena los datos en sí mismos).
o XAdES-X (extended), añade sellos de tiempo a las referencias introducidas por
XAdES-C para evitar que pueda verse comprometida en el futuro una cadena de
certificados.
o XAdES-X-L (extended long-term), añade los propios certificados y listas de
revocación a los documentos firmados para permitir la verificación en el futuro
incluso si las fuentes originales (de consulta de certificados o de las listas de
revocación) no estuvieran ya disponibles.
o XAdES-A (archivado), añade la posibilidad de timestamping periódico (por ej.
cada año) de documentos archivados para prevenir que puedan ser
comprometidos debido a la debilidad de la firma durante un periodo largo de
almacenamiento.
Cuando cualquier entidad de servicios web realiza una petición a otra en un esquema
de consumidor-proveedor, aquel debe ser autenticado de forma segura, para llevar esta
función se dispone de mecanismos como:
» HTTP-based token authentication.
» SSL/TLS-certificate based authentication.
» Mediante tokens o assertions en la petición SOAP.
» Tickets Kerberos.
» …
Figura 8.
Fuente: https://msdn.microsoft.com/en-us/library/ff648318.aspx#WSSecurityStandards
Figura 9.
Fuente: https://msdn.microsoft.com/en-us/library/ff648318.aspx#WSSecurityStandards
Figura 10.
Fuente: https://msdn.microsoft.com/en-us/library/ff648318.aspx#WSSecurityStandards
Figura 11.
Fuente: https://msdn.microsoft.com/en-us/library/ff648318.aspx#WSSecurityStandards
Modelos de autorización
SAML y XACML son dos de las especificaciones que se pueden utilizar para
implementación de los modelos anteriores de gestión de la autorización.
3.5. Disponibilidad
¿Hasta qué punto QoS es consciente de que el servicio web opera en su nivel más
esperado de desempeño y fiabilidad asegurando el servicio web opera correctamente y
de manera previsible en presencia de fallos no intencionados? La disponibilidad se
asegura de que:
Una vez que el solicitante recibe el documento WSDL para el servicio Web candidato,
debe ser validado. El método más sencillo para hacer esto es proporcionar una firma
digital del documento WSDL. La versión v. 1.1 de WSDL no prevé un mecanismo
interno para la firma de documentos WSDL. Hasta que tal mecanismo esté disponible,
el servicio Web candidato debe proporcionar una firma externa para el documento
WSDL o el solicitante debe verificar de forma independiente a través de
comunicaciones fuera de banda, que el sitio proporciona el documento WSDL es una
entidad de confianza.
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
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.
datos UML, como su propio nombre indica, los casos de abuso son casos en los que
se puede comprometer alguna funcionalidad de los SW.
» ¿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.
http://resources.sei.cmu.edu/asset_files/TechnicalReport/2005_005_001_14594.
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 figura 18, en las fases de análisis y
diseño del SSDLC.
» ¿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.
» ¿Cuándo se debe llevar a cabo? Como se puede observar en la figura 20, 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. Posteriormente,
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.
» ¿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
» ¿En qué consiste? Esta actividad se trata en el tema 2, de esta asignatura, 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. Revisa el tema 2, donde se explica la arquitectura y funcionamiento.
Es una actividad fundamental, 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 21, se puede ver un esquema de la arquitectura de las
herramientas SAST.
» ¿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.
» ¿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.
» ¿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 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
• 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
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. 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.
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.
Material complementario
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
No dejes de leer…
Bertino, E., Martino, L. D., Paci, F.& Squicciarini, A. C. (2010). Security for Web
Services and Service-Oriented Architectures. Springer.
Este artículo sobre SOA (XML) Gateways trata las mejores prácticas de
implementación, beneficios y requisitos con un enfoque en la virtualización de
servicios, cofidencialidad e integridad de mensajes y de la auditoría de mensajes. Un
Gateway de este tipo controla sin problemas acceso a los servicios, protege la
información a través de cifrado de nivel de datos, se asegura la integridad de un
mensaje a través de firmas, y controla el flujo de información corporativo.
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.
A fondo
XML Technology
Ampliación de la tecnología XML, que incluye XML Namespaces, XML Schema, XSLT,
Efficient XML Interchange (EXI).
En esta página web se pueden consultar un guía que puede servir de checklist para
cubrir todos los aspectos y funciones de seguridad de los servicios web para su
protección.
Criterios para la evaluación de cortafuegos de las aplicaciones web (y servicios web) del
Consorcio para la seguridad de las aplicaciones web WASC.
Webgrafía
OWASP
Página web del proyecto abierto para Seguridad de las Aplicaciones Web.
https://www.owasp.org/index.php/Web_Services
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
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
Bibliografía
Bibliografía básica
Bibliografía complementaria
Bertino, E., Martino, L.D., Paci, F., y Squicciarini, A.C. (2010). Security for Web
Services and Service-Oriented Architectures. SPRINGER.
Actividades
Descripción de la actividad
Pautas de elaboración
Una vez revisada la documentación de la última y reciente versión (de abril de 2104)
del software para seguridad de Servicios WEB (CORISECIO y EPERI) no está
adecuadamente actualizada por EPERI y puede llevar a confusiones. Por tal motivo,
se va a utilizar la versión inmediatamente anterior cuya documentación está bastante
bien ajustada a las capacidades del software correspondiente a la versión
inmediatamente anterior. Todo el material está disponible en Internet en un
alojamiento DROPBOX.
TEMA 3 – Actividades 57
Seguridad en Aplicaciones en Línea
TEMA 3 – Actividades 58
Seguridad en Aplicaciones en Línea
Instalación. Para su instalación en plataforma con Windows, hay que seguir los
pasos siguientes:
Contenido de Parar.cmd:
set JAVA_HOME=C:\Users\...\SOA-DEMO\Java\
set CATALINA_HOME=C:\Users\...\SOA-DEMO\Tomcat
set PATH=%JAVA_HOME%\bin;%PATH%
TEMA 3 – Actividades 59
Seguridad en Aplicaciones en Línea
cd "C:\Users\...\SOA-DEMO\Tomcat\bin"
start cmd /ccall C:\Users\...\SOA-DEMO\Tomcat\bin\shutdown.bat
https://www.dropbox.com/sh/cgkzwq2z6qyy1kd/viPuZUC2ln
Una vez descargado, hay que sustituir el fichero config.xml que viene por defecto en
la instalación en la ubicación:
C:\Users\...\SOA-DEMO\Tomcat\webapps\WSDemo\config.xml
TEMA 3 – Actividades 60
Seguridad en Aplicaciones en Línea
Hay que especificar una ruta con un subdirectorio final que no exista, fuera del
directorio WEBAPPS de aplicaciones de APACHE, p.e.:
C:\Users\...\SOA-DEMO\...
Se configura un usuario/password.
La clave de encriptación viene predefinida y se deja como está.
TEMA 3 – Actividades 61
Seguridad en Aplicaciones en Línea
TEMA 3 – Actividades 62
Seguridad en Aplicaciones en Línea
4. XMLGATEWAY. (OPCIONAL).
Ataques XQUERY INJECTION - SQLI. Para ello hay que diseñar una expresión
regular [1][2][3], que elimine caracteres y secuencias malignas sin perjudicar el
funcionamiento de los servicios. (ver vulnerabilidad sqli)
Validación de Schema. Por defecto valida contra the standard schema for SOAP
1.1 messages, por tanto, añadiendo la función de validación valida por defecto. No
obstante lo ideal es averiguar contra que esquema se valida (ver referencia [4]) la
envoltura de los mensajes. Se ve también en los propios mensajes en el tráfico de la
aplicación.
Configurar la entidad provider del XmlGateway para que redirigir las peticiones al
puerto 2600 del TCPMonitor.
TEMA 3 – Actividades 63
Seguridad en Aplicaciones en Línea
Recomendaciones:
Se necesitará generar la clave pública de cada una de las tres entidades desde la
aplicación correspondiente a cada conector de cada una de las entidades consumer,
provider y payment. Recordar el concepto de que para cifrar algo que se envía
(ORDER de petición por ejemplo) se usa la clave pública del destinatario. Tener esto
en cuenta a la hora de configurar las funciones de cifrado.
Mediante TCPMONITOR se puede ver en cada paso el tráfico XML de las peticiones
y respuestas entre las entidades.
Documentación.
Descargar de: https://www.dropbox.com/sh/cgkzwq2z6qyy1kd/viPuZUC2ln
TEMA 3 – Actividades 64
Seguridad en Aplicaciones en Línea
Referencias.
3. Symantec. http://www.symantec.com/connect/articles/detection-sql-injection-
and-cross-site-scripting-attacks
Apéndice
1. Validación de esquema
Se debe investigar contra qué esquema validar. Si en el fichero del esquema añadimos
la dirección del esquema XML que se va a validar, en este caso la correspondiente al
envoltorio SOAP (ver referencia [4]), la validación la realiza correctamente al
identificar un esquema correcto en el mensaje enviado.
En este caso la envoltura, etiqueta Envelope del mensaje de un mensaje SOAP, se valida
y se comprueba que está codificada según el esquema… (ver [4]), por lo que al añadirlo
en la configuración de la validación va a ser identificado como un mensaje
correctamente codificado.
TEMA 3 – Actividades 65
Seguridad en Aplicaciones en Línea
En la práctica, aparecen dos entradas en log (mismo timestamp) por cada petición de
acceso: un warning y un Acceso con éxito:
TEMA 3 – Actividades 66
Seguridad en Aplicaciones en Línea
2. X-QUERY INJECTION
En la página http://projects.webappsec.org/w/page/13247006/XQuery%20Injection
se describe muy bien este tipo vulnerabilidad ataque:
XQuery Injection is a variant of the classic SQL injection attack against the
XML XQuery Language. XQuery Injection uses improperly validated data that is
passed to XQuery commands. This inturn will execute commands on behalf of the
attacker that the XQuery routines have access to. XQuery injection can be
used to enumerate elements on the victim's environment, inject commands to
the local host, or execute queries to remote files and data sources. Like SQL
injection attacks, the attacker tunnels through the application entry point
to target the resource access layer.
<userlist>
<user category="group1">
<uname>jpublic</uname>
<fname>john</fname>
<lname>public</lname>
<status>good</status>
</user>
<user category="admin">
<uname>jdoe</uname>
<fname>john</fname>
<lname>doe</lname>
<status>good</status>
</user>
<user category="group2">
<uname>mjane</uname>
<fname>mary</fname>
<lname>jane</lname>
<status>good</status>
</user>
<user category="group1">
TEMA 3 – Actividades 67
Seguridad en Aplicaciones en Línea
<uname>anormal</uname>
<fname>abby</fname>
<lname>normal</lname>
<status>revoked</status>
</user>
</userlist>
doc("users.xml")/userlist/user[uname="mjane"]
Would return:
<user category="group2">
<uname>mjane</uname>
<fname>mary</fname>
<lname>jane</lname>
<status>good</status>
</user>
Assuming that the XQuery gets its user name string from the input, an
attacker can manipulate this query into returning the set of all users. By
providing the input string:
something" or ""="
TEMA 3 – Actividades 68
Seguridad en Aplicaciones en Línea
TEMA 3 – Actividades 69
Seguridad en Aplicaciones en Línea
Test
TEMA 3 – Test 70
Seguridad en Aplicaciones en Línea
TEMA 3 – Test 71
Seguridad en Aplicaciones en Línea
TEMA 3 – Test 72