• Author / Uploaded
• Adriana Narváez Rosero

Citation preview

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

http://opensource.corisecio.com/index.php?id=get_started

Security 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) 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.

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

https://www.dropbox.com/s/emlnz3ufl2aak83/SOA-DEMO.zip

desde: 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.

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

https://www.dropbox.com/s/pp9ntpxqgrdvy6g/ROOT.war

desde:

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:

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

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, 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-attacksweb-applications-log-files-2074

2. http://regexlib.com 3. http://www.symantec.com/connect/articles/detection-sql-injection-and-crosssite-scripting-attacks

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

DESARROLLO DE LA ACTIVIDAD

INSTALACIÓN Y CONFIGURACIÓN 1. Verificar que los Puertos 80, 433 y 8080 se encuentren habilitados.

2. Habilitar TOMCAT, mediante ejecución startDemostrator.cmd, se procedió a seguir los pasos para habilitar el TCPMonitor, editando el archivo startDemostrator.cmd y registrando las rutas en donde se ha descargado SOA Demostrator.

3. Se procede a crear el archivo parar.cmd para detener los servicios Tomcat.

4. Descargar XML Gateway y probar cada uno de los conectores: 

http://localhost:8080/consumer/



http://localhost:8080/provider/



http://localhost:8080/payment/



http://localhost:8080/XMLGATEWAY/

CREAR ENTIDADES 5. Acceder al conector CONSUMER y crear las entidades: la clave de acceso es secRT, antes de crear las entidades se debe especificar donde se va a crear la base de datos Derby, se muestra una pantalla en la que configurar la ubicación de la base de datos que utiliza cada conector. Se debe especificar un directorio que no exista, además se debe ingresar un usuario y contraseña, y la clave de encriptación de deja la que viene predefinida.

6. A continuación, se va a configurar las funciones de seguridad de autenticación, firma y cifrado de la petición-respuesta en cada conector de seguridad desplegado en el servidor de aplicaciones Apache Tomcat donde también están desplegados los servicios web. 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. 6.1. En cada conector se crea las tres entidades consumer, provider y payment, para hacerlo se accede desde el menú Entity-> new y creamos el usuario por cada entidad como se muestra a continuación:

6.2.

Luego se procede a inicializar la entidad, se crea el almacén de claves de seguridad para las funciones de seguridad como se muestra a continuación.

6.3.

Luego de inicializar se debe marcar activar y también se debe crear roles para las autorizaciones y se debe asociar a cada usuario creado.

7. Configurar puerto de escucha: Según el esquema de la actividad se configura el puerto de escucha, desde el menú workflow, editamos y en la opción de Worflow Entry Point presionamos configurar el ingresamos los puertos para cada pasarela como se muestra a continuación.

8. Crear Funciones Se crean las funciones para autenticación, firma y cifrado. Para cada conector se crea las funciones. Desde workflow damos click en editar y se selecciona la función del grupo disponible de funciones.  SETSECRTENTITY que es la que establece la entidad a utilizar en el workflow. En el nombre de la entidad, por ejemplo en consumer.

En medio de las dos funciones se va creando y configurando cada función para petición o respuesta. Para la petición se crean las funciones EctractFromRequest que extrae la petición de la envoltura y EnvelopeInRequest que vuelve a meter la petición en el sobre después de autenticar y firmar, entre estas las dos se va añadiendo cada función Para la respuesta se crean las funciones ExtractFromResponse que extrae la repuesta de la envoltura y EnvelopeInResponse que vuelve a meter la petición en el sobre después de descifrar, entre las dos se va añadiendo cada función Conector de seguridad de Consumer. Las funciones a crear para la petición son:  WSSecurityAddSAMLToken (SAML 1.1). Función para la autorización

Y verificamos que la autenticación se realizó correctamente. En la siguiente imagen se puede verificar los atributos del Assertion y su firma.

 EncryptXPathForCertificate, para cifrar el elemento paymentInformation de la petición XML. Se coloca la ruta de los datos de pago: //*[local-name() = 'paymentInformation' and namespace-uri() = 'http://demo-book-shop/ns'].

 SignSOAPEnvelope. Funcion de firmado, se debe especificar el nombre del actor

 Y a continuación se muestra el mensaje en TCPMonitor donde se ve la función de resumen aplicada sha y el algoritmo de seguridad asimétrico utilizado RSA

 EncryptXPathForCertificate, para cifrar el elemento Order de la petición XML.

A continuación se muestra el cifrado con la clave pública del destinatario

9. Funciones a configurar en la respuesta:  DecryptXPath para descifrar el resultado de la petición. La ruta de datos resultado de la orden es: *[local-name() = 'OrderingResult' and namespace-uri() = 'http://demo-book-shop/ns']

Conector de seguridad de Provider. Descifra el elemento Order de la petición del Consumer y verifica la firma. Las funciones a configurar para la petición:  DecryptXPath, para descifrar el elemento Order de la petición XML. La ruta de los datos de orden completa es: *[local-name() = 'Order' and namespaceuri() = 'http://demo-book-shop/ns']

 WSSecurityCheckSAMLToken (SAML 1.1). Para verificar la autorización. Se indica el actor al que se va a chequear

 VerifySOAPEnvelope.

Para asegurar la respuesta se debe configurar:  EncryptXPathForCertificate para cifrar el resultado de la petición: Elemento OrderingResult.

Conector de seguridad de Payment. Descifra la información de pago. Se deben configurar para ello las siguientes funciones en el menú WORKFLOW de Payment:

 DecryptXPath, para descifrar el elemento paymentInformation de la petición XML.

10. Verificar funciones Se verifica la función al realizar la compra con la seguridad ya implementada:

La respuesta de las funciones se la puede verificar en los documentos adjuntos log_2100, log_2300, log_2400 y log_2600 11. XML Gateway Se accede mediante la url http://localhost:8080/XMLGATEWAY/. Se crea las entidades consumer y provider configurando ID, PASSWORD y ENDPOINT solo en su provider: localhost:2600

Se configura el LISTENER de XMLGATEWAY en la POLICY con el puerto 80 y el Proxy del conector de seguridad PAYMENT debe apuntar al puerto 80 (XMLGATEWAY).

12. Ataques XQUERY INJECTION - SQLI. Se crea la regla desde policy.

Verificar la Regla creada en el paso anterior:

Validación de Schema. .- Se configura el esquema a validar en este caso http://schemas.xmlsoap.org/soap/envelope/