Professional Documents
Culture Documents
REA TCNICA
TTULO DE INGENIERO EN SISTEMAS INFORMTICOS Y
COMPUTACIN
TRABAJO DE TITULACIN
LOJA ECUADOR
2016
Esta versin digital, ha sido acreditada bajo la licencia Creative Commons 4.0, CC BY-NYSA: Reconocimiento-No comercial-Compartir igual; la cual permite copiar, distribuir y
comunicar pblicamente la obra, mientras se reconozca la autora original, no se utilice con
fines comerciales y se permiten obras derivadas, siempre que mantenga la misma licencia al
ser divulgada. http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es
Septiembre, 2016
Magister
Daniel Alejandro Guamn Coronel
DOCENTE DE LA TITULACIN
De mi consideracin:
El presente trabajo de titulacin: Consideraciones de Arquitectura de Software a nivel de Diseo
Arquitectnico y Desarrollo de Software para minimizar vulnerabilidades en aplicaciones web
basados en OWASP Top Ten 2013, caso de estudio arquitectura: SOA, realizado por Miguel
Alejandro Tenezaca Lima, ha sido orientado y revisado durante su ejecucin, por cuanto se
aprueba la presentacin del mismo
f). ............................
Mgs. Daniel Alejandro Guamn Coronel
CI: 1103777403
ii
f). ............................
Autor: Miguel Alejandro Tenezaca Lima
Cdula: 0705705721
iii
DEDICATORIA
iv
AGRADECIMIENTO
Un cordial y respetuoso agradecimiento por la culminacin del presente trabajo de fin de titulacin:
A Dios por la vida y las bendiciones que me ha dado.
A mis padres por su apoyo incondicional.
A mi director de Trabajo de fin de titulacin por su apoyo y orientacin durante la elaboracin de
este trabajo.
A mi comit del tribunal por sus correcciones y aportaciones en el presente trabajo
CONTENIDO
CONTENIDO ................................................................................................................................... vi
NDICE DE FIGURAS ...................................................................................................................... x
NDICE DE TABLAS ..................................................................................................................... xiii
RESUMEN .......................................................................................................................................1
ABSTRACT ......................................................................................................................................2
INTRODUCCIN .............................................................................................................................3
Delimitacin y definicin del problema ......................................................................................... 4
Objetivos....................................................................................................................................... 5
Objetivo General ...................................................................................................................... 5
Objetivos Especficos ............................................................................................................... 5
GLOSARIO DE TRMINOS ............................................................................................................6
CAPTULO I......................................................................................................................................8
ESTADO DEL ARTE ........................................................................................................................8
1.1.
1.1.1.
Definicin. .................................................................................................................. 9
1.1.2.
1.1.3.
1.1.4.
1.2.
1.2.1.
Definicin ................................................................................................................. 12
1.2.2.
1.3.
Patrones .......................................................................................................................... 16
1.3.1.
Patrones Arquitectnicos......................................................................................... 16
1.3.2.
1.4.
vi
1.4.1.
Definicin ................................................................................................................. 27
1.4.2.
1.4.3.
1.4.4.
1.5.
1.5.1.
Definicin ................................................................................................................. 32
1.5.2.
1.5.3.
1.5.4.
1.5.5.
1.5.6.
1.5.7.
1.6.
Vulnerabilidades .............................................................................................................. 41
1.6.1.
Definicin ................................................................................................................. 41
1.6.2.
1.7.
1.7.1.
Definicin ................................................................................................................. 44
1.7.2.
CAPTULO II...................................................................................................................................50
PROPUESTA DE SOLUCIN .......................................................................................................50
2.1.
2.2.
2.3.
2.4.
2.5.
CAPTULO III..................................................................................................................................64
DISEO DE LA SOLUCIN ..........................................................................................................64
vii
3.1
Validacin de Diseo....................................................................................................... 89
5.2.
viii
Documento WSDL del servicio web PftWebService implementado sin seguridad. ..... 113
D.
E. Configuracin SAML con WSIT Cliente del Servicio web. ............................................ 119
ix
NDICE DE FIGURAS
xi
xii
NDICE DE TABLAS
xiii
RESUMEN
La orientacin a servicios permite la integracin y automatizacin de procesos de las empresas los
mismos que al estar disponibles en la web son vulnerables a sufrir algn tipo de ataque; por ende
existen organizaciones como OWASP encargadas de concientizar a los desarrolladores en la
creacin de software seguro y de calidad mediante el uso de normas y recomendaciones para
evitar vulnerabilidades. El presente trabajo se centr en la implementacin de un prototipo para
mitigar vulnerabilidades de tipo: SQL Injection, XSS y exposicin de datos sensibles en
aplicaciones web construidas bajo el estilo arquitectnico SOA utilizando el patrn arquitectnico
MVC, patrones de diseo Facade y DAO, tcnicas de seguridad OWASP a nivel de codificacin y
configuracin en el lenguaje de programacin Java EE en Glassfish y la especificacin WSSecurity.
Finalmente el prototipo fu validado con herramientas como: Structural Analysis for Java,
SonarQube, OWASP ZAP, Vega y Wireshark, para comprobar la calidad del prototipo a nivel de
diseo, de codificacin y de seguridad para contrarrestar los tipos de vulnerabilidades.
Palabras Clave: Exposicin de datos sensibles, Inyeccin SQL, OWASP, SOA, SOAP, WSSecurity, XSS.
ABSTRACT
Services orientation allow the integration and automating process of business the same as being
available on the network are vulnerable to suffer any type of attack, there are some organization as
OWASP responsable of raising awareness to the developers in the creation of a secure software
and the quality through the use of standards and recommendations to avoid vulnerabilities. The
present work was focus on the implementation of a prototype to reduce vulnerabilities such as: SQL
Injection, XSS and exposure of sensitive data in web applications built under SOA using MVC as
architectural pattern, Facade and DAO as design patterns, and principles and best practices given
by OWASP to writing secure code, through Java EE configure the Glassfish Server and WSSecurity specification.
Finally, the prototype was validate with tools such as: Structural Analysis for Java, SonarQube,
OWASP, Vega and Wireshark, to analyze the quality of the prototype in terms of coding, design
and security to counteract the vulnerability types.
Key words: Exposure of sensitive data, OWASP, SOA, SOAP, SQL Injection, WS-Security, XSS.
INTRODUCCIN
Internet ofrece el ambiente ideal para la creacin de aplicaciones web que permiten el intercambio
de informacin, transacciones electrnicas entre otras funcionalidades, sobre todo permitiendo la
interaccin entre las empresas y sus clientes. La Arquitectura Orientada a Servicios (SOA) permite
integrar diversos tipos de aplicativos mediante los servicios web, los cuales deben cumplir ciertos
requisitos del cliente y adems poseer ciertos estndares de seguridad que garanticen que la
aplicacin final sea de calidad.
Bajo este criterio en el presente proyecto se propone que a travs del uso del patrn arquitectnico
MVC y de los patrones de diseo Facade y DAO se minimicen las vulnerabilidades a nivel de
desarrollo de cdigo de dichas aplicaciones, para ello se realiza un anlisis y estudio de algunas
metodologas, tcnicas y procedimientos que asociadas a dicha arquitectura permitan cumplir con
el objetivo desde el punto de vista de diseo y desarrollo de software.
Para el desarrollo del proyecto se han propuesto las siguientes actividades para su cumplimiento:
La finalidad del presente proyecto es utilizar la gua de OWASP para elaborar un prototipo bajo el
estilo arquitectnico SOA, en el cual se expongan las consideraciones de cdigo y diseo que
permitan minimizar vulnerabilidades en aplicaciones web.
Objetivos
Objetivo General
Identificar los patrones, mtricas y estndares que asociados al estilo arquitectnico SOA permitan
minimizar algunos de los tipos de vulnerabilidades listados en OWASP Top Ten 2013 desde el
punto de vista de diseo arquitectnico y desarrollo de software.
Objetivos Especficos
Analizar los tipos de vulnerabilidades que pueden afectar la seguridad de una aplicacin
de software diseada bajo un estilo arquitectnico SOA.
GLOSARIO DE TRMINOS
API.- Aplication Programming Interface (Interfaz de Programacin de Aplicaciones).
CORBA.- Common Object Request Broker Architecture (Arquitectura comn de intermediarios en
peticiones a objetos).
DAO.- Data Access Object (Objeto de Acceso a Datos).
DCOM.- Distributed Component Object Model (Modelo de Objetos de Componentes Distribuidos).
EJB.- Enterprise JavaBeans (Beans empresariales de Java).
HTTP.- Hypertext Transfer Protocol (Protocolo de Transferencia de Hipertexto).
HTTPS.- Hypertext Transfer Protocol Secure (Protocolo de Transferencia de Hipertexto Seguro).
IDE.- Integrated Development Enviromment (Ambiente de Desarrollo Integrado).
J2EE.- Java 2 Platform Enterprise Edition (Edicin Empresarial de la Plataforma Java 2).
JPA.- Java Persistence Api (Api de Persistencia de Java).
JSF.- Java Server Faces.
JSP.- JavaServer Pages.
MVC.- Model View Controller (Modelo Vista Controlador).
ORM.- Object-Relational Mapping (Mapeo Objeto-Relacional)
OWASP.- The Open Web Application Security Project.
OWASP ZAP.- OWASP Zed Attack Proxy.
RPC.- Remote Procedure Call (Llamadas a Procedimientos Remotos).
SMTP.- Simple Mail Transfer Protocol (Protocolo para Transferencia Simple de Correo).
SOA.- Service Oriented Architecture (Arquitectura Orientada a Servicios).
SOAP.- Simple Object Access Protocol (Protocolo Simple de Acceso a Datos).
SQL.- Estrutured Query Languaje (Lenguaje de Consulta Estructurado).
CAPTULO I
Definicin.
Y Bosch (2000),
Rendimiento.- Se refiere a las respuestas del sistema, ya sea el tiempo requerido para
responder a eventos especficos o a la cantidad de eventos procesados en un intervalo
de tiempo dado. La arquitectura debe disearse para localizar operaciones crticas de
un pequeo nmero de componentes desplegados en la misma computadora.
Seguridad.- Se debe usar una estructura en capas para proteger los componentes ms
vulnerables en las capas ms internas, con un alto nivel de seguridad aplicado en dichas
capas.
1.1.2.
1.1.3.
10
del equipo de desarrollo, sirve como puente entre los requerimientos del sistema y la
implementacin, permite la reutilizacin y permite predecir y mitigar riesgos ofreciendo un software
de calidad (C. Reynoso, 2004). Por otro lado, una arquitectura no adecuada puede ser catastrfica,
Clements & Northrop (1996) nombra algunos aspectos negativos de la arquitectura de software:
no existe un criterio unificado acerca de la arquitectura de software, limitaciones tecnolgicas y el
tiempo de elaboracin del marco de referencia es bastante amplio.
1.1.4.
Definicin
Segn Camacho, Cardeso, & Nuez (2004) define al estilo arquitectnico como un patrn que
organiza estructuralmente los componentes, tipos de conectores y un conjunto de limitaciones o
restricciones de cmo pueden ser usadas.
Buschmann, Meunie, Rohnert, Sommerlad, & Stal (2000) considera los estilos arquitectnicos
como la base fundamental de la estructura de un sistema software, asociado de mtodos que
especifican la forma de implementarlo, cuando usarlo, sus especializaciones y las consecuencias
de sus uso.
1.2.2.
12
Fuente de
Conocimiento
Fuente de
Conocimiento
Fuente de
Conocimiento
Base de Datos
Fuente de
Conocimiento
Tubera
Filtro
Tubera
Filtro
Filtro
Tubera
Tubera
Filtro
Filtro
Tubera
Filtro
13
Programa
Principal
Rutina 1
Rutina 1.1
Rutina 2
Rutina 1.2
Rutina 3
Rutina 3.1
Rutina 3.2
Obj eto
Gestores
Obj eto
Obj eto
EntryPoint
Obj eto
14
Registro de
Servicios
Encontrar
Solicitante del
Servicio
Transmitir
Unir (SOAP)
Proveedor del
Servicio
Servicio
SOA como tema principal del presente trabajo, ser abordado a profundidad ms adelante, donde
se ver sus principios, caractersticas, elementos, capas, etc.
15
1.3. Patrones
1.3.1.
Patrones Arquitectnicos
Los patrones arquitectnicos son medios para reutilizar el conocimiento sobre las arquitecturas de
sistemas, describen la arquitectura definiendo la estructura bsica del sistema; representa una
plantilla de construccin que provee un conjunto de subsistemas con sus responsabilidades, que
facilitan el diseo arquitectnico.
El diseo arquitectnico es la base fundamental de toda aplicacin, porque en l se establecen los
subsistemas y la comunicacin entre ellos. Un buen diseo arquitectnico tiene como ventajas:
una buena comunicacin entre los actores del sistema, anlisis del sistema y la reutilizacin.
Tipos de los Patrones Arquitectnicos.
Los patrones arquitectnicos son plantillas que sirven para representar una arquitectura especfica,
y de acuerdo a las necesidades del sistema se elige la adopcin de una en particular, algunos
ejemplos de patrones arquitectnicos son:
16
Modelo-Vista-Controlador.
Capas.
Repositorio.
Cliente-Servidor.
17
PATRON
Modelo Vista
Controlador
DESCRIPCION
VENTAJAS
DESVENTAJAS
Capas
Repositorio
Cliente
Servidor
Tubera y Filtro
sistema
19
Patrones de Diseo.
El patrn de diseo es una descripcin del problema y la esencia de su solucin, de modo que la
solucin puede reutilizarse en diferentes configuraciones; no es una especificacin detallada
(Sommerville, 2011). Los patrones representan una forma de describir las mejores prcticas de
diseo para poderlos reutilizar, as mismo detallan aspectos relacionados con el diseo de los
subsistemas, centrndose en aspectos ms especficos de la aplicacin; los patrones de diseo
son la base para la bsqueda de soluciones a problemas comunes en el desarrollo de software y
para el diseo de interfaces.
Sommerville (2011) presenta 4 elementos que conforman los patrones de diseo:
Nombre significativo.
Reutilizable.
Los patrones de diseo son soluciones bien pensadas a problemas conocidos de la programacin,
ya que abstraen el comportamiento de un determinado problema en una configuracin de
componentes y estn clasificados de acuerdo con el nivel de abstraccin que tenga cada patrn.
Tipos de Patrones de Diseo.
Un patrn de diseo puede considerarse como un documento que define una estructura de clases
que aborda una situacin particular. Los patrones de diseo se dividen en tres grupos principales
(Tedeschi, 2014):
decir, definen como las clases y objetos se asocian para formar estructuras ms
complejas.
21
Abstract Factory
(Creacional)
DESCRIPCIN
SE USA CUANDO
* Ser independiente de cmo se crean, se componen y se representan sus productos.
* Debera ser configurado mediante una de las mltiples familias de productos posibles.
* Se disea una familia de objetos relacionados que deben ser usados en conjunto.
* Proveer una librera de una clase de productos y es necesario revelar simplemente sus interfaces, pero
ocultar sus implementaciones.
Builder
(Creacional)
Separa
el
proceso
de
construccin de un objeto
complejo de su representacin,
para que el mismo proceso de
construccin
pueda
crear
diferentes representaciones
* El algoritmo para crear objetos complejos debe ser independiente de las partes que constituyen el objeto
y la forma en que son ensamblados.
Crea
objetos
nuevos
copindolos, clonando una
instancia creada previamente
Prototype
(Creacional)
* La construccin de procesos debe permitir diferentes representaciones para el objeto que se construye.
* Para evitar la construccin de una jerarqua de la clase de fbricas que se asemeja a la jerarqua de la
clase de productos
* Cuando instancias de una clase pueden tener una de las combinaciones de diferentes estados.
* Cuando es necesario la creacin de distintas variantes de un objeto. Entonces, el cdigo que utilizan esos
objetos solicitar una copia del objeto que necesite, una copia significa otra instancia del objeto. El nico
requisito que debe cumplir el objeto es la posibilidad de clonarse.
Adapter
(Estructural)
Bridge (Estructural)
* Se desea evitar una vinculacin permanente entre la abstraccin y su implementacin. Este puede ser el
caso en que la implementacin debe ser seleccionada o modificada en tiempo de ejecucin.
* Las abstracciones y sus implementaciones deben ser extensibles a travs de subclases. En este caso, el
patrn Bridge permite combinar diferentes abstracciones e implementaciones y extenderlas en forma
independiente.
* Los clientes no deben tener que recompilar el cdigo cuando se lleven a cabo modificaciones en la
implementacin de una abstraccin.
* Se desea ocultar completamente la implementacin de una abstraccin a los clientes.
* Se necesita compartir una implementacin entre varios objetos, y este hecho debe ocultarse a los clientes.
Composite
(Estructural)
Facade
(Estructural)
Admite
construir
objetos
complejos por medio de la
composicin recursiva de objetos
similares u otros ms simples en
una estructura en forma de rbol.
Adems permite que dichos
objetos sean tratados de manera
semejante, sin hacer distinciones
entre ellos.
Simplifica el acceso a un
conjunto
de
clases
proporcionando una nica
clase que todos utilizan para
comunicarse
con
dicho
conjunto de clases.
* Los clientes no necesitan conocer las clases que hay tras la clase Facade.
* Quiere proveer una interfaz nica para un subsistema complejo. Esto ayuda a que un subsistema sea
ms reusable y fcil de adaptar.
* Hay muchas dependencias entre clientes y clases que implementan una abstraccin. Con el patrn
Facade se desacopla el cliente del subsistema, as como entre subsistemas; esto promueve subsistemas
independientes y portables.
* Usted quiere dividir en capas su subsistema.
23
Data
Access
Object (Estructural)
* Un proxy remoto provee una representacin local de un obj* Para abstraer eto ubicado en un espacio de
direccin diferente.
* Un proxy virtual crea objetos de gran tamao bajo demanda.
Proxy (Estructural)
* Un proxy de proteccin controla el acceso al objeto original, controlando quien accede a cada mtodo y
otorgando los permisos basndose en el invocador.
* Una referencia elegante lleva a cabo acciones extras cuando se acceden a objetos referenciados.
Observer
(Comportamiento)
Command
(Comportamiento)
* Una abstraccin tiene dos aspectos, uno dependiente del otro. Encapsulndolos en objetos separados
se permite variarlos y reusarlos de forma independiente.
* Cuando un cambio en un objeto implica cambiar otros y no se conoce de antemano cuantos objetos
deben actualizarse
* Cuando un objeto debe ser capaz de hacer notificaciones a otros sin hacer suposiciones de quines son,
buscando un bajo acoplamiento.
* Facilitar la parametrizacin de las acciones a realizar
* Independizar el momento de peticin del de ejecucin
* Implementar CallBacks, especificando que rdenes se necesitan ejecutar en ciertas situaciones bajo otras
rdenes. Es decir, un parmetro de una orden puede ser otra orden a ejecutar. .
* Dar soporte para deshacer comandos, procesos de identificacin y/o transacciones
24
* Desarrollar sistemas utilizando rdenes de alto nivel que se construyen con operaciones sencillas
(primitivas).
State
(Comportamiento)
Strategy
(Comportamiento)
* Los mtodos tienen largas y mltiples sentencias condicionales que dependen del estado del objeto.
Estos estados generalmente son representados por constantes enumeradas y largas sentencias
switch/case dentro de los mtodos. El patrn State ubica cada rama del condicional en clases separadas.
* Se quiera ofrecer la posibilidad de configurar una clase con una gama de comportamientos disponibles.
* Se necesiten diferentes variantes de un algoritmo.
* Un algoritmo use datos que el cliente no tenga por qu conocer.
* Una clase defina varios comportamientos y estos aparezcan en forma condicional en sus operaciones.
25
En la Figura 6, se representa la relacin que existe entre los estilos arquitectnicos, patrones
arquitectnicos y los patrones de diseo, que propone el desarrollo de arquitecturas de software
como un sistema de patrones, y distintos niveles de abstraccin. Los estilos y patrones ayudan al
arquitecto a definir la composicin y el comportamiento del sistema de software, y una combinacin
adecuada de ellos permite alcanzar los requerimientos de calidad. Los patrones arquitectnicos en
comparacin con los patrones de diseo, los patrones arquitectnicos tienen un nivel de
abstraccin mayor.
En la Tabla 3, para tener una idea ms clara se muestra las diferencias entre estilo arquitectnico
y patrn arquitectnico:
Tabla 3. Diferencias entre estilos arquitectnicos y patrones arquitectnicos
ESTILOS ARQUITECTNICOS
PATRN ARQUITECTNICO
Definicin
27
Anaya Lopez (2011) menciona que los servicios web se describen as mismos como la lgica de
negocio expuesto en la web como servicios por medio de interfaces y el uso de protocolos de
internet, que pueden ser buscados, suscritos e invocados por otra aplicacin.
Los servicios web son aplicaciones que estn identificadas por un Uniform Resource Identiflier
(URI) que tienen la capacidad de estar definidos, descritos, descubiertos e invocados mediante
XML. Los servicios web interactan en internet, intercambian informacin entre s con el objetivo
de ofrecer servicios, mediante la adopcin de protocolos y estndares.
1.4.2.
Los servicios web proveen una funcionalidad a otros usuarios o a otros servicios, lo que determina
servicios como Proveedores y servicios Consumidores, interactuando mediante mensajes.
Gonzles Quiroga (2011) menciona 3 elementos de los servicios:
Estos componentes tambin forman parte de los elementos de una arquitectura orientada a
servicios ya que los servicios lo son, y las caractersticas principales de los servicios web, segn
Aperador (2012) son las siguientes:
Uso de estndares, para que los servicios web sean utilizados por sistemas
heterogneos existentes en la red es el empleo del protocolo de transferencia de
datos HTTP utilizado por todos los navegadores web y XML.
Los servicios web presentan una funcionalidad de caja negra que puede ser reutilizada
sin preocuparse de cmo es implementada y ello proporciona interfaces bien definidas.
28
1.4.3.
Para Chase (2011) las especificaciones de los servicios web estn clasificadas en dos grupos,
Como se puede observar en la Figura 7:
Especificaciones bsicas:
o
WSDL: Web Services Description Language, detalla una forma estndar de que
un servicio web basado en el protocolo SOAP pueda ser descrito, incluyendo la
forma la forma de uso del mensaje, su ubicacin, puertos, etc.
Especificaciones ampliadas
o
29
Especificaciones Ampliadas
Integracin
Calidad del
Serv icio
Especificaciones Bsicas
Descubrimiento
UDDI
Descripcin
WSDL
Mensaj era
SOAP, XML
Transporte
HTTP, SMTP
Los servicios web funcionan como aplicaciones independientes ya que se incluyen lgica de
negocios, manejo de datos, procedimientos y polticas para la resolucin de un problema
especfico. Los servicios web sirven de base para la implementacin de SOA permitiendo la
comunicacin por medio de mensajes de diferentes sistemas independientemente del sistema
operativo o lenguaje de programacin utilizado. La comunicacin entre los servicios web se basa
en el estndar XML y mediante el protocolo SOAP.
Los servicios web hacen uso de una pila de estndares y especificaciones que permiten la
interoperabilidad como: SOAP para el paso de mensajes, WSDL para la descripcin de los
servicios web, UDDI para el descubrimiento de los servicios web. Adems como de otras
especificaciones para la calidad y seguridad de los servicios web como: WS-Policy. WS-Security,
WS-Addressing, etc.
30
1.4.4.
En la Tabla 4, se listan las ventajas y desventajas que ofrecen los servicios web tomado de
Ordez Len (2010):
Tabla 4. Ventajas y desventajas de los servicios web
VENTAJAS
DESVENTAJAS
Los servicios web se pueden implementar siguiendo los principios de SOA, ya que permite mayor
acoplamiento, mediante el establecimiento de un Contrato, a diferencia de los servicios web REST
(Respresentational State Transfer) o RCP (Remote Procedure Call). La arquitectura orientada a
servicios permite disear e implementar los procesos de negocios en forma de servicios,
obteniendo una gran flexibilidad, resolviendo problemas de conectividad gracias a que permite la
31
Definicin
SOA (Service Oriented Architecture, en sus siglas en ingls), tiene varios enfoques: de negocio, de
tecnologa y de organizacin. Desde el punto de vista de negocio, SOA permite a las
organizaciones satisfacer los cambios en las necesidades de la empresa, mediante la
implementacin de servicios web. Desde el punto de vista tecnolgico aumenta la flexibilidad
simplificando a adaptacin de los sistemas existentes, mejora la productividad de procesos y la
usabilidad de las aplicaciones. Desde el punto de vista organizacional permite la consistencia en
los procesos, ofrece rapidez de adaptacin al cambio y mejora la cultura de servicio.
Lewis (2008) del SEI, menciona que arquitectura orientada a servicios es una forma de diseo,
desarrollo, implementacin y gestin de sistemas, en el cual:
32
En la Figura 8 se observa la integracin de SOA en una sola aplicacin final de usuario, donde la
aplicacin final orquesta la ejecucin de un conjunto de servicios, aade la lgica y la presenta a
mediante un interfaz al usuario. La orquestacin es un tema que se abordar ms adelante.
Cliente 1
Cliente 2
Cliente 3
Cliente 4
Node1
Serv idor de
Aplicaciones
Servicio
Web
Sistema de
Mensaj era
Jav a, IBM
Servicio
Web
Serv idor
Comercial
Serv idor
Cliente Mov il
Servicio
Web
Servicio
Web
Servicio
Web
Mainframes y
Microcomputadores
Servicio
Web
Serv idor
de Base
de Datos
Serv idor de
Correo
Electrnico
1.5.2.
Ser reutilizables.- Los servicios deben ser diseados para ser reutilizados dentro de la
misma aplicacin, dentro del dominio de aplicaciones de la empresa o incluso dentro
del dominio pblico.
33
Contrato formal.- Los servicios deben poseer un contrato formal en el cual debe
constar: nombre del servicio, forma de acceso, funcionalidades que ofrece, datos de
entrada y salida de las funcionalidades. Mediante el contrato el consumidor acceder a
ste, en los servicios se lo logra mediante WSDL.
Bajo acoplamiento.- Los servicios deben ser independiente unos de otros, es decir
debe existir bajo acoplamiento entre el servicio que se va a ejecutar y el servicio que lo
llama, logrando as su total reutilizacin.
Sin estado.- Un servicio no debe guardar ningn tipo de informacin, para poder ser
secuenciados (orquestados) para realizar la lgica del negocio y evitar problemas de
inconsistencia; y que toda la informacin est almacenada en algn tipo de sistema de
informacin.
Ser descubiertos.- Todo servicio debe ser descubierto de alguna forma para que
pueda ser utilizado, el descubrimiento de servicios web se lo realiza mediante interfaces
de registros UDDI.
34
Contrato
Formal
Descubrimiento
Evita
duplicidades y
se obtiene la
Proporciona la
independencia
de servicios por
ende la
Baj o
Acoplamiento
Minimiza las
dependencias
consiguiendo la
Reusabilidad
Ofrece mas
oportunidades de
Sin Estado
Permite la
Independencia
del entorno de
ejecucin
consiguiendo la
Composicin
Autonoma
1.5.3.
Un servicio es un elemento que encapsula una funcionalidad atmica, usado para soportar los
servicios de negocio que la organizacin proporciona. En un ambiente SOA, los servicios son
estructuras pequeas utilizadas para la construccin de estructuras ms complejas, para satisfacer
una necesidad especifica.
Para ello, Gomez (2013) enumera algunas caractersticas que un servicio web SOA debe cumplir:
Definido: El servicio debe definir lo que hace, sus procesos de negocio, su interfaz de
comunicacin, su forma de invocacin, los datos de entrada y salida y la forma en que
debe ser manejado el servicio.
Desplegado: Debe estar disponible para su respectivo uso por otras aplicaciones
clientes.
35
Reusable: Para que el servicio pueda ser reutilizado por cualquier proceso de negocio,
ste debe estar disponible cuando lo requieran.
Orquestado: Un servicio debe permitir ser orquestado, es decir ser combinado para
formar servicios ms grandes y complejos.
Adems, para que un servicio web se considere un servicio SOA, se debe implementar los
estndares de la industria incluyendo las especificaciones de los servicios web: XML, HTTP,
SOAP, WSDL, UDDI, WS-Security, etc.
1.5.4.
SOA es un nuevo estilo arquitectnico que est orientada a servicios y que gracias a su flexibilidad
hace ms fcil implementar cambios en toda la empresa, sin embargo no todas la empresas tienen
las mismas necesidades de negocio por tal motivo la empresa debe evaluar si es conveniente o
no adoptar SOA a su organizacin; En la Tabla 5, se listan algunas de las ventajas y desventajas
que tiene SOA tomados de Arquitectura Orientada a Servicios (2011) y Enriquez Huaca &
Caraguay (2011):
36
VENTAJAS
DESVENTAJAS
SOA simplifica la integracin de sistemas heterogneos, sistemas que requieren gran conectividad
e integracin de diversos dispositivos, procesos, formatos, plataformas, bases de datos, etc.,
aumentando la reutilizacin de software, haciendo que muchas de las aplicaciones migren a SOA
en la actualidad. Las ventajas de adoptar SOA son muchas, pero tambin esta arquitectura no se
acopla a todo tipo de aplicaciones y para efectuar algn cambio en stas se debe tener en cuenta
el impacto que puede tener en la implementacin.
37
1.5.5.
Elementos de SOA.
Para implementar una arquitectura orientada a servicios se lo debe hacer en base a estndares
que definen el manejo de aplicaciones, la comunicacin entre los servicios, SOA posee los
siguientes elementos, como se muestra en la Figura 10:
Elementos
SOA
Aplicacin
Contrato
Repositorio de
Serv icios
Serv icios
Implementacin
Lgica de
Negocio
Bus de
Serv icio
Interfz
Datos
38
Para la parte de implementacin del presente trabajo se desarrollar la parte de los elementos de:
servicio y la aplicacin consumidora del mismo, para demostrar lo concerniente a la seguridad
para evitar las vulnerabilidades de SQL Injection, XSS y exposicin de datos sensibles, utilizando
los estndares del WS-Security.
1.5.6.
La implementacin de una arquitectura orientada a servicios debe realizar por niveles y de forma
progresiva. En la Figura 11 se puede observar las capas de una arquitectura orientada a servicios:
Capa de Servicios.- Los servicios son los elementos bsicos de SOA. Existen dos
formas para crear un servicio:
o
Capa de Presentacin.- Esta capa representa la vista que puede tener el usuario, por
ende es muy importante. Se puede hacer si hablamos de tecnologas Java con: JSP,
JSF, portlets, servlets o clientes Java independientes.
Capa de Presentacin
JSP
Controlador
JSF
Vista
Capa de Negocio
Enlace de Datos
Componentes
de Negocio
Interfaz (WSDL)
EJB
Capa de
Procesos
39
Componentes
de Negocio
Clase Jav a
Capa de
Persistencia
1.5.7.
Funcionamiento de SOA.
Registro del
Serv icio
1. Publicar
2. Descubrir
Consumidor del
Serv icio
3. Conectar
WSDL
Mensaje
SOAP
4. Invocar
Direccin URI
40
es que es que siempre vayan de la mano estas tecnologas, ya que los estndares de los servicios
web forman una base para la implementacin de SOA.
Para la implementacin de SOA, en la organizacin se produce una transformacin, porque no
solo es el cambio tecnolgico, sino que cambia tambin la forma de dirigir y gestionar la empresa,
y se lo debe modelar de acuerdo a cada organizacin.
En la Tabla 6 se muestra los mitos y las realidades que existen en la Arquitectura Orientada a
Servicios.
Tabla 6. Mitos y realidades sobre SOA.
MITO
REALIDAD
Fuente: (Microsoft Developer Network Chapter 1: Service Oriented Architecture (SOA), 2014)
Elaboracin: Autor
1.6. Vulnerabilidades
1.6.1.
Definicin
Para Crespo Crespo, Augusta & Ramos Choes (2012) una vulnerabilidad o fallo es la posibilidad
de que una amenaza se materialice sobre un activo, un activo es un recurso de un sistema de
41
informacin o relacionado con ste, necesario para que la organizacin funcione correctamente,
incluye tanto elementos fsicos como abstractos. As mismo define que la amenaza es un evento
que puede producir daos tangibles o intangibles, incidiendo en la organizacin.
Segn Defaz Toapanta, (2006) vulnerabilidad es el punto o aspecto del sistema que es susceptible
de ser atacado o de daar la seguridad del mismo, es decir son la debilidades o aspectos que son
atacables en el sistema informtico.
Andrade, Jimenez, & Valencia (2013) define a la Vulnerabilidad como la capacidad, las condiciones
y caractersticas del sistema mismo (incluyendo la entidad que lo maneja), que lo hace susceptible
a amenazas, con el resultado de sufrir algn dao. En otras palabras, es la capacitad y posibilidad
de un sistema de responder o reaccionar a una amenaza o de recuperarse de un dao.
Se concluye que vulnerabilidad se refiere a la exposicin que tiene la infraestructura a los diferentes
riesgos. La vulnerabilidad provoca que los sistemas informticos funcionen de manera irregular o
diferente para lo que estaban diseados, afectando la seguridad de los mismos. Si existe algn
agujero de seguridad y mientras sta permanezca abierta se est expuesto a que cualquier ataque
se efecte. En trminos informticos vulnerabilidad es un punto del sistema que es susceptible a
ser atacado o daado.
1.6.2.
Tipos de vulnerabilidades
Las vulnerabilidades como se mencion anteriormente pueden ser tangibles e intangibles; aunque
no existe una clasificacin definida de vulnerabilidades ya que se lo puede tomar desde varios
enfoques, pero se tomar la clasificacin que hace Defaz Toapanta (2006) en 3 grupos:
Vulnerabilidad Fsica.- Se refiere al grado en que el sistema puede verse afectado por
desastres naturales o ambientales que pueden daar el sistema, como el fuego,
inundaciones, rayos, terremotos, o quizs ms comnmente, fallos elctricos o picos de
potencia. Otro aspecto es la posibilidad de entrar o acceder fsicamente al sistema para
robar o daar los discos, cintas, listados de impresora, etc. Ejemplos:
o
42
Paredes interiores que no sellan la sala por completo tanto en el techo como en
el suelo.
Virus.
Errores de configuracin.
Sistemas no protegidos.
Vandalismo y Estafas.
Invasiones.
Credenciales robadas.
43
No se puede decir que un sistema informtico es totalmente seguro, pero se puede crear
mecanismos que permitan evitar la mayora de ataques. El presente trabajo se centrar sobre las
vulnerabilidades de tipo lgicas, principalmente sobre las que pueden ocurrir durante el diseo y
codificacin de una aplicacin web. Los temas sobre este tipo de vulnerabilidades se revisarn en
el apartado denominado OWASP.
1.7. OWASP (The Open Web Application Security Project)
1.7.1.
Definicin
Salgado, Ron, & Solis (2014) menciona que The Open Web Application Security Project (OWASP)
como:
Un proyecto de cdigo abierto de seguridad en aplicaciones web y determina las causas
que hacen un software inseguro. Ofrece un Top 10 sobre los riesgos ms importantes en
aplicaciones web con el objetivo principal de educar a desarrolladores, diseadores,
arquitectos, gerentes y organizaciones.
OWASP es una comunidad abierta dedicada a habilitar a las organizaciones a desarrollar, comprar
y mantener aplicaciones en las que se pueda confiar. OWASP cuenta con aplicaciones libres,
herramientas de seguridad, recomendaciones, libros completos sobre pruebas de seguridad de
aplicaciones, cdigo de desarrollos seguros, investigacin de vanguardia, controles de seguridad
estndares, bibliotecas, etc., para el desarrollo de aplicaciones web seguras (OWASP, 2013).
Hermoso Metaute (2013) menciona que: OWASP es un organismo que est conformado por
empresas e instituciones acadmicas que contribuyen econmicamente y acadmicamente en los
distintos proyectos que promueve. Algunos de los principales proyectos de OWASP son:
OWASP Enterprise Security API (ESAPI): Es una librera que facilita a los programadores
la creacin de aplicaciones seguros, esta librera est disponible para varios lenguajes de
programacin.
44
presentes en las
aplicaciones web, esta lista se actualiza cada 3 aos aproximadamente por la organizacin.
OWASP Testing Guide: Es una gua que contiene un conjunto de tcnicas y mtodos
para encontrar las vulnerabilidades ms comunes en las aplicaciones web.
OWASP Zed Attack Proxy (ZAP): Es una herramienta potente para el escaneo de
vulnerabilidades en las aplicaciones web.
Todas las herramientas de OWASP son gratuitas, y disponibles para utilizar por cualquiera que
quiera proveer de seguridad a sus aplicaciones; ya que es una organizacin sin fines de lucro,
todos sus asociados son voluntarios, que apoyan la investigacin innovadora sobre seguridad;
busca la creacin de conciencia acerca de la seguridad en aplicaciones mediante la identificacin
de algunas vulnerabilidades que presentan las organizaciones en sus aplicativos, enumerados en
el OWASP Top Ten.
1.7.2.
El Top ten es uno de los proyectos ms importantes y conocidos de OWASP para dar seguridad a
las aplicaciones, OWASP Top Ten se centra en la identificacin de los riesgos ms crticos que
pueden ocurrir en las aplicaciones web. El objetivo principal del Top Ten es formar a los
desarrolladores, diseadores, arquitectos, gerentes y organizaciones, sobre las consecuencias de
las vulnerabilidades de seguridad ms importantes .Estos 10 tipos de vulnerabilidades son las ms
crticas no las ms comunes, y se actualiza cada 3 aos, siendo la primera versin en el ao 2003
y la ltima versin la del 2013, listada a continuacin por OWASP (2013):
Inyeccin
45
SQL Injection.- La vulnerabilidad de SQL Injection ocurre cuando no existe una correcta
validacin de los datos de entrada y stos contienen sentencias SQL, estas sentencias
contienen cdigos maliciosos en los formularios web o URL en las que rdenes SQL son
inyectados en texto para afectar la normal ejecucin de una consulta SQL predefinida, con
el propsito de atacar a los servidores de base de datos y poder acceder a datos sensibles
de la base de datos. En la Figura 13 se presenta los detalles de esta vulnerabilidad:
1
tabla
2
WHERE
3
atributo=
46
4
entrada de usuario
SELECT * FROM
tabla
2
WHERE
3
atributo=
entrada de usuario
OR
6
1
Para prevenir este tipo de ataque OWASP recomienda: usar APIs seguras que no permitan la
ejecucin del intrprete de base de datos, usar procedimientos almacenados, validar y limpiar todo
dato de entrada que el usuario ingrese en la URL.
Cross Site Scripting.- Este tipo de vulnerabilidad XSS o secuencia de comandos en sitios
cruzados sucede cuando por falta de mecanismos de filtrado de los datos de entrada, el
atacante puede insertar cdigo malicioso en forma de cdigo JavaScript o Visual Basic
Scripts. A travs de un ataque XSS se puede secuestrar cuentas, cambiar configuraciones,
acceder a partes restringidas de la pgina, modificar el contenido de la pgina, entre otras
cosas. Estos scripts pueden ser introducidos mediante:
o
Inyeccin por medio de la URL o de los elementos que viaje entre el navegador y
la aplicacin como atributos de las etiquetas HTML de la pgina.
Inyeccin por medio de recursos, por medio de las cabeceras HTTP, que son
mensajes con los que se comunican el servidor y el navegador.
47
OWASP hace las siguientes recomendaciones para evitar el ataque de XSS: validar la longitud,
formato y caracteres de los datos, limpieza de los datos de entrada, aplicacin de polticas de
seguridad.
48
Por tal razn, como recomienda OWASP, es conveniente la utilizacin de algoritmos fuertes de
cifrado, no almacenar datos sensibles innecesarios, deshabilitar el autocompletar de los
formularios, as como tambin el uso de un canal seguro de comunicacin como por ejemplo a
travs de SSL o TSL.
49
CAPTULO II
PROPUESTA DE SOLUCIN
50
Tomando como base las referencias tericas expuestas anteriormente, donde se consideran
aspectos relacionados con la construccin de servicios web seguros, el prototipo que se
implementar se lo pretende utilizar para la consulta de informacin correspondiente a los Temas
de Proyectos de Fin de Titulacin de la Universidad Tcnica Particular de Loja. La solucin estar
enfocada en la implementacin de aspectos de seguridad utilizando el estndar WS-Security,
recomendaciones OWASP para evitar vulnerabilidades de tipo SQL Injection, XSS y exposicin de
datos sensibles; con la implementacin del prototipo se pretende validar si se cumplen aspectos
como integridad, confidencialidad y disponibilidad de la informacin.
2.1. Identificacin de vulnerabilidades
Una arquitectura orientada a servicios permite a los desarrolladores mucha flexibilidad, debido a
que la mayora de sus componentes estn expuestos como servicios, permitiendo de esta forma
accesibilidad y promoviendo la reutilizacin de software. Muchas son las empresas en utilizar SOA,
sin embargo algunos equipos de desarrollo no garantizan la calidad y la seguridad con la que estn
construidos los servicios web. Problemas de diseo, de codificacin, de configuracin suelen
representar riesgos crticos o vulnerabilidades en los servicios web.
vulnerabilidades a las que un servicio web est expuesto, entre las ms comunes mencionadas
por National Security Agency (n.d.) tenemos:
Para evitar alguna infiltracin o vulnerabilidad a las aplicaciones web, se debe iniciar con el diseo
de una arquitectura donde se contemplen aspectos relacionados tanto a la funcionalidad y la
seguridad del sistema que se implementar, tomando en cuenta la utilizacin de patrones de
diseo arquitectnico, estndares y recomendaciones de buenas prcticas.
51
A continuacin se detalla los patrones que se utilizar para la implementacin del prototipo:
2.2. Patrn arquitectnico
Modelo Vista Controlador.- El patrn arquitectnico MVC resuelve el problema de reusabilidad
desacoplando las capas de vista, modelo y de datos, permitiendo hacer cualquier modificacin en
cualquiera de las capas impactando en menor medida al resto de capas. El MVC se basa en la
reutilizacin de cdigo y la separacin de conceptos. Se propone utilizar MVC debido a que permite
la reutilizacin y el desacoplamiento de cdigo, principios de la orientacin a servicios; adems
permite la implementacin de la aplicacin mediante mdulos claramente identificados y
separando la capa de persistencia, la lgica de negocio y la presentacin en la aplicacin.
2.3. Patrones de diseo
Facade.- El patrn estructural Fachada (en espaol), sirve para simplificar la comunicacin entre
dos objetos mediante la utilizacin de una interfaz que hace de puente entre el cliente y una interfaz
sencilla y sta se conecta con otras interfaces ms complejas. En el presente prototipo se utiliza
el patrn Facade para:
Proporcionar una interfaz sencilla ante el cliente, ocultando al cliente los componentes de
los subsistemas.
Data Access Object (DAO).- Oracle (n.d.) menciona que el patrn de diseo Core JavaEE
conocido como DAO se utiliza para abstraer y encapsular todo el acceso a la fuente de datos. El
DAO gestiona la conexin con la base de datos para obtener y almacenar datos. Es decir que este
patrn sabe que fuente de datos es (ya sea una base de datos, un archivo plano, archivo XML,
etc.) ocultando para la aplicacin los detalles de acceso a los datos, bajando el nivel de
acoplamiento entre las clases.
DAO acta como intermediario entre la aplicacin y la base de datos por medio de una API. Esta
API generalmente consiste en mtodos CRUD (Create, Read, Update, Delete), en nuestro caso
utilizaremos Java Persistence Api (JPA), para acceder a los datos:
Java Persistence Api.- Este api ms conocido como JPA es una especificacin que posee
varias implementaciones como Hibernate, ObjectDB, EclipseLink, Apache OpenJPA, etc.
52
cantidad de datos, facilidad de uso y portabilidad para trabajar en distintas plataformas y sistemas
operativos. Dentro de las ventajas para utilizar este motor de base de datos se pueden citar las
siguientes:
Metro.- Es un framework para el desarrollo de servicios web de alto rendimiento, extensible y fcil
de usar, es parte o est incluido dentro del servidor de aplicaciones Glassfish a partir de su versin
2, aunque tambin est dentro de JBoss, Oracle WebLogic Server, pero puede ser utilizado
tambin fuera de l. Este Metro es una coleccin de tecnologas tales como: JAX-WS, JAXB y
WSIT, para la implementacin y la interoperabilidad de servicios web. Metro permite utilizar HTTP
a nivel de transporte, adems la fiabilidad de mensajes (Reliability) mediante la implementacin de
especificaciones de WS-Security.
Los componentes principales de Metro son 2: JAX-WS RI y WSIT. Tecnologas que describiremos
a continuacin:
JAX-WS.- Es un API usado para la implementacin de servicios web XML, JAX-WS promueve la
interoperabilidad SOAP, es parte de la plataforma Java EE y de la distribucin de Metro descrita
anteriormente, y es open source, Usa Java Architecture XML Binding (JAXB) para acceder
procesar los documentos XML desde una aplicacin java sin tener que ser experto en
procesamiento XML.
JAX-WS permite desarrollar servicios web que se comunican a travs de XML, utilizando mensajes
orientados a llamadas a procedimientos remotos (RPC) representado en el protocolo SOAP, ste
protocolo define la estructura y la codificacin de las llamadas y respuestas de los mensajes a
travs de HTTP. Por eso una de las razones por la cual se utilizar este API es porque ayuda a
ocultar la complejidad de los mensajes SOAP, incluyendo todas las funcionalidades de los
mensajes SOAP como WS-Addressing.
WSIT.- Web Services Interoperability Technologies (WSIT), anteriormente conocido como
Proyecto Tango, es una tecnologa de la pila de Metro, encargada de la interoperabilidad de
servicios web, siendo la interoperabilidad la base principal de la orientacin a servicios incluido en
54
este estudio. La seguridad soportada por WSIT es una implementacin de OASIS WS-Security,
WS-Trust, WS- Secure Conversation, WS-Security Policy, que proveen un framework para
asegurar el intercambio de mensajes SOAP garantizando la interoperabilidad, integridad y la
confidencialidad del contenido de los mensajes. WSIT se compone de una serie de Apis de Java
y extensiones para el protocolo SOAP que permiten implementar caractersticas WSInteroperability (WS-I) como se puede ver en la Figura 18:
Core XML
XML
Optimization
XML Namespace
Reliability
SOAP
XML Infoset
WS-ReliableMessaging
MTOM
XML Schema
WS-Coordination
WS-Addressing
WS-Atomic Transaction
Bootstraping
WSDL
Seguridad
WS-Security Policy
WS-Security
WS-Policy
WS-Trust
WS-MetadataExchange
WS-SecureConv ersation
Netbeans IDE conjuntamente con WSIT provee de mecanismos de seguridad implementados por
WSIT para configuracin tanto en el servicio como en el cliente, Estos mecanismo son:
55
El presente trabajo est enfocado a la seguridad de los servicios web, por tal razn nos referiremos
a la parte de seguridad, optimizacin de mensajes y a la mensajera fiable utilizando: SOAP,
WSDL, WS-Security Policy y WS-Security, y como mecanismos de autenticacin: SAML Sender
Vouches with Certificates, descritos a continuacin:
2.5. Identificacin de protocolos y estndares de seguridad
SOAP.- Simple Object Access Protocol (SOAP), es un protocolo estndar para el intercambio de
informacin estructurada por medio de XML, siendo de fcil entendimiento para el ser humano. Lo
mensajes SOAP se transportan encapsulados por medio de otros protocolos como SMTP, HTTP,
etc. Los mensajes tanto de peticin como de respuesta contienen las siguientes partes (Figura 19):
Envelope.- Este elemento es obligatorio en el mensaje, contiene los otros dos elementos
del mensaje. Aqu se declara todos los namespace de los atributos adicionales.
Header.- Este elemento es opcional, es decir que puedo o no estar presente en el mensaje,
contiene informacin sobre el procesamiento del mensaje durante el acceso al mensaje,
como tokens de seguridad, control de cabeceras, etc.
Body.- Elemento obligatorio, contiene los datos del mensaje, aqu se especifica el
intercambio de informacin entre el remitente y destinatario del mensaje SOAP.
La utilizacin de SOAP tiene como ventajas el no estar asociado a ningn lenguaje ni a ningn
protocolo y permitir interoperabilidad. En la Figura 19 podemos ver un ejemplo de SOAP Request
y SOAP Response del servicio web implementado en el presente trabajo. Cabe mencionar que
este servicio ests sin seguridades.
56
Tipos <types>.- Contiene las definiciones de los tipos de datos usados en el mensaje, por
ejemplo XSD que es un tipo de datos definidos por XML Schema.
Mensajes <message>.- Contiene informacin necesaria de los mensajes para realizar una
operacin de entrada y salida. Cada mensaje est compuesto por partes y cada parte tiene
su nombre y su tipo de datos definidos anteriormente.
Tipo de puerto <portType>.- Se define las operaciones permitidas y los mensajes que se
utilizan para realizar la operacin. Un tipo de puerto es una agrupacin lgica de
operaciones relacionadas entre s.
57
Puerto <port>.- Asocia el binding con el punto de conexin del servicio (URI) donde se
puede acceder al servicio.
Servicio <service>.- Un servicio define un tipo de puerto con un Binding a travs de una
direccin. Define los puntos o puertos finales de los bindings.
Serv ice
Port
PortType
Binding
Operation
Message
58
Security Token
Serv ice
Recibir Tokens para
aadir al mensaje
SOAP
Validar tokens
Donde el cliente enva una peticin solicitando los tokens necesarios para la seguridad en la
comunicacin; el Security Token Service valida estas peticiones enviadas al web service
mediante Kerberos o certificados X.509 y aade los tokens a las cabeceras del mensaje SOAP, de
tal modo que se implementa una firma digital en la cabecera del mensaje que incluye la informacin
necesaria, garantizando as la integridad, confidencialidad y el no repudio para responder al
cliente.
WS-Interoperability.- Web Service Interoperability Organization (WS-I) es el encargado de
asegurar la interoperabilidad entre las distintas tecnologas que se implementan en SOAP. Este
estndar toma en cuenta las siguientes consideraciones (Ordez Len, 2010):
SAML.- Security Assertions Markup Language (SAML) especificacin definida por OASIS, define
un esquema para XML para el intercambio de informacin que permite la autenticacin entre
dominios de seguridad en aplicaciones distribuidas. SAML proporciona tokens de seguridad que
contienen aserciones o afirmaciones por las cuales las partes interesadas (usuarios finales y
servidor) pueden comunicarse. Google es una de las empresas que utiliza autenticacin SAML en
sus aplicaciones como Gmail o Google Calendar.
59
Nav egador
Prov eedor de
Identidad
Get Recurso
Redirecciona al Id Proveedor
2
Autenticacin de usuario
4
Pgina HTML peticin de autenticacin
5
Post SAML respuesta de autenticacin
6
Recurso
7
Donde se el usuario a travs del navegador solicita un recurso HTTP al proveedor del servicio,
ste lleva a cabo un control de seguridad en nombre del recurso de destino, re direccionando la
peticin al proveedor de identidad, el cual solicita al usuario sus respectivas credenciales (tales
como usuario y contrasea), que son enviadas al proveedor del servicio; El proveedor de
identidad al validar correctamente estas credenciales del usuario se crean aserciones SAML
integradas al navegador devolviendo una respuesta correcta al usuario.
WS-Security Policy.- Es una especificacin para servicios web basada o derivada de WS-Policy,
proporciona una forma ms simple de configurar limitaciones o requerimientos de seguridad de los
servicios web definidos en el documento WSDL. Permite especificar ciertos tipos de afirmaciones
(Sosnoski, 2011):
60
Supporting
token
assertions:
<sp:SupportingTokens>
and
<sp:SignedSupportingTokens>.
Protection: <sp:RequiredParts>.
WS-Security usa una estructura compleja y confusa para implementarla manualmente, por tal
razn la mayora de los framework para servicios web integran una interfaz dinmicas para la
creacin de estos documentos; por ejemplo Metro es una herramienta que a travs de WSIT facilita
esta difcil tarea. La intencin de WS-Security Policy es proporcionar la suficiente informacin para
la compatibilidad e interoperabilidad para el intercambio seguro de mensajes.
Como propuesta para el desarrollo del prototipo en la Figura 23, se propone el siguiente esquema
general de seguridad para la construccin del servicio web:
Calidad
WS-Security
SAML
WS-SecurityPolicy
Ecriptacin
Firma Digital
Descripcin
WSDL
Mensaj era
SOAP
Transporte
HTTPS
Core XML
XML
61
COMPONENTE
NOMBRE
DESCRIPCIN
Estructurar la codificacin y ocultar la lgica de negocio de la
aplicacin para el cliente. Adems que permite la reutilizacin
Facade
Patrones
Lenguaje
Programacin
de
Java 1.7
Base de Datos
MySQL 5.0
Servidor de
Aplicaciones
su api JAX-WS.
Framework para la implementacin de servicios web SOAP,
contiene una pila de tecnologas y proyectos como JAX-WS y
Framework
Metro 2.3
Estndares de
Seguridad
WS-Security 1.0
62
mediante
la
autenticacin,
asegurado
la
WS-Security Policy
1.2
Transporte
HTTPS / SSL
Fuente: Autor
Elaboracin: Autor
63
CAPTULO III
DISEO DE LA SOLUCIN
64
En el presente captulo se expone el diseo de un servicio web SOAP, el cual permite que los
mensajes XML pueden transportarse por diversos protocolos de transporte, pero en ste caso
utilizaremos HTTP ya que es el protocolo ms utilizado; al utilizar HTTP significa que cada mensaje
debe pasar por varios nodos, pudiendo stos nodos modificar el contenido de los mensajes
afectando as la confidencialidad de los datos; es decir que a diferencia de servicios web basados
en REST que solo soportan HTTPS, los servicios web SOAP soporta las especificaciones de WSSecurity, asegurando la comunicacin de origen a destino y no solo de punto a punto. Comparacin
que se menciona por Navarro Marset (2006),entre otras ms.
Con la finalidad de que la aplicacin web contenga una seguridad adecuada que implique
autenticacin, autorizacin de los servicios web, la encriptacin de los datos sensibles y la
prevencin de ataques de SQL injection y ataques XSS, se implementar diferentes mtodos,
estndares y especificaciones como: WS-Security, SSL descritas en captulos anteriores.
3.1 Diseo Arquitectnico de la aplicacin
El diseo de la aplicacin propuesta como solucin tiene 2 componentes: Aplicacin Cliente y
Servicio Web y. El componente de Aplicacin Cliente es quien consume las operaciones y mtodos
del servicio web mediante mecanismo de seguridad del WS-Security; el componente de Servicio
web contiene toda la lgica de negocio y el acceso a datos, representado mediante el WSDL, como
podemos observar en la Figura 24:
65
Glassfish (JAX-WS)
WS-Security
Digital Certificates
HTTPS
SAML
Facade
Web
Serv ice
Business
Logic Serv ice
DAO
Persistence
Client App
SOAP
Encrypted Data
SOAP
JPA
JSON
Decrypted Data
MySQL (Store
Procedures)
A continuacin se describe cada uno de los componentes del diseo arquitectnico propuesto
anteriormente:
3.1.1. Web Service
La aplicacin de Servicio Web es donde se encuentran el acceso a los datos, la lgica de negocio
y lo concerniente a la seguridad, contiene los siguientes componentes:
Facade Web Service.- En esta capa es la encargada de implementar una fachada o interfaz
de la aplicacin, donde se invocaran los sub mtodos para acceder a los datos mediante
la capa de lgica de negocio.
66
SQL Injection.- Para evitar los ataques de SQL Injection implementar siguiendo las
recomendaciones de OWASP, el uso de procedimientos almacenados, que son programas
que estn alojados en la base de datos, los cuales trabajan directamente con el motor de
base de datos brindando mayor rapidez en el acceso a datos y evitando as la insercin
de sentencias SQL en la codificacin de la lgica de negocio. Adems se utilizar otra
recomendacin de OWASP como el de dar permisos y privilegios a usuarios de la base de
datos; en este caso como los servicios web solo harn consultas es decir recuperar
informacin, el usuario solo podr ejecutar llamadas a los procedimientos almacenados.
De este modo se puede asegurar la integridad de los datos.
XSS.- Los ataques de XSS se mitigarn con el uso de filtros, es decir una limpieza o
validacin de los datos de entrada ingresados por el usuario, ya que toda entrada de
67
usuario se puede definir como maliciosa, por tanto mediante un mtodo se limpia estos
parmetros de entradas a la aplicacin.
SAML Authorization Vouches with Certificates.- Este mecanismo de seguridad provisto por
WSIT protege los mensajes SOAP con certificados mutuos entre el cliente y servidor resguardando
la integridad y confidencialidad por medio de la autorizacin SAML. El remitente garantiza con
tokens la autorizacin para la comunicacin aadiendo las aserciones SAML en los mensajes
SOAP.
En este mecanismo, el token SAML se incluye como parte de la firma del mensaje como un token
de autorizacin y slo se enva al destinatario. La carga til del mensaje debe ser firmado y
cifrado. El solicitante est avalando las credenciales (presentes en la asercin SAML) de la entidad
en nombre de la cual el solicitante est actuando.
El token iniciador, que es un token de X.509, es utilizado para la firma. El token receptor, que
tambin es un token de X.509, se utiliza para el cifrado. Para el servidor, esto se invierte, el token
destinatario es la firma de contadores y el token iniciador es el token cifrado. Un token SAML se
utiliza para la autorizacin.
Para la correcta configuracin de este mecanismo en la Tabla 8 se exponen ciertos requerimientos
tanto en el servidor como en el cliente que deben cumplir.
68
Keystore
Truststore
Cliente
Si
Si
Si
Servidor
Si
Si
No
Fuente: Autor
Elaboracin: Autor
Truststore.- Contiene el certificado de confianza del cliente y del servidor, verifica las
credenciales.
SAML Callback Handler.- Es una clase implementada en el cliente donde se especifica las
devoluciones a las llamadas del manejador de aserciones SAML.
69
70
CAPTULO IV
IMPLEMENTACIN DE LA SOLUCIN
71
El presente captulo expone el proceso para la implementacin de los servicios web utilizando el
estndar SOAP, se utiliz JEE7 para el desarrollo de la lgica de negocio o el Backend y el API
JAX-WS para la creacin de servicios web SOAP. En cuanto tiene que ver con las base de datos
se construy procedimientos almacenados en MySQL, para que sean consumidos por el backend.
As mismo, a nivel de seguridad de servicios web se implement el un mecanismo de seguridad
como es SAML, y para la proteccin de los datos se cifr utilizando el algoritmo DES y se firm la
informacin de los mensajes mediante la herramienta WSIT. Para detallar el desarrollo de los
servicios SOAP se consideran los siguientes niveles de implementacin:
4.1. Base de datos
La base de datos con la cual se despliegan el servicio web se denomina pft_db, la cual est
diseada en MySQL.
Se construyeron tres procedimientos almacenados, para que desde cualquier aplicacin estos
puedan ser consumidos; por lo tanto, la lgica de accedo a los datos se maneja en la capa de
datos. En el Anexo B se encuentra detallados los procedimientos almacenados construidos para
el prototipo.
En las Figura 25 se muestra la creacin del procedimiento almacenado para la consulta de todas
las personas en MySQL, y en la Figura 26 se ve cmo se implementa stos procedimientos en
Java. Se utiliz los procedimientos almacenados para evitar los ataques de SQL Injection
expuestos en el OWASP Top Ten.
72
4.2. Codificacin
El nombre del proyecto se denomina pft-ws, para el desarrollo de este proyecto se utilizaron las
siguientes dependencias. En la Tabla 9 se detallan las tecnologas utilizadas.
Tabla 9. Apis de java utilizadas en el proyecto
NOMBRE
org.glassfish.metro
VERSIN
DESCRIPCIN
2.3
gson
javaee-web-api
2.3.1
7.0
eclipselink
2.5.2
wsit
1.3.1
Fuente: Autor
Elaboracin: Autor
En el archivo POM.xml (Project Object Model) de proyecto pft-ws se colocan las dependencias de
las APIs mencionadas en la tabla anterior de la siguiente manera (Figura 27):
73
Paquetes:
El proyecto de servicio web SOAP est conformado por los siguientes paquetes (Figura 28):
74
Paquete Entity: Dentro de este paquete se encuentran los objetos de negocio, se utiliz JPA como
ORM para realizar el mapeo de las entidades de persistencia. Para la conexin del proyecto con
la base de datos existe un archivo denominado persistence.xml, es en este archivo donde se
configura la conexin. En la Figura 29 se indica la configuracin que permite mapear un objeto de
negocio con cada tabla de la base de datos pft_db:
Adems para el acceso a la base de datos se realiz una configuracin para la conexin con
MySQL, donde se especifica el nombre de la base de datos, el puerto, el usuario y claves de
acceso. El archivo que contiene estos datos se llama glassfish-resources.xml, como podemos
observar en la Figura 29:
75
Paquete Dao: En este paquete se encuentra las clases que permiten realizar el acceso a datos,
se utiliz el patrn de diseo Data Abstract Object (DAO). En la Figura 30 se indica las clases que
conforman este paquete.
Con el patrn de diseo DAO podemos dividir las responsabilidades dentro de la aplicacin, en la
figura anterior podemos observar las clases encargadas en el acceso a datos la cual heredan los
mtodos y atributos de la clase AbstractDao, la clase AbstractDao es la encargada realizar las
operaciones CRUD de cualquier tipo de objeto debido a que recibe como parmetro un clase
genrica en su constructor.
76
Paquete Service: En este paquete contienen las clases que conforman la lgica de negocio de la
aplicacin. Se utiliz el patrn de diseo Facade, simplificando al mnimo la comunicacin entre
subsistemas. En la Figura 31 se indica las clase PftPersonaService que se encuentran dentro de
este paquete y cmo se comunican con las clases del acceso a datos.
interface
dao::PftPersonaDao
+
+
+
+
+
+
+
+
+
buscarPorCedula(String) : PftPersona
buscarTodo() : List<PftPersona>
count() : int
create(PftPersona) : void
edit(PftPersona) : void
find(Object) : PftPersona
findAll() : List<PftPersona>
findRange(int[]) : List<PftPersona>
remove(PftPersona) : void
AbstractDao
implement::PftPersonaDaoImplement
+
+
+
buscarPorCedula(String) : PftPersona
buscarTodo() : List<PftPersona>
PftPersonaDaoImplement()
-personaDao
implement::PftPersonaServ iceImplement
-
personaDao: PftPersonaDao
+
+
buscarPorCedula(String) : PftPersona
buscarTodo() : List<PftPersona>
interface
PftPersonaServ ice
+
+
buscarPorCedula(String) : PftPersona
buscarTodo() : List<PftPersona>
Por lo tanto se puede concluir que las clases que conforman el paquete DAO proveen una interfaz
a las clases del paquete Service para el acceso a datos, y que las clases del paquete Service
manejan la lgica de negocio para la gestin de los proyectos fin de carrera y proveen una interfaz
para los servicios web.
Paquete ws: Dentro de este paquete se encuentran una clase denominada PftWebService en
donde se encuentran los servicios web, para la construccin de los servicios web se utiliz JAXWS que permite construir servicio REST y SOAP, aunque la finalidad de este API son los servicios
SOAP. As mismo se encuentra una clase llamada Encripta, dentro de esta clase se tiene un
mtodo que permite encriptar y desencriptar un texto plano usando el algoritmo DES.
A continuacin se indica cada servicio construido.
77
Servicio getPersonas: Este mtodo devuelve todos los usuarios de la base de datos
pft_db, se utiliza un servicio EJB denominado personaService para manejar la lgica de
negocio para la obtencin de los datos (Figura 32).
Servicio personaPorCdula: Este mtodo permite obtener una persona cuyo nmero de
identificacin sea igual al enviado como parmetro (Figura 34).
78
El api JAX-WS permite generar automticamente el archivo WSDL, donde se especifica los
puertos, las entradas y salidas de las operaciones que contiene el servicio web, sin seguridad. A
travs de este documento se puede acceder a las operaciones del servicio web mediante una
aplicacin cliente. En el Anexo C, se muestra el archivo generado del servicio web implementado:
Una vez desarrollado los servicios web, el siguiente paso es la configuracin de seguridad, que
permiten evadir las vulnerabilidades expuestas en OWASP.
4.3. Seguridad
4.3.1. Servicio Web
Configuracin SAML.- Para la confidencialidad y proteccin de los datos, se utiliz una
dependencia denominada webservices-rt que posee algunos mecanismos de seguridad, el
mecanismo de seguridad seleccionado es SAML Authorization Vouches with Certificates. En
el Anexo D, se indica los pasos para la configuracin de este mecanismo de seguridad en el
servicio web.
Una vez realizados los pasos del anexo D, el documento WSDL de anexo C se modifica
aadindose todas las aserciones y las polticas de seguridad, como se muestra a continuacin:
1.
2.
3.
4.
5.
6.
79
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
80
65.
66.
67.
68.
69.
70.
71.
72.
<sp:Body/>
</sp:EncryptedParts>
<sp:SignedEncryptedSupportingTokens/>
<sp:SignedParts>
<sp:Body/>
</sp:SignedParts>
</wsp:Policy>
<wsp:Policy xmlns:sp="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702" wsu:Id="PftWebServicePortBinding_get_personas_Output_Policy">
73. <sp:EncryptedParts>
74. <sp:Body/>
75. </sp:EncryptedParts>
76. <sp:SignedParts>
77. <sp:Body/>
78. </sp:SignedParts>
79. </wsp:Policy>
80. <types>
81. <xsd:schema>
82. <xsd:import namespace="http://ws.wspft.utpl.edu/" schemaLocation="https://localhost:
8181/pft-ws/PftWebService?xsd=1"/>
83. </xsd:schema>
84. </types>
85. <message name="get_persona_cedula">
86. <part name="parameters" element="tns:get_persona_cedula"/>
87. </message>
88. <message name="get_persona_cedulaResponse">
89. <part name="parameters" element="tns:get_persona_cedulaResponse"/>
90. </message>
91. <message name="get_personas">
92. <part name="parameters" element="tns:get_personas"/>
93. </message>
94. <message name="get_personasResponse">
95. <part name="parameters" element="tns:get_personasResponse"/>
96. </message>
97. <message name="get_modalidades">
98. <part name="parameters" element="tns:get_modalidades"/>
99. </message>
100.
<message name="get_modalidadesResponse">
101.
<part name="parameters" element="tns:get_modalidadesResponse"/>
102.
</message>
103.
<portType name="PftWebService">
104.
<operation name="get_persona_cedula">
105.
<input wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_persona_cedula
Request" message="tns:get_persona_cedula"/>
106.
<output wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_persona_cedul
aResponse" message="tns:get_persona_cedulaResponse"/>
107.
</operation>
108.
<operation name="get_personas">
109.
<input wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_personasReques
t" message="tns:get_personas"/>
110.
<output wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_personasRespo
nse" message="tns:get_personasResponse"/>
111.
</operation>
112.
<operation name="get_modalidades">
113.
<input wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_modalidadesReq
uest" message="tns:get_modalidades"/>
114.
<output wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_modalidadesRe
sponse" message="tns:get_modalidadesResponse"/>
115.
</operation>
116.
</portType>
117.
<binding name="PftWebServicePortBinding" type="tns:PftWebService">
118.
<wsp:PolicyReference URI="#PftWebServicePortBindingPolicy"/>
119.
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="documen
t"/>
120.
<operation name="get_persona_cedula">
121.
<soap:operation soapAction=""/>
122.
<input>
123.
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy
"/>
124.
<soap:body use="literal"/>
125.
</input>
81
126.
127.
y"/>
128.
129.
130.
131.
132.
133.
134.
"/>
135.
136.
137.
138.
y"/>
139.
140.
141.
142.
143.
144.
145.
"/>
146.
147.
148.
149.
y"/>
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Polic
<soap:body use="literal"/>
</output>
</operation>
<operation name="get_personas">
<soap:operation soapAction=""/>
<input>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy
<soap:body use="literal"/>
</input>
<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Polic
<soap:body use="literal"/>
</output>
</operation>
<operation name="get_modalidades">
<soap:operation soapAction=""/>
<input>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy
<soap:body use="literal"/>
</input>
<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Polic
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="PftWebService">
<port name="PftWebServicePort" binding="tns:PftWebServicePortBinding">
<soap:address location="https://localhost:8181/pft-ws/PftWebService"/>
</port>
</service>
</definitions>
Donde se pude visualizar en WSDL que desde la lnea 8 hasta la 79, son aserciones y polticas de
seguridades, descritas a continuacin (Binu, 2015):
sp:AlgorithmSuite.- Lnea 11 a 15, indica el algoritmo utilizado para la firma, en este caso
se utiliza el algoritmo Basic128.
sp:IncludeTimestamp.- Lnea 18, marca el tiempo que se utiliza con cada mensaje.
sp:InitiatorToken.- Lnea 19 a 28, indica que la clave pblica para firmar el mensaje sera
con certificado X.509 y ser enviado con cada mensaje desde el cliente al servidor y
viceversa.
82
sp:SamlToken.- Lnea 49 a 53, indica que se utiliza aserciones de seguridad (SAML) como
tokens de seguridad.
sp:WssSamlV20Token11.- Lnea 51, indica que la versin del token SAML es 2.0.
Mediante las polticas de seguridad del WS-Security Policy listadas anteriormente, son las que
definen los requerimientos y lineamientos que debe cumplir el cliente del servicio web para poder
acceder al mismo de forma satisfactoria, por ejemplo estn definidos las aserciones y los tokens
de autenticacin de SAML, los tipos de certificados utilizados, el encriptado y firmado de los
mensajes.
Configuracin de HTTPS.- Para la configuracin del protocolo HTTPS se agreg en el archivo
web.xml del servicio web el siguiente cdigo para que la aplicacin se ejecute sobre el puerto 8181
del servidor de aplicaciones Glassfish. A continuacin se indica el cdigo para tal finalidad:
<security-constraint>
<display-name>SecurityConstraint</display-name>
<web-resource-collection>
<web-resource-name>PftResource</web-resource-name>
<description/>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<description/>
<role-name>wsit</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
83
En el archivo de configuracin web.xml se tienen que habilitar los filtros para evitar las
vulnerabilidades de XSS, Clickjacking y problemas de cabeceras, como se muestra en la Figura
36.
84
Otra configuracin importante que se realiz fue la intercepcin de script a travs de las URL por
parte de los atacantes para luego personalizarlos y enviarlos a peticin al servidor. Para ello se
desarroll
una
clase
denominada
XSSRequestWrapper
85
que
extiende
Para la exposicin de datos sensibles se utiliz un algoritmo de encriptacin DES, la cual permite
encriptar la respuesta del servicio web al cliente. As mismo el cliente podr desencriptar los datos
al momento de recibir la respuesta. Con este mecanismo estamos asegurando la confidencialidad
de la informacin y no pueda ser visualizada por los atacantes. En la Figura 38 se puede visualizar
el cdigo utilizado la encriptacin de los datos en el servicio web.
86
Tambin se configur en el archivo web.xml de la aplicacin cliente del servicio web un comando
que permite evitar la lectura y escritura de scripts por parte de los atacantes, de la siguiente manera:
<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
</session-config>
Como conclusin parcial de este captulo se puede decir que la implementacin de la solucin
propuesta para el desarrollo de servicios web seguros se lo puede hacer mediante el protocolo de
comunicacin SOAP con su especificacin WS-Security, el cual provee de mecanismos de
autenticacin como el SAML, polticas de seguridad, tokens, criptografa y firmado de mensajes,
todos estos definidos en el documento WSDL con ayuda del framework Metro. Adems de la
seguridad implementada a nivel de codificacin para evitar ataques de SQL Injection y XSS, as
como del control de cabeceras.
Una vez implementada la solucin se procede a realizar sus respectivas validaciones, para
comprobar si la aplicacin cumple con los requerimientos de seguridad (disponibilidad, integridad
y confidencialidad de los datos) planteados anteriormente. En el siguiente captulo de Validacin
se detallan dichas pruebas.
87
CAPTULO V
VALIDACIN
88
En el presente captulo se exponen los resultados de las pruebas realizas en base a tres aspectos:
Diseo Arquitectnico, Codificacin y Seguridad del prototipo; mediante la utilizacin de
herramientas que nos permitirn sacar conclusiones del presente trabajo.
5.1. Validacin de Diseo
Para la validacin del diseo del prototipo se utiliz la herramienta Structural Analysis for Java la
misma que apoya a los desarrolladores a medir la calidad del software a nivel de diseo, donde se
puede visualizar el diseo estructural, la comprensin del cdigo, la medicin de la calidad de
acuerdo a mtricas.
Como resultado se obtuvo el diagrama que se expone en la Figura 39, donde se observa que los
paquetes del prototipo estn definidos, estructurados y distribuidos, separando cada clase de otra,
acorde al diseo propuesto.
En la Figura 40, se puede apreciar la implementacin del patrn de diseo Facade, donde se
visualiza la implementacin de la clase AbstractDao.
89
90
Archivos: 42
Funciones: 178
SQALE Rating: A
Issues: 86
91
NIVEL
CANTIDAD
Critical
57
Major
25
Minor
de
excepciones
deben
Bloques duplicados
92
duplicados
reutilizar luego.
Fuente: Autor
Elaboracin: Autor
Archivos: 41
Funciones: 179
SQALE Rating: A
Issues: 57
93
Los campos de una clase "Serializable" deben ser o bien transitoria o serializable.
Estos dos issues encontrados por la herramienta no se pudieron resolver ya que todas las clases
se encuentran correctamente serializadas e igualmente sale como error en la herramienta. El otro
issue se refiere a un paquete utilizado ya no pertenece al API de Java.
5.3. Validacin de Seguridad
5.3.1. Validacin con Herramientas
Como ya se mencion anteriormente SOAP permite la construccin de servicios web seguros con
la implementacin de estndares del WS-Security, sin embargo es necesario realizar siempre
pruebas de seguridad para encontrar algn fallo que pueda existir en el prototipo. Para ello se han
seleccionado las siguientes herramientas:
En primer lugar se realizar pruebas al prototipo sin seguridad que ser la primera iteracin de la
validacin con las herramientas OZASP ZAP y Vega, los resultados se detallan en la Tabla 11:
94
NO. DE
NIVEL DEL
ALERTAS
RIESGO
Directory Traversal
Alto
Medio
Medio
Bajo
Bajo
Informativo
TIPO DE ALERTA
Vega
Fuente: Autor
Elaboracin: Autor
95
Donde se puede visualizar los datos que viajan en respuesta a la peticin, ya que se encuentra en
un protocolo no seguro como es el HTTP.
La segunda iteracin fue realizada tomando en cuenta la implementacin de estndares y
recomendaciones de seguridad, como se puede ver en la Tabla 14:
Tabla 12. Alertas del prototipo con seguridad
HERRAMIENTA
OWASP ZAP
NO. DE
NIVEL DEL
ALERTAS
RIESGO
Directory Traversal
Alto
Medio
Medio
Bajo
Bajo
TIPO DE ALERTA
96
Alto
Informativo
Informativo
Fuente: Autor
Elaboracin: Autor
Directory Transversal.- Este tipo de inseguridad ocurre cuando no existe una validacin de
usuarios, permitiendo el acceso a directorios restringidos. Mediante esta vulnerabilidad los
atacantes pueden visualizar informacin secreta, descargando estos archivos privados.
Web Browser XSS Protection Not Enabled.- La cabecera XSS Protection permite activar y
desactivar filtros XSS.
X-Content-Type-Options Header Missing.- Esta cabecera impide que los navegadores lean
otro tipo de contenido al declarado.
Page Fingerprint Differential Detected.- Possible Local File Include.- Significa que el
atacante puede tener acceso no autorizado a archivos confidenciales de la aplicacin web,
en alguna ruta o entrada dada en la URL.
97
Adems se implement SAML para la parte de autenticacin de los servicios web; si no se hace
las respectivas configuraciones tanto en el cliente como en el servicio, el cliente no podr acceder
a los datos que retorne el servicio web, como se puede ver la Figura 46:
La aplicacin cliente no puede acceder a la informacin debido a los siguientes errores descritos a
continuacin (Figura 47):
Grave:
Grave:
UsernameCallback
98
99
Una de las vulnerabilidades que pueden ocurrir sobre un servicio web es la inyeccin SQL, en la
Figura 49, se observa que se puede introducir en la URL una consulta para obtener los datos de
una persona por un criterio de bsqueda, le introducimos la siguiente inyeccin SQL:
http://localhost:8080/pft-ws-client-vulnerable/PersonaServlet?cedula= ''or ''=''
Se puede observar que al no contener ninguna seguridad para evitar esta vulnerabilidad es posible
acceder a todos los datos tan solo enviando como para parmetro el siguiente cdigo SQL: ''or
''=''. Muchos de los casos de las Inyecciones SQL se dan por el cdigo que se utiliza ya sea en
una consulta en lenguaje SQL, o en nuestro caso que se utiliza JPA.
Por lo tanto el hecho que se utilice un ORM, no significa que no exista riego en los ataques SQL.
En la Figura 50, se muestra el cdigo incorrecto que se utiliza para obtener las personas por cdula.
100
Se puede observar que se utiliza una consulta nativa utilizando JPA, sin embargo la consulta queda
abierta para que se pueda introducir mediante el parmetro cedula una consulta SQL
En la Figura 51, se indica el cdigo correcto a implementar para evitar un ataque SQL Injection.
Se puede observar que la entrada que enva un usuario como parmetro es preparada en
query.setParameter (cedula) esto hace que todas las entradas sean tomadas como texto y no
como sentencias SQL, es decir si se enva ''or ''='', significa que es una cedula y no sentencia
SQL. En la Figura 52, se observa que no se produce el mismo resultado del caso anterior, es decir
no se puede hacer un ataque de SQL Injection.
101
En la Figura 54, se puede comprobar que se insert el cdigo script en la base de datos sin ningn
problema, ya que no existe ninguna validacin de los datos de entrada en el prototipo, ahora al
momento que se desee recuperar dicha clave se ver reflejada dicha alerta, a este tipo de ataque
se lo conoce como XSS almacenado.
En la Figura 55, podemos observar en el navegador web el servicio para recuperar la clave de un
usuario anterior, donde se ejecuta el script almacenado en la base de datos.
102
Para evitar este tipo de ataque se procedi a la validacin los datos de entradas en el prototipo
donde se utiliz un cdigo que limpia los parmetros enviados, la podemos observar en la Figura
48, anteriormente citada, que no permite la introduccin de cdigos maliciosos.
103
CONCLUSIONES
Al trmino del presente proyecto fin de carrera y cumpliendo con cada objetivo se ha llegado a las
siguientes conclusiones:
SonarQube a travs del anlisis esttico permite validar la calidad del cdigo, Structural
Analysis for Java permite la validacin de la estructuracin de las clases del prototipo
representando las misma de forma visual.
104
RECOMENDACIONES
Para el desarrollo de servicios web con el protocolo SOAP se recomienda utilizar el API de
Java JAX-WS, que permite el uso de tecnologas como como Metro y WSIT que ayudan a
la implementacin de estndares de seguridad como WS-Security para proteger la
informacin sensible.
como
WS-Trust,
WS-Reability,
WS-SecureConversation,
WS-
Hay que tener en cuenta que no se pueden resolver algunos de los problemas encontrados
por SonarQube, ya que esta herramienta posee estndares no acordes con el lenguaje de
programacin Java, como por ejemplo serializacin de clases y la utilizacin de APIs
antiguas.
105
BIBLIOGRAFA
Ahumada Ahumada, J. F. (2013). Documentacin de Arquitecturas de Sistemas en un Banco.
Retrieved
from
http://www.tesis.uchile.cl/bitstream/handle/2250/113666/cfahumada_fa.pdf?sequence=1
Almeida, A. S., & Perez, V. (2011). Arquitectura de Software: Estilos y Patrones. Universidad
Nacional
de
la
Patagonia
San
Juan
Bosco.
Retrieved
from
http://www.dit.ing.unp.edu.ar/graduate/bitstream/123456789/203/1/Tesina Arquitectura
de Soft.pdf
Anaya Lopez, E. (2011). Implementacin de controles de seguridad en Arquitecturas
Orientadas a Servicios (SOA) para servicios web. Instituto Politcnico Nacional.
Retrieved from http://148.204.210.201/tesis/1313442753812TesisEmilioAn.pdf
Andrade, K., Jimenez, J., & Valencia, O. (2013). Anlisis para la deteccin de vulnerabilidades
en la aplicacin web COLIBRI II. Retrieved from file:///C:/Users/Miguel
Tenezaca/Downloads/1-1-1-PB.pdf
Aperador, M. (2012). Caractersticas de los Servicios web y como consumirlos. Retrieved from
https://prezi.com/lwbginvwiod4/caracteristicas-de-los-servicios-web-y-comoconsumirlos/
Arias, J., & Fernndez, N. (2009). Servicios Web. Madrid-Espaa. Retrieved from
http://ocw.uc3m.es/ingenieria-telematica/tecnologias-de-distribucion-decontenidos/transparencias_tdc/servicios-web-i-soap-wsdl.pdf
Arquitectura Orientada a Servicios. (2011). Retrieved December 5, 2014, from http://soafpuna.blogspot.com/2011/11/ventajas-y-desventajas.html
Arsanjani, A. (2004). Service-oriented modeling and architecture, 114. Retrieved from
http://www.ibm.com/developerworks/webservices/library/ws-soa-design1/ws-soadesign1-pdf.pdf
Barraza, F. (n.d.). Modelado y Diseo de Arquitectura de Software. Cali. Retrieved from
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:s2_conceptosdemodelado.p
df
Binu, G. (2015). Globinch Foro de Java. Retrieved from http://java.globinch.com/enterprisejava/web-services/jax-ws/secure-web-services-signatures-encryption-security-withmetro/
Bosch, J. (2000). Design and Use of Software Architectures. Harlow-UK: Addison-Wesley.
Retrieved
from
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.105.6346&rep=rep1&type=pdf
Buschmann, F., Meunie, R., Rohnert, H., Sommerlad, P., & Stal, M. (2000). Pattern Oriented
Software Architecture. A System of Patterns. Inglaterra: John Wiley & Sons.
http://doi.org/ISBN: 978-0-471-95869-7
106
Camacho, E., Cardeso, F., & Nuez, G. (2004). Arquitecturas de Software. Gua de
estudio.[En Lnea], 158. Retrieved from http://prof.usb.ve/lmendoza/Documentos/PS6116/Guia Arquitectura v.2.pdf
Cervantes,
H.
(2010).
Arquitectura
de
Software.
http://sg.com.mx/revista/27/arquitectura-software#.VKgIStKG9Y5
Retrieved
from
from
107
from
Oracle. (n.d.). Oracle- Patrones J2EE Core - Data Access Object. Retrieved from
http://www.oracle.com/technetwork/java/dataaccessobject-138824.html
Ordez Len, P. R. (2010). Definicin de un esquema de seguridad en servicios web para la
Universidad Tcnica Particular de Loja. Universidad Tcnica Particula de Loja. Retrieved
from http://dspace.utpl.edu.ec//handle/123456789/1585
OWASP. (2013). OWASP The Open Web Application Security Project. Retrieved from
https://www.google.com.ec/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CD8Q
FjAE&url=http%3A%2F%2Fowasptop10.googlecode.com%2Ffiles%2FOWASP%2520T
op%252010%2520-%25202013.pdf
Patio Castillo, L. G. (2014). Anlisis comparativo de Metro y AXIS2 para el desarrollo de
aplicaciones que consuman servicios web WCF en la ESPOCH. Escuela Superior
Pplitcnica
de
Chimborazo.
Retrieved
from
http://dspace.espoch.edu.ec/bitstream/handle/123456789/3325/18T00548.pdf
Reynoso, C. (2004). Introduccin a la Arquitectura de Software. Universidad de Buenos Aires,
127. Retrieved from http://carlosreynoso.com.ar/archivos/arquitectura/Arquitecturasoftware.pdf
108
109
ANEXOS
110
A.
B.
NOMBRE
PARMETROS
get_modalidades
No aplica
get_all_persona
No aplica
get_persona_byIdentific
acion
Fuente: Autor
Elaboracin: Autor
DNI VARCHAR(250)
RESULTADO
Permite obtener todos los programas
acadmicos
Permite devolver todos los usuarios
Permite devolver un usuario que coincida
con el DNI ingresado como parmetro.
C.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
113
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Policy"/>
<soap:body use="literal"/>
</output>
</operation>
<operation name="get_personas">
<soap:operation soapAction=""/>
<input>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy"/>
<soap:body use="literal"/>
</input>
<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Policy"/>
<soap:body use="literal"/>
</output>
</operation>
<operation name="get_modalidades">
<soap:operation soapAction=""/>
<input>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy"/>
<soap:body use="literal"/>
</input>
<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Policy"/>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="PftWebService">
<port name="PftWebServicePort" binding="tns:PftWebServicePortBinding">
<soap:address location="http://localhost:8080/pft-ws/PftWebService"/>
</port>
</service>
</definitions>
114
D.
A continuacin se detallan los pasos a seguir para la configuracin del mecanismo de seguridad
SAML en el servicio web:
1. Seleccionar el servicio web y editar los atributos del servicio web, como se visualiza en la
Figura 57:
115
3. Este mecanismo se seguridad trabaja con certificados SSL, por lo cual se debe hacer
referencia a la ubicacin de estos archivos que contiene informacin para que el cliente del
servicio web pueda autenticarse satisfactoriamente, as mismo de establecer las
contraseas del keystore y truststore. Cabe recalcar que para el presente proyecto se usar
los certificados que viene predefinidos en el servidor de aplicaciones Glassfish. En las
Figuras 59 y 60 se muestra dicha configuracin.
116
117
118
E.
A continuacin se indican los pasos para configurar las credenciales de seguridad en el lado del
cliente para que pueda acceder correctamente al servicio web con el mecanismo de autenticacin
SAML.
1. Para este paso el servicio web tiene que estar ejecutndose con todas las polticas de
seguridad para que la importacin del archivo WSDL sea correcto en el cliente (Figura 62).
2. Una vez cargado el Servicio web en el cliente, editamos los atributos del servicio web
(Figura 63).
119
4. Por ltimo se debe seleccionar una clase llamada SamlCallBackHandler que realizar la
autorizacin a los servicio mediante los certificador SSL, como se muestra en la Figura 45.
La clase SamlCallBackHandler se descarga de la pgina:
https://xwss.java.net/servlets/ProjectDocumentList?folderID=6645&expandFolder=6645&f
olderID=6645, y se lo implementa en nuestro proyecto cliente y se modifica con los datos
de los certificados utilizados.
120