• Author / Uploaded
• Bequer Orosco

Citation preview

Asignatura Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 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 Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 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 Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 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. Ejemplo de script startDemostrator.cmd (actualizar las rutas convenientemente): set JAVA_HOME= C:\...\SOA-DEMO\Java\ TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)

Asignatura Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 Nombre:

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: Ejecutar



startDemonstrator.cmd

arranca

Tomcat,

despliega

SOA

DEMOSTRATOR y XMLGATEWAY y arranca TCPMONITOR.

TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)

Asignatura Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 Nombre:

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á. TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)

Asignatura Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 Nombre:

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

TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)

Asignatura Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 Nombre:

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/ TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)

Asignatura Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 Nombre:

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.

TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)

Asignatura Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 Nombre:

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). 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. Regular Expression Library. http://regexlib.com 3. Symantec. http://www.symantec.com/connect/articles/detection-sql-injectionand-cross-site-scripting-attacks 4. SOAP Messages. http://soapuser.com/basics3.html

TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)

Asignatura Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 Nombre:

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.

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 Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 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

TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)

Asignatura Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 Nombre:

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.



jpublic john public good

jdoe john doe good

mjane mary jane good

anormal abby normal revoked

An typical XQuery of this document for the user mjane:

TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)

Asignatura

Datos del alumno

Seguridad en Aplicaciones en Línea

Fecha

Apellidos: 12-01-2021 Nombre:

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

Would return:

mjane mary jane good

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

TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)

Asignatura Seguridad en Aplicaciones en Línea

Datos del alumno

Fecha

Apellidos: 12-01-2021 Nombre:

TEMA 3 – Actividades

© Universidad Internacional de La Rioja (UNIR)