Download análisis basado en modelos de las configuraciones

Traducción por: M.C.E. Christian Mauricio Castillo Estrada
Fecha de Traducción: Mayo de 2016
Material usado en la materia: Desarrollo de Sistemas de Información basados en Web I Java EE (8°U)
Artículo publicado en: MiSE’16, May 16-17 2016, Austin, TX, USA.
Año de publicación: Mayo de 2016
ANÁLISIS BASADO EN MODELOS DE LAS CONFIGURACIONES DE SEGURIDAD
WEB DE JAVA EE
Resumen
El uso generalizado de aplicaciones web Java EE
como un medio para proporcionar servicios
distribuidos a clientes remotos impone fuertes
requerimientos de seguridad, de manera que los
recursos manejados por estas aplicaciones
permanezcan protegidos contra revelaciones y
manipulaciones no autorizadas.
Para este propósito, el framework Java EE
proporciona a los desarrolladores mecanismos
para definir políticas de control de acceso.
Desafortunadamente, la variedad y complejidad
de la seguridad proporcionada y los mecanismos
de configuración hacen que la definición y
manipulación de una política de seguridad sea
compleja y propensa a errores. Como los
requisitos de seguridad no son estáticos, y por lo
tanto, las políticas implementadas deben
cambiarse y revisarse a menudo, descubrir y
representar la política en un nivel de abstracción
adecuado para permitir su comprensión y
reingeniería aparece como un requisito crítico.
Para abordar este problema, este documento
presenta un enfoque (basado en modelos) dirigido
a ayudar a los expertos en seguridad a visualizar,
(automáticamente) analizar y manipular las
políticas de seguridad web.
Palabras clave
Seguridad, Control de acceso, Ingeniería-Inversa.
El permiso para hacer copias digitales o respaldos de todo o una
parte de este trabajo para uso personal o de salón de clases es
permitido sin cargo alguno en el entendido de que las copias no
son hechas o distribuidas para obtener beneficios o ventajas
comerciales y que las copias contienen esta advertencia y una
cita completa en la primera página. Para cualquier otro tipo de
copia, republicar y distribución en servidores o para redistribuir
en listas, requiere de un permiso específico y/o cargo.
Copyright is held by the owner/author(s). Publication rights
licensed to MiSE’16, May 16-17 2016, Austin, TX, USA. 2016
Copyright held by the owner/author(s). Publication rights
licensed to ACM.
1. INTRODUCCIÓN
Java EE es una tecnología popular de elección para
el desarrollo de aplicaciones web dinámicas, que
también sirve como capa base para otros marcos
de propósito menos general. Java EE facilita la
exposición de información y servicios distribuidos
a usuarios remotos. En este escenario, la
seguridad es una preocupación principal [16], ya
que los recursos web que constituyen la aplicación
web pueden ser potencialmente accedidos por
muchos usuarios sobre redes no confiables. Como
consecuencia, el framework Java EE proporciona a
los desarrolladores las herramientas para
especificar las políticas de control de acceso a fin
de asegurar las propiedades de confidencialidad e
integridad de los recursos expuestos por las
aplicaciones web.
Desafortunadamente,
ya
pesar
de
la
disponibilidad de estos mecanismos de seguridad,
la implementación de configuraciones de
seguridad sigue siendo una actividad compleja y
propensa a errores, donde se necesita alto
1
conocimiento para evitar inconsistencias y
problemas de configuración, que podrían causar
daños críticos a los negocios. A medida que los
recursos gestionados por la aplicación web
pueden ser accedidos por muchos usuarios y
atravesar redes desprotegidas. La divulgación
involuntaria de datos puede dar lugar a
importantes pérdidas tanto en términos de dinero
como de reputación.
1. Escribir restricciones en el archivo de descriptor
web XML utilizando un conjunto de elementos de
etiqueta predefinidos.
2. Escribir anotaciones (con una sintaxis y
organización diferentes w.r.t los elementos de la
etiqueta XML) en los componentes de Java Servlet.
Ambos mecanismos pueden utilizarse en la misma
aplicación Java EE, por lo que se necesitan reglas
de combinación para obtener la política de
seguridad final. En este contexto, el
descubrimiento y la comprensión de las políticas
de seguridad que realmente están siendo
aplicadas por una aplicación web dada se
presentan como un requisito fundamental. El
principal reto para este proceso de
descubrimiento es salvar la brecha entre la
representación de políticas de bajo nivel dispersa
y una representación global de alto nivel, más fácil
de entender y manipular. Para abordar este
problema, proporcionamos, para el caso de las
aplicaciones web Java EE:
1. Una unificación lingüística de los dos mecanismos
declarativos de especificación de restricciones
proporcionados por el marco de Java EE, de manera que
las contribuciones de ambos mecanismos pueden ser
analizadas por los mismos procedimientos y
herramientas.
2. Un proceso de ingeniería inversa que extrae las
configuraciones de seguridad implementadas mediante
el uso de los diversos mecanismos Java EE y los integra
a un modelo de seguridad conforme a un metamodelo
de seguridad web propuesto.
3. Una demostración de las aplicaciones y ventajas de
utilizar una representación basada en modelos
integrados, dado que esto permite la reutilización en el
dominio de seguridad del gran número de técnicas y
herramientas modeladas que se pueden aplicar para
visualizar, analizar, evolucionar, etc.
Nuestro enfoque complementa los trabajos existentes
de ingeniería inversa de Java que saltan aspectos de
seguridad [3, 5].
Demostramos la viabilidad de nuestro enfoque a
través de un prototipo de implementación de
herramientas y su aplicación a una muestra de
aplicaciones reales de Java EE disponibles GitHub.
El resto del artículo está organizado de la siguiente
manera. La Sección 2 presenta el mecanismo de
control de acceso diverso proporcionado por el
marco de Java EE, mientras que la Sección 3
introduce nuestro enfoque para extraer una
representación de modelo integrada de ellos. La
Sección 4 describe una serie de escenarios de
aplicación relevantes. La evaluación del enfoque
se proporciona en la Sección 5, seguida en la
Sección 6 por una breve descripción del soporte de
herramientas que proporcionamos para lograr la
automatización.
Concluimos el trabajo discutiendo el trabajo
relacionado en la Sección 7 y proporcionando
futuras líneas de investigación y conclusiones en la
Sección 8.
2.- SEGURIDAD WEB EN JAVAEE
A grandes rasgos, en el framework Java EE, cuando
un cliente web realiza una solicitud HTTP, el
servidor web traduce la solicitud en llamadas HTTP
Servlet a componentes web (Servlets y Java Server
Pages) que pueden responder directamente o, a
su vez, Java Beans (EJBs) para realizar operaciones
de lógica de negocios más complejas. En este
esquema, un requisito muy importante es
asegurar la confidencialidad e integridad de los
recursos gestionados por la aplicación web. En
este sentido, el framework Java EE proporciona
instalaciones de control de acceso listas para usar.
A continuación describiremos brevemente el
mecanismo que ofrece Java EE para la
implementación de políticas de control de acceso
para aplicaciones web.
2.1 CONTROL DE ACCESO
Las aplicaciones Java EE suelen estar constituidas
por JSP y Servlets. El mecanismo de control de
acceso en su lugar se encarga de controlar el
acceso a estos elementos junto con cualquier otro
artefacto almacenado en la web y accesible
(páginas HTML puras, documentos multimedia,
etc.). 1 Dos sabores están disponibles para
especificar políticas de seguridad a este nivel:
2
Declarativa y programática, siendo esta última
prevista para los casos en que se requiera un
control de acceso fino, que requiera una
evaluación del contexto del usuario.
Respecto a las políticas de control de acceso
declarativo, existen dos alternativas: 1) escribir las
restricciones de seguridad en un Descriptor de
Despliegue Portátil (web.xml) y 2) escribir
anotaciones de seguridad como parte del código
Servlets Java (tenga en cuenta que no todas las
configuraciones de seguridad pueden ser
Especificado mediante anotaciones).
<security -constraint>
< display-name>
GET To Employees
< / display-name>
<web-r e s o u r c e-c o l l e c t i o n >
<web-r e s o u r c e-name>
Restricted
< / web-r e s o u r c e-name>
< u r l-p a t t e r n >
/ r e s t r i c t e d / employee / < / u r l-p a t t e r n >
< h t t p-method>GET< / h t t p-method>
< / web-r e s o u r c e-c o l l e c t i o n >
<auth-c o n s t r a i n t >
< r o l e-name>Employee< / r o l e-name>
< / auth-c o n s t r a i n t >
<us e r-da t a-c o n s t r a i n t >
< t r a n s p o r t -g u a r a n t e e >
NONE
< / t r a n s p o r t -g u a r a n t e e >
< / us e r-da t a-c o n s t r a i n t >
< / s e c u r i t y -c o n s t r a i n t >
Listado 1: Restricción de seguridad en web.xml
Consideremos una aplicación web corporativa con
un área restringida para empleados y donde se
define un rol Empleado. El Listado 1 muestra una
restricción de seguridad definida en un descriptor
web.xml que restringe el acceso (al utilizar el
método HTTP GET) al área de empleados a los
usuarios que tienen la función Empleado.
Contiene tres elementos principales: una
colección de recursos web que especifica la ruta
de los recursos afectados por la restricción de
seguridad y el método HTTP utilizado para ese
acceso (en este caso, la ruta/restricted/employee
* y el método GET); Una restricción de
autorización que declara qué funciones, si las hay,
tienen acceso a los recursos
(Sólo el rol Empleado en el ejemplo) y una
restricción de datos de usuario que determina
cómo deben viajar los datos de usuario desde y
hacia la aplicación web, establecida en Ninguno
(es decir, se acepta cualquier tipo de transporte)
en el ejemplo.
La restricción de seguridad equivalente, definida
por medio de anotaciones, se muestra en el
Listado 2. La anotación @WebServlet identifica el
servlet y la ruta del recurso en el contenedor web.
Entonces, la anotación de seguridad principal es
@ServletSecurity que tiene dos atributos: value,
que corresponde a una anotación anidada @ HttpConstraint y httpMethodConstraint que contiene
una lista de anotaciones @HttpMethodConstraint
anidadas. El @HttpConstraint se utiliza para
representar una restricción de seguridad que se
aplicará a todos los métodos HTTP mientras que el
segundo se utiliza para definir las restricciones de
método por-HTTP.
Ambos,
@HttpConstraint
y
@HttpMethodConstraint
contienen
como
atributos una lista de roles permitidos
(allowedRoles), los requisitos de protección de
datos (equivalente al elemento de restricción de
datos de usuario en el archivo web.xml) y el
comportamiento cuando la lista de roles
permitidos está vacía.
1 @WebServlet (
2 name = " R e s t r i c t e d S e r v l e t " ,
3 urlPatterns ={ " / r e s t r i c t e d / employee
/
"})
4 @S e r v l e t S e c u r i t y ( ( h t t pMe t h o dCo n
straints={
5 @Ht tpMe thodCons t r a int (
6 value = "GET" ,
7 rolesAllowed = " Employee " )
8 t r a n s p o r tGu a r a n t e e = Tr a n s p o r tGu
a r a n t e e . None ) } )
9 p u b l i c c l a s s RestrictedServlet e x t e n d s
HttpServlet { . . . }
Listado 2: Servlet anotado
2.1 COMBINACIÓN DE POLITICAS Y REGLAS
Ambas alternativas declarativas mencionadas
anteriormente pueden utilizarse al mismo tiempo
y la política de seguridad final es el resultado de
combinar las restricciones de seguridad
especificadas con ambos mecanismos. Sin
embargo, en caso de conflictos, las restricciones
3
especificadas en el archivo web.xml tienen
prioridad y, además, las restricciones definidas
mediante anotaciones pueden ser completamente
ignoradas si así se establece en el descriptor
web.xml (el conjunto de parámetros metadatacomplete como true) Lo que puede crear
claramente situaciones confusas para los no
expertos.
Además, las políticas de control de acceso
definidas con los mecanismos descritos
anteriormente pueden contener inconsistencias
(reglas que establecen diferentes acciones de
acceso para el mismo recurso). Estas
incoherencias se resuelven utilizando precedencia
de reglas, semántica de ejecución y algoritmos de
combinación definidos en la especificación Java EE
Servlet.
Desafortunadamente, mientras este proceso
elimina las inconsistencias en la política, puede
introducir anomalías de control de acceso típicas,
tales como sombreado y redundancia [8], junto
con otras mis configuraciones particulares al
control de acceso de Java EE.
Tenga en cuenta que, como se mencionó
anteriormente, las restricciones de control de
acceso de grano fino que requieren información
de contexto también pueden definirse en el marco
de Java EE. Estas restricciones no pueden definirse
declarativamente y requieren el uso de seguridad
programática. Ejemplos de ello serían las
restricciones que verifican que un usuario tiene
dos funciones o que una conexión sólo puede ser
aceptada en intervalos de tiempo específicos.
Dejamos el análisis de estas limitaciones
programáticas finas como un trabajo futuro.
Observe también que la especificación Java EE
recomienda un uso preferencial de seguridad
declarativa siempre que sea posible.
Figura 1: Análisis de aplicaciones web de Java EE
3. METODO
Nuestro método, representado en la Figura 1,
recoge la información de seguridad contenida en
una aplicación Java EE extrayéndola hacia
representaciones de modelos. A continuación, los
unifica e integra en un modelo específico de
dominio (por medio de transformaciones de
modelos), de manera que las manipulaciones de
los modelos, las operaciones de consulta, etc.,
puedan aplicarse posteriormente sobre ella para
analizar y gestionar la configuración de seguridad.
El metamodelo específico del dominio y el proceso
de extracción se describen en el resto de esta
sección.
3.1 MetaModelo /MetaModel
Antes del proceso de extracción, se requiere la
definición de metamodelos capaces de
representar con precisión la información
contenida en los archivos fuente de configuración.
Para ello se utilizará el metamodelo de seguridad
Servlet Access-Control (en adelante denominado
metamodelo de seguridad Servlet) representado
en la figura 2. Tanto las anotaciones como las
definiciones de seguridad XML comparten
semántica similar y por lo tanto pueden ser
asignadas a esta sintaxis abstracta de metamodelo
que nos permite ir directamente desde sus
representaciones de modelo de bajo nivel (modelo
Java y modelo XML, ya disponibles en el marco
MoDisco [3]) a nuestra seguridad Metamodelo sin
necesidad de definir metamodelos de seguridad
específicos intermedios para su representación.
El metamodelo Servlet Security permite manejar
roles de seguridad (clase SecurityRole) y
restricciones
de
seguridad
(clase
SecurityConstraint) en una aplicación web
determinada. El primero específica los roles de
seguridad definidos por la directiva de seguridad.
Este último se utiliza para representar las
restricciones de control de acceso, procedentes de
descriptores web XML
O anotaciones Java (atributo de origen), en una
colección
de
recursos
web
(clase
WebResourceCollection). Cada colección de
recursos web identifica los recursos (atributo
urlPattern) y los métodos HTTP (clase
HttpMethod) a los que se aplica una restricción de
seguridad. Es importante tener en cuenta que si un
método HTTP se define como omitido (atributo de
4
omisión), la restricción de seguridad se aplica a
todos los métodos excepto al método omitido.
El conjunto de roles que participan en la
restricción de seguridad para una colección de
recursos web se agrupan bajo una restricción de
autorización (clase AuthConstraint). La ausencia
de un elemento AuthConstraint en una restricción
dada representa el acceso público mientras que la
exclusión total está representada por su presencia
sin asociación de funciones.
Una restricción de seguridad también puede
asociarse con un requisito de protección de datos
dado (clase UserDataConstraint). Este requisito de
protección de datos puede definirse como:
NINGUNO indicando que el contenedor debe
aceptar peticiones cuando se reciben en cualquier
conexión, INTEGRAL estableciendo un requisito
para la integridad del contenido y CONFIDENCIAL,
estableciendo
un
requisito
para
la
confidencialidad de la comunicación.
3.2 Proceso de Extracción
Una vez que un metamodelo capaz de describir las
definiciones de control de acceso de Java EE está
disponible, podemos extraer la información de
control de acceso definida para la aplicación web.
El proceso de extracción, que se muestra en la
Fig.1, consta de tres pasos, a saber, el
descubrimiento de modelos, transformación e
integración y análisis.
El paso de descubrimiento del modelo se basa en
Modisco que analiza el código fuente de Java y el
descriptor web XML para obtener las
representaciones correspondientes del modelo, a
saber, un modelo Java y un modelo XML. Al
hacerlo, pasamos del espacio técnico de
anotaciones de código fuente y archivos XML a la
del dominio modelware. Los modelos obtenidos
son manipulados y la información de seguridad
contenida se mezcla en el paso de transformación
e integración para obtener un modelo que se
ajuste al metamodelo de seguridad Servlet
propuesto (modelo de seguridad web en la figura).
Este paso de transformación e integración se
basan en ATL [9], un lenguaje de transformación
de modelo.
El código ATL para la transformación e integración
incluye 19 reglas y 31 ayudantes. 10 reglas y 6
ayudantes tratan con la información contenida en
el descriptor XML, mientras que las 9 reglas
restantes y 25 ayudantes se encargan de la
información de seguridad dentro del modelo de
código fuente.
El mencionado proceso nos permite facilitar las
operaciones de manipulación necesarias para
analizar las políticas w.r.t. Una manipulación
directa de las restricciones definidas por separado
en las anotaciones XML y código fuente con
técnicas más básicas (como manipulación de texto
o transformación xslt). Concretamente, nos
permitirá: 1) utilizar herramientas y marcos bien
conocidos de la unidad de modelado y 2) tratar la
información de seguridad de una manera
uniforme, sin tener en cuenta si fue especificada
usando XML o anotaciones. Observe sin embargo
que estos modelos se encuentran en el mismo
nivel de abstracción de las configuraciones
originales y por lo tanto, no se produce pérdida de
información en el proceso de extracción.
El Listado 3 muestra una regla ATL, parte de la
transformación para extraer directivas de control
de acceso, que mapea Servlets anotados a
entidades de SecurityConstraint.
Tenga en cuenta que con el fin de hacer
transparente a los usuarios los detalles técnicos de
bajo nivel necesarios para usar MoDisco y ATL,
hemos desarrollado una herramienta bajo Eclipse,
que permite al usuario seleccionar un proyecto
Java EE determinado y su descriptor web a través
de una GUI simple Para derivar el modelo de
seguridad
Servlet
correspondiente.
Tal
herramienta puede emplearse como soporte para
diferentes tipos de aplicaciones.
1 lazy rule createSecurityConstraint {
2 from
3 s : JAVA!Annotation
4 us ing {
5 servletAnnotation : JAVA!Annotation =
6 s . getContainerAnnotation(’ServletSecurity’) ; }
7 to
8 t : SEC!SecurityConstraint (
9 webResourceCollection <�
10 thisModule . createWebResourceCollection(
11 servletAnnotation . getWebServlet , s) ,
12 authConstraint <�
13 i f s . getEmptyRoleSemantic = ’PERMIT’ then
14 thisModule . createAuthConstraint(s , true)
15 e l s e
16 thisModule . createAuthConstraint(s , false)
5
17 endi f ,
18 source <- #CODE)
19 }
Listado 3: Regla ATL para asignar servlets anotados de
seguridad a Restricciones de seguridad
El último paso de nuestro enfoque, a saber, el
análisis y la manipulación de las configuraciones
de seguridad extraídas se demostrará en la
siguiente sección mediante la descripción de una
serie de escenarios de aplicación.
4. APLICACIONES
Tener toda la información de control de acceso de
una aplicación web Java EE reunida y representada
en la forma de un modelo integrado
correspondiente a nuestro metamodelo Servlet
Security, permite la reutilización de una amplia
gama de herramientas y técnicas probadas de
modelo Derivan interesantes aplicaciones de
análisis. En el siguiente, discutiremos algunos de
ellos, enfocándonos en el cálculo de consultas y
métricas y discutiendo brevemente el resto.
4.1 Problema
Una de las aplicaciones más inmediatas de nuestro
metamodelo es utilizar lenguajes de consulta
como OCL o IncQuery [2] para realizar operaciones
de consulta y métricas sobre la información de
nuestro modelo. Desde simples consultas como la
lista de todos los recursos alcanzables por un tema
dado a operaciones más complejas como la
detección de roles equivalentes (un
Mal olor para una posible ruptura en la estrategia
de menor privilegio), nuestro modelo de
representación, extracción de modelos y el
enfoque de integración facilitar el análisis de la
seguridad de una aplicación JEE, reduciendo la
complejidad de la realización de tales operaciones
w.r.t. Trabajar con los mecanismos de
configuración originales y hacer la integración
necesaria a mano.
Como ejemplo, mostraremos aquí la definición de
una métrica que cuenta los recursos libremente
accesibles. Recuento de consulta de recursos de
acceso abierto: los recursos de las aplicaciones
Java EE pueden ser visibles para un conjunto
reducido de usuarios que tienen determinados
roles o que son de libre acceso para todos,
independientemente de sus funciones. Una
inspección manual de la aplicación para descubrir
los recursos de acceso abierto puede ser una tarea
tediosa, sin embargo aprovechando el
metamodelo Servlet Security propuesto, podemos
definir fácilmente una métrica para detectar y
contar este tipo de recursos.
1 query unreachableResources =
2 SEC!SecurityConstraint . allInstances ( )
3 ->select(sc | sc . authConstraint . oclIsUndefined ( ) )
4 ->collect(sc | sc . webResourceCollection)->flatten ( )
5 ->collect(wrc | wrc . urlPattern)->flatten ( )
6 ->collect(up | up . value)->flatten ( )
7 ->asSet ( )->asSequence ( )->size ( ) ;
Listado 4: Consulta métrica para contar los recursos de
acceso abierto
El Listado 4 muestra una posible consulta OCL
capaz de detectar recursos de acceso abierto. Se
seleccionan todas las restricciones de seguridad
que no definen una restricción de autorización
(authConstraint), ya que no imponen ninguna
restricción de acceso a los recursos declarados
dentro de la restricción (ver líneas 2-3). A
continuación, se recogen las direcciones URL
dentro de cada recurso contenido en las
restricciones seleccionadas (ver líneas 4-6) y
finalmente se cuentan (véase la línea 7).
4.2 Exactitud
Las propiedades de corrección de la definición de
seguridad se pueden verificar realizando consultas
sobre nuestro modelo de seguridad extraído. La
detección de configuraciones erróneas (por
ejemplo, la accesibilidad de recursos rotos,
dejando recursos inaccesibles por cualquier
función) se habilita así ayudando a los
desarrolladores a verificar fácilmente sus
configuraciones de seguridad y encontrar posibles
errores. A modo de ejemplo, en lo que sigue
daremos detalles sobre cómo comprobar una
propiedad de seguridad muy importante para
configuraciones de seguridad de Java EE, por
ejemplo, la propiedad de completitud.
Propiedad de completitud y consulta: Al definir
una restricción de control de acceso sobre un
recurso determinado, los desarrolladores deben
asegurar que especifican la política para cada
forma de acceso al recurso, si no lo hace, puede
dejar información inesperadamente disponible (o
inesperadamente excluida). Esto es especialmente
cierto para el marco de Java EE
6
Debido a la semántica específica de sus políticas
de seguridad. Si se nombra un método HTTP en
una restricción de seguridad, se deben especificar
todos los demás métodos HTTP estándar en la
misma o en otra restricción de seguridad que
coincida con el mismo conjunto de solicitudes. De
lo contrario, los métodos HTTP no denominados se
considerarán como descubiertos, dando acceso
sin restricciones a ellos.
Figura 3: Visión de visualización de la política de Sirius
En el ejemplo 1 se muestra un ejemplo de una
restricción de seguridad que viola esta propiedad.
En el ejemplo, se define una restricción para el
método GET, indicando que sólo se permiten los
usuarios que tienen la función Empleado. Sin
embargo, no se dice nada sobre ningún otro
método HTTP. En ausencia de otras restricciones
con un patrón URL idéntico, esta, y por lo tanto, se
concederá acceso sin restricciones a cualquier
método HTTP diferente de GET. En el Listado 5
mostramos la consulta que calcula la propiedad
“completeness”.
1 contextHttpMethod inv :
2 let HTTP_METHODS : Sequence (OclAny) =
3 Sequence {’OPTIONS’ ,’GET’ ,’HEAD’ ,’POST’ ,
4 ’PUT’ ,’DELETE’ ,’TRACE’ ,’CONNECT’} in
5 l e t ALL_HTTP_METHODS : Sequence
(PSM!HttpMethod) =
6 PSM!HttpMethod . allInstances ( ) in
7 l e t httpMethodsToCheck : Sequence ( S t r i n g ) =
8 i f self . omission then
9 HTTP_METHODS->select(m | m = self . name)
10 e l s e
11 HTTP_METHODS->reject(m | m = self . name)
12 end if in
13 l e t selfUrlPatterns: Sequence (PSM!UrlPattern) =
14 self . refImmediateComposite ( ) . urlPattern in
15 selfUrlPatterns->iterate(sup ; output : Boolean =
true,!|
16 l e t declaredHttpMethods : Sequence
(PSM!HttpMethod) =
17 ALL_HTTP_METHODS->reject(hm | hm = self)
18 ->select(hm |
,!hm . refImmediateComposite ( ) . urlPattern
19 ->exists(up | sup . value = up . value) ) in
20 if declaredHttpMethods->isEmpty ( ) then
21 false
22 e l s e
23 output and httpMethodsToCheck
24 ->forAll(m | declaredHttpMethods
25 ->exists(dhm | dhm . name = m) )
26 endif
Listado 5: Consulta OCL para calcular la propiedad de
integridad
7
4.3 Visualización
La información gráfica a menudo es más fácil de
entender a simple vista que la textual. En este
sentido, las herramientas de generación de
workbench basadas en Modelos como Sirius2
permiten la definición de diferentes puntos de
vista para un lenguaje específico de dominio, de
modo que se pueden obtener diferentes
representaciones gráficas sin necesidad de
manipular el modelo fuente para crear la vista. De
esta manera, podemos obtener representaciones
generales, resumiendo la política de control de
acceso de una aplicación dada, o una
representación más detallada que muestra, por
ejemplo, la información de seguridad detallada
relacionada con un recurso o rol dado. La Figura 3
muestra la visualización obtenida para una
aplicación web simple donde los recursos web, los
roles y las restricciones definidas son visibles
(tenga en cuenta que para legibilidad algunas
relaciones se omite).
4.4 Representación de pivote
Nuestro metamodelo y proceso de extracción
también se puede utilizar como una
representación de pivote para construir puentes
hacia otras representaciones (modelo). Las
traducciones de nuestro metamodelo a lenguajes
de control de acceso más genéricos como
SecureUML o XACML [17] permitirían la
reutilización de la gran cantidad de investigación
realizada en el campo general del análisis de
acceso y control. Cabe destacar que las técnicas
formales de validación y verificación [14], junto
con el análisis del impacto del cambio [6] para las
políticas de control de acceso estarían disponibles.
Además, mediante la integración de nuestro
proceso de extracción y el modelo en los marcos
de reingeniería de Java EE podemos utilizar el
enfoque presentado aquí para 1) extraer las
configuraciones de control de acceso de una
aplicación web 2) aplicar el análisis de modelos y
técnicas de manipulación para encontrar una
correcta posible existente mis configuraciones o
Implementar refactorizaciones de seguridad y 3)
regenerar la aplicación web con una configuración
de seguridad correcta.
5. EVALUACIÓN
Con el fin de demostrar la viabilidad y la eficacia de
nuestro enfoque hemos construido una
herramienta de prototipo y llevó a cabo una
evaluación de una muestra de proyectos reales de
Java EE extraídos de GitHub.
De los proyectos recolectados, se realizaron dos
pasos de filtrado para eliminar proyectos de
juguete. Primero, filtramos manualmente aquellos
proyectos que incluyeran una de las siguientes
palabras en su nombre o ruta: prueba, muestra,
demo, ejemplo, tutorial, entrenamiento, ejercicio,
lección. En segundo lugar, a partir de los proyectos
a la izquierda, se derivó la representación modelo
de sus configuraciones de seguridad, y se filtraron
los que declararon menos de 5 restricciones de
seguridad, obteniendo de esta manera una
muestra compuesta de 16 proyectos.
Hemos realizado tres análisis sobre la muestra
anterior: primero, hemos aplicado nuestra
herramienta para obtener representaciones de
modelos de sus configuraciones de seguridad y
medido el tiempo para realizar la tarea, en
segundo lugar, hemos evaluado automáticamente
la consulta de corrección presentada en la Sección
4. Finalmente, Y para comprobar la existencia de
falsos
positivos,
hemos
comprobado
manualmente esta propiedad en la lista de
proyectos.
En la Tabla 1, que muestra para cada proyecto Java
EE el número de restricciones que componen su
configuración de seguridad y para la consulta de
corrección de seguridad, si se detecta una
anomalía manual y / o automáticamente, se
resumen los resultados obtenidos.
La Tabla 1 también muestra el tiempo que tomó
nuestra herramienta para extraer modelos de los
correspondientes proyectos web Java EE (gen.) Y
para evaluar (eval.) Nuestra propiedad de
corrección de seguridad sobre ellos. El tiempo de
extracción del modelo depende directamente del
número de archivos Java, mientras que el tiempo
para calcular las propiedades depende del número
de reglas de seguridad en la política y de la
complejidad de las interacciones entre reglas.
Ambas veces son razonablemente bajas para un
análisis offline y concretamente, el tiempo de
analizar las propiedades es siempre inferior a un
segundo.
Esta evaluación muestra que nuestro enfoque: 1)
tiene un buen rendimiento y por lo tanto es
adecuado para ser utilizado en escenarios reales 2)
8
la información de seguridad pertinente no se
pierde en el proceso y por lo tanto, se puede
analizar como si se hizo manualmente sobre el
original Los artefactos de configuración. Esto se
demuestra por la ausencia de falsos positivos o
falsos negativos en la evaluación de la propiedad
de completitud. Los mismos resultados son
obtenidos por ambos, nuestra herramienta y por
inspección manual.
6. HERRAMIENTAS DE SOPORTE
Ofrecemos soporte de herramientas que cubre
dos aspectos diferentes de nuestro trabajo. Por un
lado, hemos creado una herramienta que se basa
en Selenium [21] para muestrear de forma
aleatoria GitHub proyectos (para ser analizados
por cuestiones de seguridad). Por otra parte, se ha
desarrollado una herramienta como plugin bajo la
plataforma Eclipse [22] con el propósito de extraer
automáticamente modelos de seguridad de las
configuraciones existentes. Ambas herramientas
están disponibles en GitHub.4
control de acceso definidas responsables de ese
comportamiento, como lo hacemos nosotros. Más
similar al presente trabajo, en [19] los autores
presentan un metamodelo de seguridad y enfoque
de ingeniería inversa especialmente adaptado
para extraer las configuraciones de seguridad de la
web Content Management Systems (CMS) (un
lenguaje similar se presenta en [23]). En cambio,
no nos restringimos a una clase específica de
aplicaciones.
En cuanto a DSL de seguridad (web) en [18], se
presenta un perfil RBAC para modelos UML.
UmlSEC, otra extensión del lenguaje UML a los
requisitos de seguridad de alto nivel, se introduce
en [10] y se utiliza en [11] para modelar las
propiedades de seguridad de alto nivel (requisitos)
para propósitos de ingeniería avanzada. Más
enfocados en aplicaciones web, los enfoques de
modelado web, como construcciones de
seguridad [12] y [4] incluspecific, por lo menos
para especificar usuarios y roles y sus permisos de
acceso en partes del modelo de navegación web.
7. TRABAJOS RELACIONADOS
Varias otras obras abordan el problema de extraer
políticas de control de acceso de aplicaciones web
dinámicas. Sin embargo, se centran en tipos
específicos de aplicaciones, como CMS, o se
centran en la recuperación sólo de bajo nivel, la
aplicación intercontinental de control de acceso.
Nuestro trabajo se centra en la recuperación de las
configuraciones de seguridad de cualquier
aplicación web Java EE que cubra los mecanismos
proporcionados por los frameworks de
aplicaciones web.
Concretamente, en [1] los autores utilizan técnicas
de análisis dinámico para extraer modelos
SecureUML de aplicaciones web PHP. También
para aplicaciones PHP, en [15] las violaciones de
privilegios entre procedimientos se detectan
analizando autómatas extraídos del código fuente.
En [7] se ha estudiado un enfoque similar para la
plataforma de aprendizaje Moodle Web. Por
último, no se centró en las aplicaciones web, pero
en código Java, los autores presentan un enfoque
para realizar interprocedural análisis de privilegios
para aplicaciones Java [13]. Todos estos trabajos
se centran en extraer cierta información de
seguridad analizando el comportamiento en
tiempo de ejecución de la aplicación en lugar de
realizar un análisis estático de las políticas de
Sin embargo, consideramos que un mejor punto
de partida para un análisis de seguridad requiere
un metamodelo de seguridad más específico.
Además, ninguno de estos marcos y lenguajes
proporciona un enfoque de ingeniería inversa para
obtener
automáticamente
los
modelos
correspondientes de las configuraciones de
seguridad de Java EE existentes. En este sentido,
nuestro enfoque podría ser un buen complemento
a ellos actuando como un modelo de pivote, ya
que las traducciones de nuestro lenguaje a esas
otras representaciones serían posibles, por
ejemplo, como parte de un modelo de calzado de
caballos.
8. CONCLUSION
Hemos presentado un enfoque de ingeniería
inversa basado en modelos para extraer políticas
de control de acceso de los diversos mecanismos
de configuración de seguridad de aplicaciones web
Java EE. Como resultado del proceso, se crea un
modelo de control de acceso independiente de la
plataforma que integra en un solo lugar las
diversas restricciones parciales de seguridad,
Facilitando la comprensión y análisis de las
políticas. Hemos demostrado la viabilidad y
pertinencia de nuestro enfoque mediante el
9
desarrollo de una herramienta de prueba de
concepto que hemos aplicado en un conjunto de
proyectos reales recuperados de GitHub.
Como trabajo futuro, prevemos varias extensiones
posibles. En primer lugar, creemos que un enfoque
de ingeniería avanzada que apunte al despliegue
automático de políticas refactorizadas corregidas
sería una evolución natural de nuestro enfoque.
Entonces, creemos que extenderlo para incluir
otras configuraciones de seguridad es igualmente
interesante.
En este sentido, pretendemos ampliar nuestro
enfoque
para
incluir:
1)
restricciones
programáticas de seguridad; 2) otras fuentes de
configuraciones de seguridad (por ejemplo, del
sistema de bases de datos subyacente) para
obtener una versión más completa de la seguridad
del sistema en su conjunto y 3) Marcos más
complejos construidos sobre Java EE (que
normalmente proporcionan su propio mecanismo
de seguridad) como el marco de Spring.
Finalmente, y siguiendo el camino abierto en la
Sección 4 con la codificación y evaluación de una
propiedad de seguridad como una consulta OCL,
pretendemos extender nuestro enfoque y
herramienta
para
definir
y
analizar
automáticamente un conjunto de propiedades de
seguridad importantes más allá de la propiedad de
corrección descrita aquí..
9. REFERENCIAS
[1] M. H. Alalfi, J. R. Cordy, and T. R. Dean.
Recovering role-based access control security
models from dynamic web applications. In
ICWE’12, pages 121–136. Springer, 2012.
[2] G. Bergmann, Z. Ujhelyi, I. Ráth, and D. Varró.
A graph query language for emf models. In
ICMT’11, pages 167–182. Springer, 2011.
[3] H. Bruneliere, J. Cabot, G. Dupé, and F. Madiot.
Modisco: A model driven reverse engineering
framework. IST, 56(8):1012–1032, 2014.
[4] S. Ceri, P. Fraternali, and A. Bongio. Web
modeling language (webml): a modeling language
for designing web sites. Computer Networks,
33(1):137–157, 2000.
[5] V. Cosentino, J. Cabot, P. Albert, P. Bauquel,
and J. Perronnet. A model driven reverse
engineering framework for extracting business
rules out of a java application. In RuleML’12, pages
17–31. Springer, 2012.
[6] K. Fisler, S. Krishnamurthi, L. A. Meyerovich,
and M. C. Tschantz. Verification and changeimpact analysis of access-control policies. In
ICSE’27, pages 196–205. ACM, 2005.
[7] F. Gauthier, D. Letarte, T. Lavoie, and E. Merlo.
Extraction and comprehension of moodle’s access
control model: A case study. In PST’11, pages 44–
51. IEEE, 2011.
[8] H. Hu, G.-J. Ahn, and K. Kulkarni. Anomaly
discovery and resolution in web access control
policies. In SACMAT’11, pages 165–174. ACM,
2011.
[9] F. Jouault, F. Allilaire, J. Bézivin, and I. Kurtev.
ATL: a model transformation tool. Science of
Computer Programming, 72:31–39, 2008.
[10] J. Jürjens. UMLsec: Extending UML for secure
systems development. In UML’02, pages 412–425.
Springer, 2002.
[11] J. Jürjens, J. Schreck, and P. Bartmann. Modelbased
security
analysis
for
mobile
communications. In ICSE’08, pages 683–692. ACM,
2008.
[12] N. Koch and A. Kraus. The expressive power of
uml-based web engineering. In IWWOST’02,
volume 16. CYTED, 2002.
[13] L. Koved, M. Pistoia, and A. Kershenbaum.
Access rights analysis for java. In ACM SIGPLAN
Notices, volume 37, pages 359–372. ACM, 2002.
[14] Y. Ledru, N. Qamar, A. Idani, J.-L. Richier, and
M.-A. Labiadh. Validation of security policies by
the animation of z specifications. In SACMAT’11,
pages 155–164. ACM, 2011.
[15] D. Letarte and E. Merlo. Extraction of interprocedural simple role privilege models from php
code. In WCRE’09., pages 187–191. IEEE, 2009.
[16] X. Li and Y. Xue. A survey on server-side
approaches to securing web applications. ACM
Computing Surveys (CSUR), 46(4):54, 2014.
[17] H. Lockhart, B. Parducci, and A. Anderson.
OASIS XACML TC, 2013.
[18] T. Lodderstedt, D. Basin, and J. Doser.
Secureuml: A uml-based modeling language for
model-driven security. In UML’02, pages 426–441.
Springer, 2002.
[19] S. Martínez, J. Garcia-Alfaro, F. Cuppens,
N. Cuppens-Boulahia, and J. Cabot. Towards
an access-control metamodel for web content
management systems. In ICWE MDWE’13
Workshop, pages 148–155. Springer, 2013.
[20] R. Sandhu, D. Ferraiolo, and R. Kuhn. The
NIST model for role-based access control:
10
towards a unified standard. In RBAC’00, pages
47–63. ACM, 2000.
[21] Selenium, a portable software testing
framework
for
web
applications.
http://www.seleniumhq.org/.
[22] D. Steinberg, F. Budinsky, M. Paternostro,
and E. Merks.
EMF: Eclipse Modeling Framework 2.0.
Addison-Wesley
Professional, 2nd edition, 2009.
[23] V. Svansson and R. E. Lopez-Herrejon. A
web specific
language for content management systems.
In OOPSLA
DSM Workshop, Montréal, Canada, 2007.
11