PDF de programación - Fortalecimiento en la Seguridad de Web Services para Aplicaciones Críticas

Fortalecimiento en la Seguridad de Web Services para

Aplicaciones Críticas

Eduardo Casanovas, Fernando Boiero, Carlos Tapia

Instituto Universitario Aeronáutico, Facultad de Ingeniería, Av. Fuerza Aérea 6500, Córdoba,

Provincia de Córdoba, Argentina

[email protected], [email protected],

[email protected]

la

teniendo en consideración que

Resumen. Reconociendo a las propiedades de la Seguridad de la Información
(confidencialidad, integridad y disponibilidad) como elementos esenciales de
cualquier transferencia de datos, haciendo foco en el conjunto de protocolos y
estándares utilizados para intercambiar datos entre aplicaciones web, es decir,
Web Services, para el presente trabajo definimos el objetivo general de asegurar
dichas comunicaciones,
información
intercambiada es igual o más crítica y confidencial que la transferida entre
sistemas informáticos con la interacción humana.
Vamos a definir a las Aplicaciones Críticas, aquellas que se encuentran corriendo
dentro de las Infraestructuras Críticas, siendo éstas las definidas por la Oficina
Nacional de Tecnología de Información (ONTI), dependiente de la Jefatura de
Gabinete de Ministros. En este marco es que los aspectos de seguridad cobran
una relevancia superior y por tanto los esfuerzos para segurizar los sistemas
deben ser extremos. Bajo este objetivo general, se definieron lineamientos
particulares para efectuar lo que denominamos “hardening de seguridad de Web
Services”, lo que implica la conformación de una guía mediante la cual se
establecen medidas de seguridad que ayudan a disminuir los riesgos de violación
de las propiedades de seguridad mencionadas.


Palabras clave. web service, Infraestructuras Críticas, Seguridad Informática,

cifrado, firma digital, XML, ONTI, security hardening.


1 Introducción

La Seguridad Informática es prioritaria en cualquier ambiente de tecnología
donde se procese información computarizada, más aún cuando nos referimos al
procesamiento de datos dentro de las Infraestructuras Críticas [01] de un país.
Por Infraestructuras Críticas se entiende aquellas instalaciones, redes, servicios y
equipos físicos y de tecnología de la información cuya interrupción o destrucción
pueden tener una repercusión importante en la salud, la seguridad o el bienestar

IETFDay 2015, 1º Taller del Grupo de Trabajo de Ingeniería de Internet/Argentina. 44 JAIIO - IETFDay 2015 - ISSN: 2451-76234 transmitida,

económico de los ciudadanos o en el eficaz funcionamiento de los gobiernos de
los Estados a los que pertenecen.

El concepto primario, el aspecto clave desde el que hay que partir, no es tanto la
Infraestructura en sí, sino la función que ésta desempeña o el servicio que presta.
En este marco, surge también el concepto de Aplicación Crítica, es decir, aquellos
sistemas vitales que funcionan dentro de una Infraestructura Crítica. Por ejemplo,
dentro de un aeropuerto (que podría considerarse una Infraestructura Crítica
civil), el sistema que permite monitorear por radar a las aeronaves es una
Aplicación Crítica.
Continuando con nuestro ejemplo del aeropuerto, cuando la Aplicación Crítica
“Sistema de Radar” detecta una potencial colisión o proximidad riesgosa entre 2
aeronaves, se debe comunicar con otro sistema que gatilla alertas tempranas e
informa a los servicios de emergencia. La comunicación entre ambos sistemas se
establece mediante Web Services (WS), y de allí que sea vital proteger la
información
teniendo en cuenta que errores u omisiones,
intencionales o accidentales, pueden derivar en una catástrofe.
Mediante este razonamiento es que se propone en el presente trabajo una suerte
de guía para defender a los Web Services que utilicen las Aplicaciones Críticas
de cualquier Infraestructura Crítica.


2 Desarrollo

Los Web Services son servicios de intercambio de datos entre aplicaciones que
utilizan una serie de protocolos estándares controlados por las organizaciones
W3C, OASIS o el WS-I, siendo estos protocolos, por ejemplo, el Simple Object
Access Protocol (SOAP), el Web Services Definition Language (WSDL) y el
Universal Description Discovery and Integration (UDDI), los cuales en esencia
permiten las transferencias de datos independizándose de los lenguajes de
programación en que fueron programadas las aplicaciones intervinientes.

En relación a los protocolos mencionados, el WSDL es el encargado de poner a
disposición una API (Application Programming Interface) en un formato
comprensible para cualquier sistema. Para ello, se vale del lenguaje XML y
determina los requisitos funcionales necesarios para establecer la comunicación
con el Web Service.

Luego, el protocolo SOAP define la manera en la que se efectuará el intercambio
de información mediante XML. Los clientes de conexión utilizan SOAP para
efectuar las llamadas a las funciones disponibles mediante la API WSDL.

Por su parte, UDDI se utiliza para publicar la información asociada al Web
Service y permite comprobar su disponibilidad y estado.


IETFDay 2015, 1º Taller del Grupo de Trabajo de Ingeniería de Internet/Argentina. 44 JAIIO - IETFDay 2015 - ISSN: 2451-76235 En forma gráfica, el funcionamiento de un Web Service genérico puede
esquematizarse de la siguiente manera:


Imagen 1 - Esquema genérico de un Web Service



Los principales riesgos de seguridad de Web Services podrían resumirse en los
siguientes ítems:

● No fueron gestados con conceptos de seguridad embebidos.
● Los datos transferidos son confidenciales y deben ser protegidos de igual

modo que la información contenida en las bases de datos.

● Existe la posibilidad de captura de la información en texto plano en tránsito.
●
Falta de mecanismos de validación de identidad o autenticación para
consumir la información brindada por el Web Service.
Interferencia en el canal de comunicación.
Interrupción del servicio y falta de plan de contingencia.

●
●


Estos riesgos pueden materializarse en ataques como los siguientes:
● A nivel de aplicación:

-

-

-

Las aplicaciones transfieren datos relevantes de los procesos de negocio
de la organización.
Los bugs de diseño, errores de reglas de negocio, se mantienen con o sin
WS.
Cualquier ataque de la guía OWASP [02] se mantiene.

● A nivel de SOAP (Simple Object Access Protocol):

-
-

Interfaces escritas con WS Description Language.
En general no se implementan controles de acceso a WSDL.


● A nivel de XML:

-

Es un estándar para representación de sets de datos.

IETFDay 2015, 1º Taller del Grupo de Trabajo de Ingeniería de Internet/Argentina. 44 JAIIO - IETFDay 2015 - ISSN: 2451-76236 -
-

Es posible efectuar ataques para que el parser falle.
Sujeto a ataques de inyección de código.



Luego, a los efectos de tener un marco de referencia específico para comprender
los ataques y sus posibles controles mitigantes, el proyecto se vale de la
reconocida Guía de Seguridad OWASP para tomar herramientas y métodos,
puntualmente tomando los temas tratados en la “Web Service Security Cheat
Sheet” [02], cubriendo los siguientes aspectos:

Server Authentication
User Authentication
Transport Encoding
Message Integrity
Message Confidentiality
Authorization
Schema Validation
Content Validation

1) Transport Confidentiality
2)
3)
4)
5)
6)
7)
8)
9)
10) Output Encoding
11) Virus Protection
12) Message Size
13) Availability
14) Endpoint Security Profile

resultó

incluir


Asimismo, a modo de complemento,
las
recomendaciones vertidas por el NIST (National Institute of Standards and
Technology) de Estados Unidos, el cual publica el documento “Guide to Secure
Web Services” (Special Publication 800-95 de Agosto del 2007 [03]), el cual
contiene una extensa guía con muchos detalles sobre cada medida de control,
brinda ejemplos de código fuente para materializar las medidas de seguridad y
analiza distintas posibilidades de implementación.

interesante

IETFDay 2015, 1º Taller del Grupo de Trabajo de Ingeniería de Internet/Argentina. 44 JAIIO - IETFDay 2015 - ISSN: 2451-76237 Imagen 2 - Medidas de seguridad de WS propuestas por NIST


Se describe a continuación las medidas de seguridad implicadas en cada
dimensión de la Guía 800-95 de NIST:

● Dimensión “Messaging”: Dentro de esta dimensión se destacan aquellas
tecnologías que fortalecen SOAP (que no fuera pensado inicialmente con
conceptos de seguridad), como por ejemplo HTTPS, cifrado XML y la firma
digital de XML, con los consiguientes beneficios a la hora de dificultar o
impedir capturas o manipulación de mensajes en texto plano transmitidos
por los WS. Esta dimensión también incluye WS-Security que define los
mecanismos para utilizar tanto el cifrado como la firma digital de mensajes
SOAP.


● Dimensión “Resource”: Implica la utilización de mecanismos de
control de acceso para que los WS puedan ser consumidos sólo por
aquellos sistemas autorizados. Un ejemplo de alternativa de
autenticación para WS es XACML (eXtensible Access Control
Markup Language [04]).



● Dimensión “Negotiation”: Esta dimensión engloba a los mecanismos
la negociación y el

los cuales se automatiza

mediante

IETFDay 2015, 1º Taller del Grupo de Trabajo de Ingeniería de Internet/Argentina. 44 JAIIO - IETFDay 2015 - ISSN: 2451-76238



descubrimiento de nuevas funcionalidades ofrecidas por los WS.
Los subcomponentes incluidos en la dimensión “Negotiation” son:


-
-
-
-
-

Protocolo de negociación.
Servicio de negociación.
Servicio de mediación.
Servic