Asignatura Datos del alumno Fecha

Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

Actividades

Trabajo: Configurar la seguridad de servicios web

Descripción de la actividad

Esta actividad consiste en configurar la seguridad de servicios web mediante

soluciones de seguridad de open source.

CORISECIO Corporate Information Security

http://opensource.corisecio.com/index.php?id=get_started y EPERI
http://eperi.de/en/open-source/eperi-xml-gateway/ ponen conjuntamente, a libre
disposición, varias soluciones diferentes para dar seguridad a Servicios Web.

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.

En esta actividad se van a utilizar conjuntamente dos soluciones de seguridad:

SOA SECURITY DEMOSTRATOR para implementar servicios de autenticación,

firma digital y cifrado con una aplicación de compra de libros ejemplo. (8 de 10
puntos), diseñada para aprendizaje.

XML GATEWAY (OPCIONAL) para validación de esquemas y prevención de

ataques SQLI entre otros. (2 de 10 puntos)

TEMA 3 – Actividades
 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

Requisitos. El alumno debe manejar los conceptos de certificados digitales y su uso,

uso de algoritmos de claves públicas, uso de la firma digital, no repudio,
autenticación, integridad y cifrado. Además, debe conocer los conceptos y
arquitectura de diseño de los servicios web.

Descripción. En la figura 1, se presenta un esquema de lo que se pretende con esta

actividad. Es una demostración de lo que se puede conseguir con las soluciones
anteriores siguiendo el documento de ayuda Tutorial secRT demostrator y los
documentos auxiliares de referencia además de estas instrucciones.
Se dispone de un servicio de tienda web de libros (CONSUMER), otro servicio de
suministro de los libros (PROVIDER) y un tercer servicio que se encarga de
posibilitar el pago de los libros solicitados por un usuario (PAYMENT).
Se dispone de tres conectores de seguridad (SOA SECURITY GATEWAY), en la
figura en rojo que realizan las acciones de seguridad de autenticación, integridad,
no repudio y confidencialidad, descritas en la figura y detalladas más adelante.
Cuando se despliegan los tres servicios se arranca una aplicación de
monitorización que intercala puertos (en amarillo) para poder ver tráfico de
mensajes entre servicios para comprender mejor las acciones que realizan los
conectores de seguridad (en rojo).
Por último se intercala antes del servicio de pago un firewall XML (OPEN XML
GATEWAY) para implementar validación de esquemas y protección de ataques
SQL – XQUERY INJECTION.

TEMA 3 – Actividades
 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

Seguridad de servicios web con soluciones open source

Instalación. Para su instalación en plataforma con Windows, hay que seguir los
pasos siguientes:

Asegurarse de que los puertos 80, 443, 8080 están libres.

Descargar SOA Demonstrator desde:

https://www.dropbox.com/s/emlnz3ufl2aak83/SOA-DEMO.zip luego
descomprimir. El directorio resultante contiene las versiones de apache TOMCAT y
de JAVA necesarias.

A continuación ejecutar startDemostrator.cmd (donde hay que actualizar

las rutas de instalación del producto para un correcto arranque de
TOMCAT con la versión de JAVA que trae consigo). Una vez actualizado el
script, se ejecuta para desplegar los tres servicios web sobre Apache Tomcat y
arrancar la aplicación de monitorización del tráfico XML.

TEMA 3 – Actividades
 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

Ejemplo de script startDemostrator.cmd (actualizar las rutas convenientemente):

set JAVA_HOME= C:\...\SOA-DEMO\Java\

set CATALINA_HOME= C:\...\SOA-DEMO\SOA-DEMO\Tomcat
set PATH=%JAVA_HOME%\bin;%PATH%
cd "C:\...\SOA-DEMO\Tomcat\bin"
start cmd /ccall C:\... \SOA-DEMO\Tomcat\bin\startup.bat
cd "C:\...\SOA-DEMO"
cd TCPMonitor
start tcpmon.bat
cd C:\...\SOA-DEMO

Se recomienda crear y alojar en el mismo subdirectorio que startDemostrator.cmd

un script (parar.cmd) para parar el servidor APACHE, con el siguiente contenido
actualizando las rutas a vuestra particular configuración:

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%

cd "C:\Users\...\SOA-DEMO\Tomcat\bin"
start cmd /ccall C:\Users\...\SOA-DEMO\Tomcat\bin\shutdown.bat

Descargar XML Gateway desde:

https://www.dropbox.com/s/pp9ntpxqgrdvy6g/ROOT.war La solución es una
aplicación desplegable en Apache denominada ROOT. Hay que copiar ROOT.war en
el directorio webapps del servidor Apache Tomcat de SOA Demonstrator instalado
en el paso anterior. De esta forma, al arrancar TOMCAT se despliegan SOA
SECURITY DEMOSTRATOR y XMLGATEWAY en la figura 1, para poder
configurar seguidamente la seguridad de los servicios web como se indica en la
figura 1.

TEMA 3 – Actividades
 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

Arranque de Tomcat con las soluciones de seguridad y la aplicación

tpcmonitor:

Ejecutar  startDemonstrator.cmd arranca Tomcat, despliega SOA

DEMOSTRATOR y XMLGATEWAY y arranca TCPMONITOR.

IMPORTANTE: Después de arrancar el servidor hay que descargar el fichero

config.xml de:

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

por el descargado previamente de DROPBOX, que tiene la parametrización correcta

de puertos, para navegar a través de los puertos de TCPMONITOR.

PARAR y ARRANCAR APACHE TOMCAT para que se cargue la nueva

configuración.

Acceso a los conectores de seguridad de SOA Demostrator y Gateway xml:

Se accede mediante las URL,s siguientes:

http://localhost:8080/consumer/
http://localhost:8080/provider/
http://localhost:8080/payment/
http://localhost:8080/XMLGATEWAY/

TEMA 3 – Actividades
 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

La contraseña de acceso inicial es secRT.

Seguidamente se muestra una pantalla, donde hay que configurar la ubicación de la

base de datos derby que utiliza cada conector (ver apartado 4.4.3 DATA STORE de la
UserGuide secRT):

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

A continuación la aplicación del conector de seguridad redirige a la pantalla inicial y ya

se puede comenzar a configurar.

Configuración. Seguidamente, hay que configurar las funciones de seguridad de

autenticación, firma y cifrado de la petición-respuesta en cada conector de seguridad
(en rojo) desplegados en el servidor de aplicaciones Apache Tomcat donde también
están desplegados los servicios web, según la figura 1. (ver documentación que viene
con el producto: Tutorial secRT demostrator y otros de referencia para consultar
la correcta parametrización de las funciones). En cuanto a las funciones de cifrado, se
aplican dos veces, una para los datos de pago que son una parte de la orden de petición
y la otra para toda la orden de petición. Por lo tanto, se deben cifrar los datos de pago
en primer lugar, porque van incluidos dentro de la orden de pedido y deben viajar a
través de provider cifrados hasta payment que es quién solamente debe poder
descifrarlos.

1. Conector de seguridad de CONSUMER.

Se accede mediante la url http://localhost:8080/consumer/ (se puede utilizar también

https). Se deben configurar las siguientes funciones de autenticación, firma y cifrado de
la petición a enviar en menú WORFLOW de consumer:
SetsecRTEntity
EctractFromRequest
WSSecurityAddSAMLToken (SAML 1.1)
EncryptXPathForCertificate, para cifrar el elemento paymentInformation de la
petición XML.

TEMA 3 – Actividades
 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

SignSOAPEnvelope
EncryptXPathForCertificate, para cifrar el elemento Order de la petición XML
EnvelopeInRequest
Proxy para redirigir la petición al servicio web provider a través del puerto 2100 del
tcpmonitor.

En la respuesta se debe configurar:

ExtractFromResponse
DecryptXPath para descifrar el resultado de la petición
EnvelopeInResponse

2. Conector de seguridad de PROVIDER.

Se accede mediante la url http://localhost:8080/provider/ Descifra el elemento Order

de la petición del consumer y verifica la firma. Se deben configurar para ello las
siguientes funciones en el menú WORKFLOW de provider.
SetsecRTEntity
EctractFromRequest
DecryptXPath, para descifrar el elemento Order de la petición XML
WSSecurityCheckSAMLToken (SAML 1.1)
VerifySOAPEnvelope
EnvelopeInRequest
Proxy para redirigir la petición al servicio web payment a través del puerto 2300
del tcpmonitor.

Para asegurar la respuesta se debe configurar:

ExtractFromResponse
EncryptXPathForCertificate para cifrar el resultado de la petición: Elemento
OrderingResult
EnvelopeInResponse

3. Conector de seguridad de PAYMENT.

Se accede mediante la url http://localhost:8080/payment/ Descifra la información de

pago. Se deben configurar para ello las siguientes funciones en el menú WORKFLOW
de payment:
SetsecRTEntity
EctractFromRequest
DecryptXPath, para descifrar el elemento paymentInformation de la petición
XML
EnvelopeInRequest
Proxy para redirigir la petición al XMLGATEGAY (puerto 80) o al puerto 2600 del
TCPMonitor si se opta por no intercalar y configurar XMLGATEWAY.

TEMA 3 – Actividades
 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

4. XMLGATEWAY. (OPCIONAL).

Se accede mediante la url http://localhost:8080/XMLGATEWAY/

XMLGATEWAY está prácticamente configurado con el nivel de seguridad en

su NIVEL1 según se descarga y solamente hay que configurar y habilitar las
protecciones siguientes (ver apéndice):

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.

Recomendaciones:

Seguir la documentación para entender las funciones de seguridad a implementar.

El tutorial de SOA Demonstrator es el primer documento que deberíais consultar
aunque en las funciones implementadas en su ejemplo no son exactamente las
mismas que las de la práctica.

Implementar primero la parte de los conectores de seguridad sin XMLGATEWAY.

Una vez instalados los conectores CONSUMER, PROVIDER y PAYMENT intercalar
XMLGATEWAY como en la figura y luego configurar las protecciones pedidas.

Implementar las funciones de autenticación, firmado y cifrado de forma

escalonada no a la vez. Cuando se va superando una fase con una función
comprobando que funciona la aplicación se pasa a la siguiente.

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,

TEMA 3 – Actividades
 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

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

Debes entregar una memoria explicando la configuración de las funciones, expresiones

regulares utilizadas en la prevención de ataques SQLI, certificados digitales y claves
necesarios para su correcto funcionamiento y debes demostrarlo con los LOG
descargables (opción salvar) desde cada puerto de la aplicación TCPMONITOR (2100,
2300, 2400, 2600), copias de pantallas de la aplicación TCPMonitor (con la fecha-hora
visibles de las peticiones) y de los conectores de seguridad y proporcionando el último
archivo de log cada uno de los conectores de seguridad: (ej. C:\..\..
\Tomcat\webapps\consumer\log\conector.2013-04-17.log) y del XmlGateway.

Referencias.

1. SANS. Detecting Attacks on Web Applications from Log Files.

https://www.sans.org/reading-room/whitepapers/logging/detecting-attacks-
web-applications-log-files-2074

2. http://regexlib.com

3. http://www.symantec.com/connect/articles/detection-sql-injection-and-cross-
site-scripting-attacks

4. SOAP Messages. http://soapuser.com/basics3.html

TEMA 3 – Actividades