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 © Universidad Internacional de La Rioja (UNIR)

 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 © Universidad Internacional de La Rioja (UNIR)

 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 © Universidad Internacional de La Rioja (UNIR)

 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.

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

tpcmonitor:

TEMA 3 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

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/

La contraseña de acceso inicial es secRT.

TEMA 3 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

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. Se deben cifrar por tanto, 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.
SignSOAPEnvelope
EncryptXPathForCertificate, para cifrar el elemento Order de la petición XML
EnvelopeInRequest

TEMA 3 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

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

TEMA 3 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

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.

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:

TEMA 3 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

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

Extensión máxima: 15 páginas (Georgia 11 e interlineado 1,5).

TEMA 3 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

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. Regular Expression Library. http://regexlib.com

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

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

Apéndice

1. Validación de esquema

Añadiendo la función de validación de esquema, sin configurar ningún parámetro, se

valida por defecto contra el standard schema forSOAP 1.1 messages (Modeling
reference_SOASecurity.pdf). No obstante, veréis que la validación da un warning En
cuanto al log de salida, dado que no se ha configurado con ninguna función, considera
exitosa la respuesta al no encontrar ningún problema de seguridad (ver pantallas
subsiguientes).

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 © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

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 © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

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.

Using the example XML document below, users.xml.

<?xml version="1.0" encoding="ISO-8859-1"?>

<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">
<uname>anormal</uname>
<fname>abby</fname>
<lname>normal</lname>
<status>revoked</status>
</user>
</userlist>

An typical XQuery of this document for the user mjane:

doc("users.xml")/userlist/user[uname="mjane"]

Would return:

TEMA 3 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos:
Aplicaciones Online
y Bases de Datos Nombre:

<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 ""="

the XQuery becomes: doc("users.xml")/userlist/user[uname="something" or

""=""]

En XMLGATEWAY podemos especificar una regla para impedir el string or.

XMLGATEWAY en su documentación (Modeling reference_SOA Security), con

respecto a la función CheckForSQLInjection (En realidad es la función Prevent SQL-
XQUERY INJECTION en XMLGATEWAY), nos dice como añadir una regla (todas las
que queramos), es una validación tipo blacklist. Cada regla consta de una pareja
nombre-valor (expresión regular). Este valor lo buscará XMLGATEWAY en el body de
las peticiones y si lo encuentra bloqueará.

A continuación, para comprobar un ataque, ponemos el string or en cualquier campo

de una petición de libros y veremos que el GATEWAY bloquea.

¡OJO! En las referencias de expresiones regulares aportadas veréis que las expresiones
vienen con una / al principio y final. En esta herramienta no hay que ponerlas, ejemplo:

/((\%27)|(\'))(select|union|insert|update|delete|replace| truncate)/ix
sería
((\%27)|(\'))(select|union|insert|update|delete|replace| truncate)

TEMA 3 – Actividades © Universidad Internacional de La Rioja (UNIR)